Displaying 5 results from an estimated 5 matches for "callsite_patch_st".
2009 Oct 30
2
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
...g enabled even if its not what I want for
many reasons.
Also perhaps the lazy compilation stub should spin waiting on a lock
(implemented using atomics), and the compilation callback should
execute while holding the lock just before patching the callsite, so it
would look like this in pseudocode:
callsite_patch_state = 0;// for each callsite one byte of memory
callsite:
if (atomic_load(&callsite_patch_state) == 2) {
//fast-path: already compiled and patched
patchsite:
jmp <nop nop nop nop nop nop nop nop> // will be patched
}
// not yet patched, it may already be compiling
if (atomi...
2009 Nov 01
0
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
...ze a bit, but it's clearly better
than the "load the target address" option I mentioned in the bug.
Would you add it to the bug so we don't lose it?
I think we can put the entire "not yet patched" branch inside the
compilation callback to minimize the code size impact:
callsite_patch_state = 0;// for each callsite one byte of memory
callsite:
if (atomic_load(&callsite_patch_state) != 2) {
call CompilationCallback // Doesn't return until the patchsite is patched.
}
//fast- and slow-path: already compiled and patched
patchsite:
call <nop nop nop nop nop nop nop...
2009 Oct 29
0
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray
<nicolas.geoffray at lip6.fr> wrote:
> Hi Jeffrey,
>
> Jeffrey Yasskin wrote:
>>
>> Cool, I'll start implementing it.
>>
>
> Great! Thanks.
>
> Just to clarify things: on my end, it doesn't really matter what is the
> default behavior, as long as vmkit can continue to have the existing
>
2009 Nov 01
1
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
...tter
> than the "load the target address" option I mentioned in the bug.
> Would you add it to the bug so we don't lose it?
>
> I think we can put the entire "not yet patched" branch inside the
> compilation callback to minimize the code size impact:
>
> callsite_patch_state = 0;// for each callsite one byte of memory
>
> callsite:
> if (atomic_load(&callsite_patch_state) != 2) {
> call CompilationCallback // Doesn't return until the patchsite is patched.
> }
> //fast- and slow-path: already compiled and patched
> patchsite:
>...
2009 Oct 29
3
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
Hi Jeffrey,
Jeffrey Yasskin wrote:
> Cool, I'll start implementing it.
>
Great! Thanks.
Just to clarify things: on my end, it doesn't really matter what is the
default behavior, as long as vmkit can continue to have the existing
behavior of lazy compilation. With Chris' solution, I was wondering how
you would implement the getPointerToFunction{Eager, Lazy} functions when