[LLVMdev] Dynamic (JIT) type resolution

[Chris Lattner]

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:
>
> public class One {
>  double a;
> }
>
> and class Two:
> public class Two {
>   static double getDoubleFromOne(One arg) {
>        return One.a;
>   }
> }
> What happens in Java is that types are created lazily. Which means you
> can compile getDoubleFromOne without knowing the layout of the class
> One. Therefore, if you compile getDoubleFromOne without the layout
> information, the compiler will generate the code:

I'm missing something here.  If you lazily compile getDoubleFromOne the 
first time it is called, it seems like you are guaranteed to have layout 
information, as an instance of "One" is required to be passed in for this 
to run.

I guess a better example would be:

static double x() {
   (new One).a = 4;
}

or something like that.  The best way (I think) to handle this is to 
either:

1. interpret the first time through the code, then jit compile after the 
class is loaded, or:
2. jit compile code that is slower than need be (using function calls to 
cause the lazy stuff to happen) and then replace it when the class is 
loaded.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/