Re: Status of Anno Class loader with constant patches?
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. in Lisp there is this form > > (load-time-value t) > > that is essentially a constant but must be evaluated at load time > and not later (as would be done with lazy linking). This is an unusual pattern for the JVM, but it can be done with invokedynamic by pre-executing the constant-load instruction, as follows: 1. Translate the LTV form into an invokedynamic instruction. 2. Emit the invokedynamic instruction into a private static helper method. 3. Call the helper method from two places: The intended use point, and the method. That way, class loading executes , which then "warms up" (links) the invokedynamic instruction. If you have many LTV forms in a compilation unit, this leads to many small helper methods, which may be inconvenient. If that is the case, consider a more complex scheme where all LTV forms in a compilation unit are collected, and their evaluation results collected into a private static final object array. Then, individual lazy-linked invokedynamic instructions can pick from the array.. With such a population of similar invokedynamic instructions, it can help (as Mark discovered) to share a common BSM and use the name field to send in a single simple parameter. The most direct way to specify a parameter to a BSM for a single invokedynamic instruction is to specify a static argument in the BootstrapMethods attribute. This is a relatively new feature: http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/java/dyn/package-summary.html#args If the parameter is a name-string or if you don't mind decoding strings, you can also specify it as the name of the relevant NameAndType. -- John ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
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 to mark my constants. The loader then searched for
them,
created a patch from the string and then converted the tag to the utf8
tag.
Load the class and done. Very nice.
But I was worried that this was not mainstream. So Remi's inputs were
good.
My first attempt was ugly. Ugly in that the constant pool went wild.
For each
constant ( and a method could have a hundred or so ) I needed an
invokeDynamic,
a bootstrap table entry and my constant string. After thinking a bit
( always a
good thing to try) I realized that the name part of the invoke dynamic
could
carry the constant. So now I have a shared bootstrap, and a per
constant invokeDynamic,
nameAndType and constant.
Not as pretty as the pool patching but good enough. My only concern
will be how well
it gets optimized and that I will leave to the experts.
Now on to airity and the unfortunate issue that my stack order is
opposite that of Java
('this' is at the end not the beginning)
For the stack order, your bytecode generator should just generate arguments
in reverse order or if you're lazy, you can use
MethodHandles.permuteArguments().
regards
mark
Rémi
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
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 >> return a constant method handle created using the value. > So what you recommend? Simple final static (no method handles) or this > scheme? Now or in two years :) > Helmut Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
* 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. So what you recommend? Simple final static (no method handles) or this scheme? Helmut ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
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 searched for
them,
created a patch from the string and then converted the tag to the utf8
tag.
Load the class and done. Very nice.
But I was worried that this was not mainstream. So Remi's inputs were
good.
My first attempt was ugly. Ugly in that the constant pool went wild. For
each
constant ( and a method could have a hundred or so ) I needed an
invokeDynamic,
a bootstrap table entry and my constant string. After thinking a bit (
always a
good thing to try) I realized that the name part of the invoke dynamic
could
carry the constant. So now I have a shared bootstrap, and a per constant
invokeDynamic,
nameAndType and constant.
Not as pretty as the pool patching but good enough. My only concern will
be how well
it gets optimized and that I will leave to the experts.
Now on to airity and the unfortunate issue that my stack order is opposite
that of Java
('this' is at the end not the beginning)
regards
mark___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
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 final static fields can't be optimized as well as constant method > handles (you said that). I say that constant method handles *can* be optimized more easily. static final fields can be optimized as well if changing a static field by reflection trigger a VM deoptimization. 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. > Helmut > Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
* 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 constant method handles (you said that). Helmut ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
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.g. in Lisp there is this form > >(load-time-value t) > > 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 ? > Helmut Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Auto Reply: Re: Status of Anno Class loader with constant patches?
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/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
* 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) that is essentially a constant but must be evaluated at load time and not later (as would be done with lazy linking). Helmut ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
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 indirect: You bind a call site permanently to a K
combinator, which always returns your desired value.
(The K combinator is K(x) := lambda(){x}. See
http://en.wikipedia.org/wiki/SKI_combinator_calculus .)
But the design is also general: An invokedynamic call site can take arguments.
This opens the door to "almost constant" values. Many languages feature
templated value constructors, in which most of the constructor expression is a
constant template, with little bits of inserted data.
Shell: "foo $x bar 12"
Lisp: `(foo ,x bar 12)
JavaScript: {foo: x, bar: 12}
Java+Lambda: {PrintStream out -> out.println("foo "+x+" bar 12")}
In all the above cases, a variable value x is stuffed into the middle of a
mostly-constant value (string, quasiquoted list, object literal, closure,
respectively).
Invokedynamic allows you a hook to pass the constant parts of the template as
bootstrap method parameters, and the non-constant parts as normal stacked
invocation parameters. The bootstrap method is responsible for spinning a
factor method which will take the non-constant parts and build the requested
patterned value. There are lots of interesting language-specific optimizations
possible here.
>From this viewpoint, a "live constant" is simply a zero-argument templated
>value, and the K combinator is its constructor.
Best wishes,
-- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
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 can be modified via reflection. An > IllegalAccessException with the message "field is final" is thrown at > the end of Reflection::resolve_field in reflection.cpp. resolve_field is not used anymore, there is an #ifdef SUPPORT_OLD_REFLECTION before resolve_interface_call. Since 1.4, fields are created with Reflection::new_field and set() is done using sun.misc.Unsafe.putVolatile or by spinning bytecodes. (see subtypes of sun.reflect.UnsafeQualifiedFieldAccessorImpl). To sumarize: 1.2 allows to modify final fields, 1.3 forbids, 1.4+ allows using a new code. > - thomas Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Auto Reply: Re: Status of Anno Class loader with constant patches?
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/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
> 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 message "field is final" is thrown at the end of Reflection::resolve_field in reflection.cpp. - thomas ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
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 called returns a ConstantCallSite with as target a method handle > created by MethodHandles.constant(). At first glance this seems like adding a lot of overhead ( a method send ) as a replacement for a simple ldc bytecode. Are you thinking that hotspot will be efficient in optimizing this? We, the JSR292 EG, think that most of the VMs will be able to optimize this. I like it theoretically, as I don't have to mess with the class loader, but will the overhead be acceptable? 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). happy new year mark roos Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
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 target a method handle > created by MethodHandles.constant(). At first glance this seems like adding a lot of overhead ( a method send ) as a replacement for a simple ldc bytecode. Are you thinking that hotspot will be efficient in optimizing this? I like it theoretically, as I don't have to mess with the class loader, but will the overhead be acceptable? happy new year mark roos___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Auto Reply: Re: Status of Anno Class loader with constant patches?
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/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
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 template by replacing some constants of the template by some live objects. 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 target a method handle created by MethodHandles.constant(). The former offer a push way to store atypical constants, the later offer a pull way to store atypical constants. Rémi > 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 of the anonymous >> class loader in java.dyn.anon to create constant pool >> >> entries with instances of our Smalltalk >> types. >> >> >> Is this feature expected to continue? >> If so in which package will it be located in the JDK7 >> >> release? >> >> >> If not then I assume that we have to >> hold these constants as static fields and create an initializer. >> >> Any other suggestions? >> >> >> thanks for all of the good work >> >> >> mark roos >> >> > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Auto Reply: Re: Status of Anno Class loader with constant patches?
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/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
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 of the anonymous > class loader in java.dyn.anon to create constant pool > > entries with instances of our Smalltalk > types. > > > Is this feature expected to continue? > If so in which package will it be located in the JDK7 > > release? > > > If not then I assume that we have to > hold these constants as static fields and create an initializer. > > Any other suggestions? > > > thanks for all of the good work > > > mark roos > > ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Auto Reply: Re: Status of Anno Class loader with constant patches?
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/mailman/listinfo/mlvm-dev
Re: Status of Anno Class loader with constant patches?
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 expected to continue? If so in which package will it be located in the JDK7 release? If not then I assume that we have to hold these constants as static fields and create an initializer. Any other suggestions? thanks for all of the good work mark roos Hi Mark, the anonymous classloader is a Hotspot specific feature, jdk classes are in package sun.dyn.anon http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/share/classes/sun/dyn/anon/ Also to enable it, you need to use this flag: -XX:+AnonymousClasses This patch was not touched since a long time, so you may espect some troubles, as far as I remember, it only works with host class that is null. I really hope to that the JSR 292 expert group will standardize this API during the JDK8 timeframe. Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
