search for: patchsite2

Displaying 4 results from an estimated 4 matches for "patchsite2".

Did you mean: patchsite
2009 Oct 30
2
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
...) { // not yet compiling, set state to compiling, and start compiling call CompilationCallBack // set state to patched atomic_set(&callsite_patch_state, 2) } // wait for patched state while (atomic_load(&callsite_patch_state) != 2) { waitJIT(); } // serialize CPUID patchsite2: // execute new code jmp <nop nop nop nop nop nop nop nop> // will be patched waitJIT: jitLock() jitUnlock() ^This should be consistent with the Intel Manual's requirements on XMC, which has a similar algorithm, except for the fast-path. CompilationCallBack: jitLock();...
2009 Nov 01
0
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
...ing, and start compiling >      call CompilationCallBack >      // set state to patched >      atomic_set(&callsite_patch_state, 2) > } > // wait for patched state > while (atomic_load(&callsite_patch_state) != 2) { >  waitJIT(); > } > // serialize > CPUID > patchsite2: > // execute new code > jmp <nop nop nop nop nop nop nop nop> // will be patched > > waitJIT: >    jitLock() >    jitUnlock() > > ^This should be consistent with the Intel Manual's requirements on XMC, > which has a similar algorithm, except for the fast-path....
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 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