search for: putfield

Hi everyone, I would like to implement an equivalent mechanism of function callbacks in the JIT, but for fields. Typically in Java, when you compile a method, there may be some instructions (getfield, putfield) that depend on a type which is not yet resolved. I think the best way to do this in LLVM is to add an intrinsic. The intrinsic would be only valid if we jit, and would be lowered only in the codegen part (don't know yet if it would be in the target dependent or target independent part). The...

On Nov 5, 2007, at 8:27 PM, Nicolas Geoffray wrote: > I would like to implement an equivalent mechanism of function > callbacks > in the JIT, but for fields. Typically in Java, when you compile a > method, there may be some instructions (getfield, putfield) that > depend > on a type which is not yet resolved. > > I think the best way to do this in LLVM is to add an intrinsic. The > intrinsic would be only valid if we jit, and would be lowered only in > the codegen part (don't know yet if it would be in the target > depend...

...ight way to go. Can you give an > example snippet of Java code that would need this and what you are > proposing? With a concrete example that shows how the lazy class > loading stuff works we can talk about different possibilities, > > Field operations in Java (getfield, putfield, getstatic, putstatic) do _not_ need what I'm proposing. What I'm proposing is just performance related (just like method patching in callbacks is an optimization in order to not call the callback everytime). Here's a simple example: consider class One: public class One { double a;...

...o modify LLVM. On 2007-11-05, at 23:27, Nicolas Geoffray wrote: > Hi evaeryone, > > I would like to implement an equivalent mechanism of function > callbacks > in the JIT, but for fields. Typically in Java, when you compile a > method, there may be some instructions (getfield, putfield) that > depend > on a type which is not yet resolved. > > I think the best way to do this in LLVM is to add an intrinsic. The > intrinsic would be only valid if we jit, and would be lowered only in > the codegen part (don't know yet if it would be in the target > depend...

On Tue, 6 Nov 2007, Nicolas Geoffray wrote: > Field operations in Java (getfield, putfield, getstatic, putstatic) do > _not_ need what I'm proposing. What I'm proposing is just performance > related (just like method patching in callbacks is an optimization in > order to not call the callback everytime). > > Here's a simple example: consider class One: > &gt...

...:27, Nicolas Geoffray wrote: > > >> Hi evaeryone, >> >> I would like to implement an equivalent mechanism of function >> callbacks >> in the JIT, but for fields. Typically in Java, when you compile a >> method, there may be some instructions (getfield, putfield) that >> depend >> on a type which is not yet resolved. >> >> I think the best way to do this in LLVM is to add an intrinsic. The >> intrinsic would be only valid if we jit, and would be lowered only in >> the codegen part (don't know yet if it would be in...

Hi all, I don't know if I understand everything, but it seems really interesting for a runtime developer, stackmap and patchpoint looks perfect for a lot of optimizations :) I just have few question to verify if I understand what are these stackmaps and patchpoints, and I discuss the GC after. * I have a first very simple scenario (useful in vmkit). Let's imagine that we want to lazily