RE Lambda Forms the Sequel
>From John on the HotSpot list The new Lambda Form framework is about to be integrated. This a key foundation stone for optimizing dynamic languages. On this foundation, we want to build a robustly performant and portable implementation of JSR 292, to support our current and future set of great JVM languages, and to provide a flexible framework for code management. So for those of us not at Oracle but would like to get some in depth knowledge on how to use 292 to its max, any thoughts of a Total Immersion Workshop for 292? I would gladly pay $$ for that. regards mark ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: MethodHandle.bindTo() only for reference types?
On 07/24/2012 09:02 PM, John Rose wrote:
> On Jul 24, 2012, at 11:09 AM, Attila Szegedi wrote:
>
>> I don't think technically there'd be a difficulty in having it
>> work on primitives, it's just that it ain't the intent; you still use
>> insertArguments() for uses that are not semantically "bind"s.
>
> MethodHandle.bind is a less-general primitive. The general API is
> insertArguments.
>
> Good 292 support for primitives requires a signature-polymorphic API.
>
> Therefore, we have been considering adding something like this, to
> fill functionality not covered by bind and insertArguments:
>
> class MethodHandle {
> /** Binds the given argument(s) to the method handle, but does not
> invoke it.
> * Arguments are not boxed, but rather passed in a
> signature-polymorphic call.
> * Requires an exact match to the corresponding leading parameter types.
> * Returns a method handle which accepts any remaining arguments,
> * and invokes the original on the combined argument lists.
> * Equivalent to insertArguments(this, 0, args), but may be more efficient.
> * Equivalent to this.bind(args[0]), but may be more efficient.
> */
> public final native MethodHandle invokePartial(Object… args) throws
> Throwable;
> }
>
> If we do, we will first experiment internally with it (as a non-public
> API).
invokePartial is in fact, invokedynamic + insertArguments +
insertArguments (to insert 0) + asType(asVarargCollector) + escape
analysis (to remove the array allocation and boxing).
I would prefer a way to gently ask the compiler to substitute a
classical Java call to an invokedynamic one.
The question is: are VMs able to do the escape analysis here or not.
BTW, invokePartial is important because it is the primitive needed when
you want to create a lambda that capture some values from the scope
so even Java will use it.
>
> — John
Rémi
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: MethodHandle.bindTo() only for reference types?
On Jul 24, 2012, at 11:09 AM, Attila Szegedi wrote:
> I don't think technically there'd be a difficulty in having it
> work on primitives, it's just that it ain't the intent; you still use
> insertArguments() for uses that are not semantically "bind"s.
MethodHandle.bind is a less-general primitive. The general API is
insertArguments.
Good 292 support for primitives requires a signature-polymorphic API.
Therefore, we have been considering adding something like this, to fill
functionality not covered by bind and insertArguments:
class MethodHandle {
/** Binds the given argument(s) to the method handle, but does not invoke it.
* Arguments are not boxed, but rather passed in a signature-polymorphic
call.
* Requires an exact match to the corresponding leading parameter types.
* Returns a method handle which accepts any remaining arguments,
* and invokes the original on the combined argument lists.
* Equivalent to insertArguments(this, 0, args), but may be more efficient.
* Equivalent to this.bind(args[0]), but may be more efficient.
*/
public final native Object invokePartial(Object… args) throws Throwable;
}
If we do, we will first experiment internally with it (as a non-public API).
— John___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: MethodHandle.bindTo() only for reference types?
The "bind" operation is traditionally used for taking an instance method (that takes an object instance as its 0th argument), and binding it to a specific instance. It's an admittedly minor semantic point. I don't think technically there'd be a difficulty in having it work on primitives, it's just that it ain't the intent; you still use insertArguments() for uses that are not semantically "bind"s. Attila. On Tue, Jul 24, 2012 at 6:36 AM, Aleksey Shipilev wrote: > Hi, > > I wonder if anyone could point to the explanation why MH.bindTo() is > accepting only reference types? This behavior seems surprising for > newcomers like me, mostly because similar API accepts primitive types. > For one, given: > > public static void foo(int i); > > ...and the MethodHandle mh referring to it, I can do: > MethodHandle mh2 = MethodHandles.insertArguments(mh, 0, (int)someInt) > > ...but this one is prohibited: > MethodHandle mh2 = mh.bindTo((int)someInt); > > Thanks, > -Aleksey. > > > ___ > 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
Re: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code
On 07/24/2012 07:15 PM, Christian Thalinger wrote: >> Not sure if this logic is applicable in this particular case. This is >> the potential "performance cliff" you are eager to get rid of with new >> implementation. > > No it's not. We know exactly what causes the performance cliff. It's a > completely unrelated issue in the VM. Sorry for misguided definition there, thought quoting does the trick for me. I was meant to say that the scalability bottlenecks like these pop out quickly, unexpected and hit hard. The difference between single-threaded and two-threaded versions could be so dramatic, so you can easily say it goes down the sink. It's inconvenient to fix one "cliff" and introduce the other, albeit "completely unrelated". -Aleksey. signature.asc Description: OpenPGP digital signature ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code
On Jul 24, 2012, at 2:55 AM, Aleksey Shipilev wrote: > On 07/23/2012 10:31 PM, John Rose wrote: >> On Jul 23, 2012, at 2:27 AM, Aleksey Shipilev wrote: >> The code does not need to be scalable, because the number of entries in >> the cache is small (order of 10-100) and scales only with type schema >> complexity, not workload complexity. > > If I had a nickel... > > Not sure if this logic is applicable in this particular case. This is > the potential "performance cliff" you are eager to get rid of with new > implementation. No it's not. We know exactly what causes the performance cliff. It's a completely unrelated issue in the VM. -- Chris > Given enough users and applications make use of this > code, someone will eventually step and burn on this. > > This wishful thinking "it's okay to use synchronized here, because this > couldn't possibly get contended" lead to many beautiful scalability > bottlenecks throughout the JDK. While it is usually a simple thing to > fix, I'm keen on not allowing to make the same mistakes over and over again. > >> So in this case, "static synchronized" is the correct choice. > > I shall wait for mainline integration to complete and then try to run > the microbenchmarks against the new backend; will see if this potential > issue is the practical one. > > -Aleksey. > > ___ > 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
MethodHandle.bindTo() only for reference types?
Hi, I wonder if anyone could point to the explanation why MH.bindTo() is accepting only reference types? This behavior seems surprising for newcomers like me, mostly because similar API accepts primitive types. For one, given: public static void foo(int i); ...and the MethodHandle mh referring to it, I can do: MethodHandle mh2 = MethodHandles.insertArguments(mh, 0, (int)someInt) ...but this one is prohibited: MethodHandle mh2 = mh.bindTo((int)someInt); Thanks, -Aleksey. signature.asc Description: OpenPGP digital signature ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code
On 07/23/2012 10:31 PM, John Rose wrote: > On Jul 23, 2012, at 2:27 AM, Aleksey Shipilev wrote: > The code does not need to be scalable, because the number of entries in > the cache is small (order of 10-100) and scales only with type schema > complexity, not workload complexity. If I had a nickel... Not sure if this logic is applicable in this particular case. This is the potential "performance cliff" you are eager to get rid of with new implementation. Given enough users and applications make use of this code, someone will eventually step and burn on this. This wishful thinking "it's okay to use synchronized here, because this couldn't possibly get contended" lead to many beautiful scalability bottlenecks throughout the JDK. While it is usually a simple thing to fix, I'm keen on not allowing to make the same mistakes over and over again. > So in this case, "static synchronized" is the correct choice. I shall wait for mainline integration to complete and then try to run the microbenchmarks against the new backend; will see if this potential issue is the practical one. -Aleksey. signature.asc Description: OpenPGP digital signature ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
