Auto Reply: Re: Status of Anno Class loader with constant patches?

2011-01-06 Thread henrik . osterdahl
Hello, I'm out of the office Dec 24 2010 through Jan 9 2011. Please refer to David Cox (david.cox) and Daniel Källander (daniel.kallander). Regards, Henrik Österdahl ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net

Re: Status of Anno Class loader with constant patches?

2011-01-06 Thread Helmut Eller
* Rémi Forax [2011-01-06 13:30] writes: that is essentially a constant butexp must be evaluated at load time and not later (as would be done with lazy linking). why not using a static final field initialized in clinit in that case ? Because final static fields can't be optimized as well as

Re: Status of Anno Class loader with constant patches?

2011-01-06 Thread Rémi Forax
On 01/06/2011 04:08 PM, Helmut Eller wrote: * Rémi Forax [2011-01-06 13:30] writes: that is essentially a constant butexp must be evaluated at load time and not later (as would be done with lazy linking). why not using a static final field initialized inclinit in that case ? Because final

Arg ordering on the test path method handle for GwT

2011-01-06 Thread Mark Roos
My goal was to do the port at the byte code level so that there would be a high degree of confidence that the 500K of existing code will work as it does today. It is a stack based VM so changing the arg order could add some pain for me (another thing I try to avoid). Since I am not calling

Re: Status of Anno Class loader with constant patches?

2011-01-06 Thread John Rose
On Jan 6, 2011, at 1:12 AM, Helmut Eller wrote: * John Rose [2011-01-06 02:37] writes: Live constants are definitely one of the use cases that invokedynamic is designed for. Are/will there be any means to link invokedynamic call sites eagerly instead of the lazy linking scheme? E.g.

Re: Arg ordering on the test path method handle for GwT

2011-01-06 Thread John Rose
On Jan 6, 2011, at 10:59 AM, Mark Roos wrote: My goal was to do the port at the byte code level so that there would be a high degree of confidence that the 500K of existing code will work as it does today. It is a stack based VM so changing the arg order could add some pain for me

Re: Arg ordering on the test path method handle for GwT

2011-01-06 Thread Rémi Forax
On 01/06/2011 08:23 PM, John Rose wrote: On Jan 6, 2011, at 10:59 AM, Mark Roos wrote: My goal was to do the port at the byte code level so that there would be a high degree of confidence that the 500K of existing code will work as it does today. It is a stack based VM so changing the arg