Displaying 5 results from an estimated 5 matches for "getdoublefromone".
2007 Nov 06
2
[LLVMdev] Dynamic (JIT) type resolution
...posing. 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;
}
}
Here's the bytecode generated for the getDoubleFromOne method:
ldarg 0
getfield "One", "a"
return
What happens in Java is that types are created lazily. Which means you
can compile getDoubleFromOne without knowing the layout of the...
2007 Nov 06
0
[LLVMdev] Dynamic (JIT) type resolution
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
2007 Nov 06
0
[LLVMdev] Dynamic (JIT) type resolution
...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 co...
2007 Nov 06
4
[LLVMdev] Dynamic (JIT) type resolution
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
2007 Nov 06
2
[LLVMdev] Dynamic (JIT) type resolution
Chris Lattner wrote:
>
> 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.
>
Right, you got me ;) Thanks for giving a better example.
> 1. interpret the first time through the...