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?
On 01/06/2011 05:42 PM, Mark Roos wrote:
Thanks to all for the suggestions on providing live constants to a
method.
I must admit that I was impressed with how the constant patch approach
worked.
As my constants are defined using an utf8 string it was easy to use
some unused
constant type tags
On 01/06/2011 05:50 PM, Helmut Eller wrote:
> * Rémi Forax [2011-01-06 15:36] writes:
>
>> Anyway, you can store your load-time constant in a static field,
>> initialize it in a static block and use invokedynamic to load it.
>> In the bootstrap method, do a field lookup to get the value and
>> retu
* Rémi Forax [2011-01-06 15:36] writes:
> Anyway, you can store your load-time constant in a static field,
> initialize it in a static block and use invokedynamic to load it.
> In the bootstrap method, do a field lookup to get the value and
> return a constant method handle created using the value
Thanks to all for the suggestions on providing live constants to a method.
I must admit that I was impressed with how the constant patch approach
worked.
As my constants are defined using an utf8 string it was easy to use some
unused
constant type tags to mark my constants. The loader then sear
On 01/06/2011 04:08 PM, Helmut Eller wrote:
> * Rémi Forax [2011-01-06 13:30] writes:
>
>>> that is essentially a constant but 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 in that case ?
> Because fina
* Rémi Forax [2011-01-06 13:30] writes:
>> that is essentially a constant but 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 in that case ?
Because final static fields can't be optimized as well as cons
On 01/06/2011 10: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?
No
> E
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
http://mail.openjdk.java.net/mailm
* 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. in Lisp there is this form
(load-time-value t)
On Dec 28, 2010, at 1:53 PM, Rémi Forax wrote:
> We, the JSR292 EG, think that most of the VMs will be able to optimize this.
Thanks for answering Mark's question so fully, Remi.
"Live constants" are definitely one of the use cases that invokedynamic is
designed for.
The design is a little ind
On 12/30/2010 01:40 PM, Thomas Wuerthinger wrote:
Hi Thomas,
>> In fact for hotspot, this kind of constant can be even more optimized
>> than a static final field containing a non-primitive values which is
>> not a real constant
>> (it can be modified by reflection).
> I don't think final fields
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
http://mail.openjdk.java.net/mailm
> In fact for hotspot, this kind of constant can be even more optimized
> than a static final field containing a non-primitive values which is
> not a real constant
> (it can be modified by reflection).
I don't think final fields can be modified via reflection. An
IllegalAccessException with the
On 12/28/2010 07:32 PM, Mark Roos wrote:
Thanks Remi, the extra comments really helped
You also mentioned
>
> There is another way to do something similar,
> you can call invokedynamic, use the bootstrap arguments to send
> the primitive values composing the object value and when the
> BSM is c
Thanks Remi, the extra comments really helped
You also mentioned
>
> There is another way to do something similar,
> you can call invokedynamic, use the bootstrap arguments to send
> the primitive values composing the object value and when the
> BSM is called returns a ConstantCallSite with as t
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
http://mail.openjdk.java.net/mailm
On 12/27/2010 06:33 PM, Charles Oliver Nutter wrote:
> I am curious what you mean here...storing atypical object values (not
> string, int, etc) in the constant pool? Is that possible?
The idea is to use the bytecode of an existing class
as a template and to instantiate a new class from this templ
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
http://mail.openjdk.java.net/mailm
I am curious what you mean here...storing atypical object values (not
string, int, etc) in the constant pool? Is that possible?
On Sunday, December 26, 2010, Mark Roos wrote:
> We are working on a port of Smalltalk to
> the MLVM. For this we were thinking of using the
>
> constant patch feature
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
http://mail.openjdk.java.net/mailm
On 12/26/2010 08:33 PM, Mark Roos wrote:
We are working on a port of Smalltalk to the MLVM. For this we were
thinking of using the
constant patch feature of the anonymous class loader in java.dyn.anon
to create constant pool
entries with instances of our Smalltalk types.
Is this feature expec
22 matches
Mail list logo
