Re: two things invokedynamic canbot do
On 06/26/2012 02:24 PM, Jochen Theodorou wrote: > Am 26.06.2012 13:37, schrieb Julien Ponge: >> You may bypass the invokespecial (…)V as a first method >> invocation within a constructor requirement by launching the JVM with >> -noverify. As long as you don't do anything stupid in the bytecode it >> will be just ok and you can call a constructor using indy. >> >> Anyway I confess that disabling verification is probably not what you >> want ;-) > That is indeed not really what I want ;) No, seriously... we want to be > able to use Groovy classes in an environment not under our control, even > in a application server. For those things -noveriffy is surely no option. > > bye Jochen > BTW, It's usually better to use unsafe.defineClass() than noverify because you can just ask to not verify some classes. cheers, Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: two things invokedynamic canbot do
Am 26.06.2012 13:37, schrieb Julien Ponge: > You may bypass the invokespecial (…)V as a first method > invocation within a constructor requirement by launching the JVM with > -noverify. As long as you don't do anything stupid in the bytecode it > will be just ok and you can call a constructor using indy. > > Anyway I confess that disabling verification is probably not what you > want ;-) That is indeed not really what I want ;) No, seriously... we want to be able to use Groovy classes in an environment not under our control, even in a application server. For those things -noveriffy is surely no option. bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: two things invokedynamic canbot do
Am 26.06.2012 13:06, schrieb Rémi Forax: [...] (2) calling super() afaik I cannot generate a call site that replaces the invokeSpecial call to a super class constructor. >>> You can call super.foo() >> ah true... this is not reflection.. even if I get the handle from the >> super class it won't call the overriding method in the current class. I >> totally forgot... how do you handle this in your backport? > > I don't :( > > The current plan is to add an empty trampoline method in the code > by default and to redefine the code of this method when you create > a method handle that use invokespecial. > But it only works in agent mode not in reflection only mode. it works only in agent mode for you because you add the methods at "runtime" I guess. We let the compiler emit those, so we don't depend on an agent... but of course it means the bytecode is quite a bit larger than needed. Ah well.. [...] > For Dart, I don't generate Dart constructor as Java constructor, > I create public default Java constructor that just call super() > and translate the Dart constructor to a Java method. > > Then, a call to new is translated to an invokedynamic that will, > at runtime, fold the call to the Java constructor and the call to > the method that correspond to the Dart constructor. > > This allow me to workaround the VM limitation but > I don't allow any Dart to Java integration like being able > in Java to inherits from a Dart class. I see, well, that is no option for Groovy then. Too bad there is no other way around bye blackdrag -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: two things invokedynamic canbot do
You may bypass the invokespecial (…)V as a first method invocation within a constructor requirement by launching the JVM with -noverify. As long as you don't do anything stupid in the bytecode it will be just ok and you can call a constructor using indy. Anyway I confess that disabling verification is probably not what you want ;-) - Julien On Tuesday, June 26, 2012 at 11:59 AM, Rémi Forax wrote: > On 06/26/2012 11:40 AM, Jochen Theodorou wrote: > > Hi all, > > > > just to be sure I understand correctly... afaik there are two things > > invokedynamic cannot do. > > > > (1) calling private methods > > actually I am not sure this is really true. There is a Lookup instance I > > can use to get handles to private methods (afaik), therefore it should > > be possible. Or is there an artificial restriction of some kind? > > > > No restriction, or you need a way to get the proper lookup > or you use reflection to get a j.l.r.Method, call setAccessible(true) > and unreflect it as a MethodHandle (see MethodHandles.unreflect*). > > > > > (2) calling super() > > afaik I cannot generate a call site that replaces the invokeSpecial call > > to a super class constructor. > > > > You can call super.foo() but not super(). > It's because the VM verifies that you should not have access to an > uninitialized object, ie. access to an object before calling super(). > So if you do a super() using a MethodHandle, because it's hidden > by an invokedynamic (or a constant method handle) the VM as no > way to know that this invokedynamic will call the constructor > of the super class, so the verifier will not let you call invokedynamic > on this in a constructor without calling explicitly super() before. > > > > > Am I right about those? > > > > bye blackdrag > > Rémi > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net (mailto: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: two things invokedynamic canbot do
On 06/26/2012 12:37 PM, Jochen Theodorou wrote: > Am 26.06.2012 11:59, schrieb Rémi Forax: >> On 06/26/2012 11:40 AM, Jochen Theodorou wrote: >>> Hi all, >>> >>> just to be sure I understand correctly... afaik there are two things >>> invokedynamic cannot do. >>> >>> (1) calling private methods >>> actually I am not sure this is really true. There is a Lookup instance I >>> can use to get handles to private methods (afaik), therefore it should >>> be possible. Or is there an artificial restriction of some kind? >> No restriction, or you need a way to get the proper lookup >> or you use reflection to get a j.l.r.Method, call setAccessible(true) >> and unreflect it as a MethodHandle (see MethodHandles.unreflect*). > ok, so I can remove those stupid helper methods ;) > >>> (2) calling super() >>> afaik I cannot generate a call site that replaces the invokeSpecial call >>> to a super class constructor. >> You can call super.foo() > ah true... this is not reflection.. even if I get the handle from the > super class it won't call the overriding method in the current class. I > totally forgot... how do you handle this in your backport? I don't :( The current plan is to add an empty trampoline method in the code by default and to redefine the code of this method when you create a method handle that use invokespecial. But it only works in agent mode not in reflection only mode. > > > but not super(). >> It's because the VM verifies that you should not have access to an >> uninitialized object, ie. access to an object before calling super(). >> So if you do a super() using a MethodHandle, because it's hidden >> by an invokedynamic (or a constant method handle) the VM as no >> way to know that this invokedynamic will call the constructor >> of the super class, so the verifier will not let you call invokedynamic >> on this in a constructor without calling explicitly super() before. > I see... that is a bit unfortunate. I have to do quite some tricks to > enable the super constructor call according to Groovy rules for method > dispatch. And what I do I won't call fast. For Dart, I don't generate Dart constructor as Java constructor, I create public default Java constructor that just call super() and translate the Dart constructor to a Java method. Then, a call to new is translated to an invokedynamic that will, at runtime, fold the call to the Java constructor and the call to the method that correspond to the Dart constructor. This allow me to workaround the VM limitation but I don't allow any Dart to Java integration like being able in Java to inherits from a Dart class. > > bye blackdrag > ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: two things invokedynamic canbot do
Am 26.06.2012 11:59, schrieb Rémi Forax: > On 06/26/2012 11:40 AM, Jochen Theodorou wrote: >> Hi all, >> >> just to be sure I understand correctly... afaik there are two things >> invokedynamic cannot do. >> >> (1) calling private methods >> actually I am not sure this is really true. There is a Lookup instance I >> can use to get handles to private methods (afaik), therefore it should >> be possible. Or is there an artificial restriction of some kind? > > No restriction, or you need a way to get the proper lookup > or you use reflection to get a j.l.r.Method, call setAccessible(true) > and unreflect it as a MethodHandle (see MethodHandles.unreflect*). ok, so I can remove those stupid helper methods ;) >> (2) calling super() >> afaik I cannot generate a call site that replaces the invokeSpecial call >> to a super class constructor. > > You can call super.foo() ah true... this is not reflection.. even if I get the handle from the super class it won't call the overriding method in the current class. I totally forgot... how do you handle this in your backport? > but not super(). > It's because the VM verifies that you should not have access to an > uninitialized object, ie. access to an object before calling super(). > So if you do a super() using a MethodHandle, because it's hidden > by an invokedynamic (or a constant method handle) the VM as no > way to know that this invokedynamic will call the constructor > of the super class, so the verifier will not let you call invokedynamic > on this in a constructor without calling explicitly super() before. I see... that is a bit unfortunate. I have to do quite some tricks to enable the super constructor call according to Groovy rules for method dispatch. And what I do I won't call fast. bye blackdrag -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/jdk: meth: fix broken cache
Changeset: 7f23289ab8a8 Author:jrose Date: 2012-06-26 02:52 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/7f23289ab8a8 meth: fix broken cache ! meth-lazy-7023639.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: two things invokedynamic canbot do
Hi blackdrag, Private methods can be called - providing you have a lookup object that was constructed (via MethodHandles.lookup() ) in a context which can see the private method. The point of the lookup mechanism is to provide the capability to selectively give access to private methods, without breaking the whole of access control or upsetting security managers. The use of lookup moves the access control check to method handle (or lookup) creation time, rather than method invocation time. Thanks, Ben On Tue, Jun 26, 2012 at 10:40 AM, Jochen Theodorou wrote: > Hi all, > > just to be sure I understand correctly... afaik there are two things > invokedynamic cannot do. > > (1) calling private methods > actually I am not sure this is really true. There is a Lookup instance I > can use to get handles to private methods (afaik), therefore it should > be possible. Or is there an artificial restriction of some kind? > > (2) calling super() > afaik I cannot generate a call site that replaces the invokeSpecial call > to a super class constructor. > > Am I right about those? > > bye blackdrag > > > -- > Jochen "blackdrag" Theodorou - Groovy Project Tech Lead > blog: http://blackdragsview.blogspot.com/ > german groovy discussion newsgroup: de.comp.lang.misc > For Groovy programming sources visit http://groovy-lang.org > > > ___ > 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: two things invokedynamic canbot do
On 06/26/2012 11:40 AM, Jochen Theodorou wrote: > Hi all, > > just to be sure I understand correctly... afaik there are two things > invokedynamic cannot do. > > (1) calling private methods > actually I am not sure this is really true. There is a Lookup instance I > can use to get handles to private methods (afaik), therefore it should > be possible. Or is there an artificial restriction of some kind? No restriction, or you need a way to get the proper lookup or you use reflection to get a j.l.r.Method, call setAccessible(true) and unreflect it as a MethodHandle (see MethodHandles.unreflect*). > > (2) calling super() > afaik I cannot generate a call site that replaces the invokeSpecial call > to a super class constructor. You can call super.foo() but not super(). It's because the VM verifies that you should not have access to an uninitialized object, ie. access to an object before calling super(). So if you do a super() using a MethodHandle, because it's hidden by an invokedynamic (or a constant method handle) the VM as no way to know that this invokedynamic will call the constructor of the super class, so the verifier will not let you call invokedynamic on this in a constructor without calling explicitly super() before. > > Am I right about those? > > bye blackdrag > > Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/jdk: rebase
Changeset: 7897d571c685 Author:jrose Date: 2012-06-26 02:54 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/7897d571c685 rebase ! meth-lazy-7023639.xbmh.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: meth: compiled MH paths work in C1 (unit tests except PermuteArgsTest)
Changeset: 2a77b30743df Author:jrose Date: 2012-06-26 02:40 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/2a77b30743df meth: compiled MH paths work in C1 (unit tests except PermuteArgsTest) ! meth-lazy-7023639.jit.patch ! meth-lazy-7023639.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
two things invokedynamic canbot do
Hi all, just to be sure I understand correctly... afaik there are two things invokedynamic cannot do. (1) calling private methods actually I am not sure this is really true. There is a Lookup instance I can use to get handles to private methods (afaik), therefore it should be possible. Or is there an artificial restriction of some kind? (2) calling super() afaik I cannot generate a call site that replaces the invokeSpecial call to a super class constructor. Am I right about those? bye blackdrag -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
