Re: Good news, bad news
Am 26.05.2011 11:03, schrieb Christian Thalinger: [...] > I looked at the inlining tree of fib and everything looks good and is > inlined. There is one invokeExact which is: > > @ 43 java.lang.invoke.MethodHandle::invokeExact (42 bytes) too > big > > but bumping the MaxInlineSize just shows that it's: > > @ 43 java.lang.invoke.MethodHandle::invokeExact (42 bytes) call > site not reached > > so it doesn't matter anyway. sorry for gutting in here. Is that looking at the inlining tree something normal mortals can also do? I see there some useful information, even without invokedynamic. So is this some debugging code not found in the normal JVM? bye Jochen ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: MethodHandle lookup&invocation performance
Am 09.07.2011 10:48, schrieb Hiroshi Nakamura: > Hello, > > I heard that jsr292 makes dynamic method lookup&invocation faster than > reflection so I did some performance comparison against plain > reflection. I'm sending this mail since the result looks strange to > me. > > Code is here: > https://raw.github.com/nahi/jsr292-sandbox/master/src/jp/gr/java_conf/jruby/MethodHandleTest.java lookup I don't know. I am not sure about the recent versions, I think the lookup is using the same "core" as Reflection plus additional checks. I don't expect that to be faster. It would be very nice though. The performance of the invocation cannot be meassured like you do it I think. The big pro comes from the ability to inline the method calls, but this is only present if you use the invokedynamic bytecode instruction. There is currently no way in Java to express invokedynamic. And a third point... even if there where invokedynamic used, I think in your case it would not really bring forth the real performance possibilities, since your receiver is changing all the time. But in general I must say, I would have expected the performance to be at least near Reflection as well. I mean the situation is for Reflection not all that better. bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead http://blackdragsview.blogspot.com/ For Groovy programming sources visit http://groovy.codehaus.org ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Process-level fork on OpenJDK...is it madness?
Am 29.11.2011 22:32, schrieb Mark Roos: [...] > I just finished a paper (link below) on JVM startup time which states > that for small programs its around > 70ms. So I assume there is some other startup time you are trying to > improve? Or is the > paper not applicable to the launching of a new process as you describe it? For the JVM itself that might be true, but in case of for example Groovy there is a lot if init work to be done before the first program can be executed. And this takes time. 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: Process-level fork on OpenJDK...is it madness?
Am 29.11.2011 23:34, schrieb Thomas Wuerthinger: > On 11/29/11 11:22 PM, Jochen Theodorou wrote: >> Am 29.11.2011 22:32, schrieb Mark Roos: >> [...] >>> I just finished a paper (link below) on JVM startup time which states >>> that for small programs its around >>> 70ms. So I assume there is some other startup time you are trying to >>> improve? Or is the >>> paper not applicable to the launching of a new process as you describe it? >> For the JVM itself that might be true, but in case of for example Groovy >> there is a lot if init work to be done before the first program can be >> executed. And this takes time. >> >> bye Jochen > What kind of initialization work is this? Could the result of that work > be cached? we have to setup the initial meta class system, which requires to use reflection to inspect some classes and other work. Yes, this could be cached, if we would know how. 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: Process-level fork on OpenJDK...is it madness?
Am 30.11.2011 14:02, schrieb Rémi Forax: [...] >>> What kind of initialization work is this? Could the result of that work >>> be cached? >> we have to setup the initial meta class system, which requires to use >> reflection to inspect some classes and other work. Yes, this could be >> cached, if we would know how. > > It worth to give a try to java.lang.ClassValue, here. > You you be able to create your metaclass only when needed. > > Also note that you can also lazyly initialize the list of methods, > fields etc. because even if two threads ask the same list at the > same time, the result will be the same, so there is no need > to use synchronized here. > (this is exactly what java.lang.Class code does) : it is all lazy, but what gives it if you need it for even the most simple script? For println 1+1 you will need the a meta class for the current class, you will need the int meta class, you will need to load the default methods too... and one second is burnt. 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: Process-level fork on OpenJDK...is it madness?
Am 01.12.2011 00:35, schrieb Rémi Forax: [...] > The only way I see to avoid that is to not load the meta-class > until someone reference them so you can compile this example > to System.out.println(2) and if there is a ref to a meta-class somewhere, > discard the code and recompile it with meta-class check. In my example it is more that I have to compile against groovy.lang.Script#println, but anyway... in the general case it is afaik impossible to compile directly if I have a x.y(a,b) in Groovy. Only in certain special cases this is different. And if I cannot go the direct path, I need the meta class. For my primitive opts in 1.8 I wanted to be able to run a program, that does only calculations and internal method calls, to be able to run without any meta class being loaded. I think I didn't succeed fully... time did run out kind of. > I do something like that in PHP.reboot but my unit of compilation > is the method and not the class, which also avoid to compile a > code you never use. true 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
invokedynamic and error messages
Hi all,
I noticed some of the error message are a bit strange. For example I was
going to use bindTo for a boolean, but primitives are not allowed. The
error message I then get is:
no leading reference parameter
Which makes no sense at all. Looking at the code:
if (type().parameterCount() == 0 ||
(ptype = type().parameterType(0)).isPrimitive())
throw newIllegalArgumentException("no leading reference
parameter", x);
I see where it comes from, but "reusing" that instead of making a new if
is not really needed, is it?
Do people here agree this should be improved?
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: invokedynamic and error messages
Am 06.01.2012 17:22, schrieb John Rose: > On Jan 6, 2012, at 4:57 AM, Jochen Theodorou wrote: > >> I see where it comes from, but "reusing" that instead of making a new if >> is not really needed, is it? >> >> Do people here agree this should be improved? > > The javadoc for this throw is: > * @throws IllegalArgumentException if the target does not have a > * leading parameter type that is a reference type > > Therefore, I suppose the message could be, "The target does not have a > leading parameter type that is a reference type". > > The current message is supposed to be an abbreviation of that sentence. > Perhaps it is excessively optimized for space. I think the current message is shortened a bit too much, this one would have helped much more. If space is such a big requirement, then it can stay as it is of course. Regardless the unclear message I found the reason quite fast ;) Which reminds me of a question though... why am I not allowed to use bindTo to bind a primitive? 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
[jvm-l] JVM cannot find invoker
Hi all, after some modifications to my code I suddenly got this exception: > java.lang.InternalError: JVM cannot find invoker for > (CompilationUnit,TreeNodeBuildingNodeOperation,int)Object > at java.lang.invoke.Invokers.lookupInvoker(Invokers.java:91) > at java.lang.invoke.Invokers.exactInvoker(Invokers.java:73) > at java.lang.invoke.MethodHandles.exactInvoker(MethodHandles.java:1371) > at > java.lang.invoke.MethodHandleImpl.makeGuardWithTest(MethodHandleImpl.java:1072) > at java.lang.invoke.MethodHandles.guardWithTest(MethodHandles.java:2162) > at > org.codehaus.groovy.vmplugin.v7.IndyInterface.setGuards(IndyInterface.java:424) > at > org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:545) I am not understanding the error and I hope somebody here can help me with that. What does this mean? The guard I want to use here is a bound method handle, with the resulting handle having no arguments. Is that not allowed? by 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: [jvm-l] JVM cannot find invoker
Am 31.01.2012 23:20, schrieb Jochen Theodorou: > Hi all, > > after some modifications to my code I suddenly got this exception: >> java.lang.InternalError: JVM cannot find invoker for >> (CompilationUnit,TreeNodeBuildingNodeOperation,int)Object >> at java.lang.invoke.Invokers.lookupInvoker(Invokers.java:91) >> at java.lang.invoke.Invokers.exactInvoker(Invokers.java:73) >> at java.lang.invoke.MethodHandles.exactInvoker(MethodHandles.java:1371) >> at >> java.lang.invoke.MethodHandleImpl.makeGuardWithTest(MethodHandleImpl.java:1072) >> >> at java.lang.invoke.MethodHandles.guardWithTest(MethodHandles.java:2162) >> at >> org.codehaus.groovy.vmplugin.v7.IndyInterface.setGuards(IndyInterface.java:424) >> >> at >> org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:545) >> > > I am not understanding the error and I hope somebody here can help me > with that. What does this mean? The guard I want to use here is a bound > method handle, with the resulting handle having no arguments. Is that > not allowed? I found a possible hint... TreeNodeBuildingNodeOperation is a private class. What do I have to do again to get access to that class? 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: [jvm-l] JVM cannot find invoker
Am 02.02.2012 12:21, schrieb Jochen Theodorou: > Am 01.02.2012 12:38, schrieb Rémi Forax: > [...] >> This is weird, >> All tests but one in UberTestCaseJavaSourceGroovyPackagesSecurity pass >> for me, >> with jdk7u2 and jdk8b23. > > I guess I will try jdk8b23 next and hope the bug vanishes over time > somehow But if that also does not work... so... now I am stuck... jdk8b23 has the problem too and I have Cedric confirming the same bug on his machine for jdk7u2 and for 1.7.0_147-icedtea Looks like I will have to fill my very first JVM bug report 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: [jvm-l] JVM cannot find invoker
Am 02.02.2012 14:37, schrieb Christian Thalinger: > > On Feb 2, 2012, at 2:34 PM, Jochen Theodorou wrote: > >> Am 02.02.2012 12:21, schrieb Jochen Theodorou: >>> Am 01.02.2012 12:38, schrieb Rémi Forax: >>> [...] >>>> This is weird, >>>> All tests but one in UberTestCaseJavaSourceGroovyPackagesSecurity pass >>>> for me, >>>> with jdk7u2 and jdk8b23. >>> >>> I guess I will try jdk8b23 next and hope the bug vanishes over time >>> somehow But if that also does not work... >> >> so... now I am stuck... jdk8b23 has the problem too and I have Cedric >> confirming the same bug on his machine for jdk7u2 and for 1.7.0_147-icedtea >> >> Looks like I will have to fill my very first JVM bug report > > Do you have a test case you can share? you can use this: https://github.com/groovy/groovy-core/tree/indy If you run "ant clean test" the tests will fail with several errors, about 20 of them are because of a single place that is causing the internal error btw, it seems the error appears on 32bit as well as 64bit JVMs. Every help is very much appreciated. 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: [jvm-l] JVM cannot find invoker
Am 02.02.2012 19:40, schrieb Jochen Theodorou: [...] > Every help is very much appreciated. On further investigation the error seems really to be related to one of the parameters being an instance of a class with a private modifier set. The key point in that is maybe that the class is not an inner class. Normal Java doesn't allow for this kind of class afaik. The JVM seemed not to have a problem with this before, but indy seems to have. If I read the spec right the private modifier should not be allowed 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: [jvm-l] JVM cannot find invoker
Am 02.02.2012 21:02, schrieb Jochen Theodorou: > Am 02.02.2012 19:40, schrieb Jochen Theodorou: > [...] >> Every help is very much appreciated. > > On further investigation the error seems really to be related to one of > the parameters being an instance of a class with a private modifier set. > The key point in that is maybe that the class is not an inner class. > Normal Java doesn't allow for this kind of class afaik. The JVM seemed > not to have a problem with this before, but indy seems to have. > > If I read the spec right the private modifier should not be allowed another update on this... seems like this happens also if the classes with the private modifier set are package private. If I assume the private modifier was just ignored before then this makes perfectly sense, since the class was then package private for indy. But afaik package private should be allowed and seems not to be. 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
problem with vargs method
Hi all, maybe someone can explain to me why method handles behave this way in my case. Bascially I have a handle for Class#getDeclaredConstructor(Class...) I created via unreflect. http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getDeclaredConstructor%28java.lang.Class...%29 this handle is then created as a AdapterMethodHandle$AsVargsCollector. My targetType is Object(Object,Object) and the arguments to the call are the Class, and an empty Class[]. So the next steps are asType with the target type, adding a guard with catch, then my guards for the arguments and last I do an invokeWithArguments. What I get now is a ClassCastException with the message required class java.lang.Class but encountered class [Ljava.lang.Class; The guards are unrelated to the problem, since it happens without them as well. Now can anyone explain me why I get that exception? It doesn't really make sense to me atm. 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: problem with vargs method
The problem can be easily reproduced using this: > MethodType type = MethodType.methodType(Constructor.class, > Class[].class); > MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class, > "getDeclaredConstructor", type); > MethodType target = MethodType.methodType(Object.class, Object.class, > Object.class); > mh = mh.asType(target); > mh.invokeWithArguments(Class.class,new Class[0]); can someone tell me the mistake? bye Jochen Am 07.02.2012 17:04, schrieb Jochen Theodorou: > Hi all, > > maybe someone can explain to me why method handles behave this way in my > case. > > Bascially I have a handle for Class#getDeclaredConstructor(Class...) I > created via unreflect. > > http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getDeclaredConstructor%28java.lang.Class...%29 > > this handle is then created as a AdapterMethodHandle$AsVargsCollector. > My targetType is Object(Object,Object) and the arguments to the call are > the Class, and an empty Class[]. So the next steps are asType with the > target type, adding a guard with catch, then my guards for the arguments > and last I do an invokeWithArguments. > > What I get now is a ClassCastException with the message required class > java.lang.Class but encountered class [Ljava.lang.Class; > > The guards are unrelated to the problem, since it happens without them > as well. > > Now can anyone explain me why I get that exception? It doesn't really > make sense to me atm. > > 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: problem with vargs method
Am 07.02.2012 17:29, schrieb Jim Laskey: MethodType type = MethodType.methodType(Constructor.class, Class[].class); MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class, "getDeclaredConstructor", type); MethodType target = MethodType.methodType(Object.class, Object.class, Object.class); mh = mh.asType(target); mh.invokeWithArguments(Class.class,new Class[0]); > > As soon as you mh = mh.asType(target); it is no longer vararg, so it > is treating new Class[0] as the second argument cast to Object. If > you are trying to type as (Object , Object[]). I think you are going > to run into difficulties validating (Class[]) Object[]. You may have > to add a wrapper to get what you want, but you could also try using > asCollector. or in other words: I should not use invokeWithArguments for this. If I wanted to use the same target type... since that is what my call site gives me... and I wanted to use invokeExact instead, how would I have to change the program? 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: problem with vargs method
That will produce a java.lang.invoke.WrongMethodTypeException: (Ljava/lang/Object;[Ljava/lang/Object;)V cannot be called without a receiver argument as ([Ljava/lang/Object;)Ljava/lang/Object; imho casting to Object and Object[] in mh.invokeExact((Object)Class.class, (Object[])new Class[0]); is without effect, since invokeExact is a vargs method an everything will just be put into an Object[] anyway. We had not a compiler change for this kind of thing, had we? bye Jochen Am 07.02.2012 17:52, schrieb Jim Laskey: > Try > > MethodType type = MethodType.methodType(Constructor.class, > Class[].class); > MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class, > "getDeclaredConstructor", type); > MethodType target = MethodType.methodType(void.class, Object.class, > Object[].class); > mh = MethodHandles.explicitCastArguments(mh, target); > mh.invokeExact((Object)Class.class, (Object[])new Class[0]); > > Cheers, > > -- Jim > > On 2012-02-07, at 12:37 PM, Jochen Theodorou wrote: > >> Am 07.02.2012 17:29, schrieb Jim Laskey: >>>>>> MethodType type = MethodType.methodType(Constructor.class, >>>>>> Class[].class); >>>>>> MethodHandle mh = >>>>>> MethodHandles.lookup().findVirtual(Class.class, >>>>>> "getDeclaredConstructor", type); >>>>>> MethodType target = MethodType.methodType(Object.class, >>>>>> Object.class, Object.class); >>>>>> mh = mh.asType(target); >>>>>> mh.invokeWithArguments(Class.class,new Class[0]); >>> >>> As soon as you mh = mh.asType(target); it is no longer vararg, so it >>> is treating new Class[0] as the second argument cast to Object. If >>> you are trying to type as (Object , Object[]). I think you are going >>> to run into difficulties validating (Class[]) Object[]. You may have >>> to add a wrapper to get what you want, but you could also try using >>> asCollector. >> >> or in other words: I should not use invokeWithArguments for this. >> >> If I wanted to use the same target type... since that is what my call site >> gives me... and I wanted to use invokeExact instead, how would I have to >> change the program? >> >> 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 >> > -- 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: problem with vargs method
Am 07.02.2012 18:29, schrieb Jim Laskey: > Worked okay for me. So must be addressed in a later release. :-/ later than jdk7u2? oh boy. I would feel better if I could find a bug report that shows the problem and that is resolved. Then I would at least have something for the release notes. But I didn't find anything that looks fitting. The only one that seems to be slightly fitting was fixed a year ago and surely that fix is part of jdk7u2 already. You said for > MethodType type = MethodType.methodType(Constructor.class, Class[].class); > MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class, > "getDeclaredConstructor", type); > MethodType target = MethodType.methodType(Object.class, Object.class, > Object.class); > mh = mh.asType(target); > mh.invokeWithArguments(Class.class,new Class[0]); I probably have to wrap something... can you explain what you mean? 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
Question about inlining caching by Hotspot and classes implementing an method from an interface
Hi all,
I have the feeling we have talked about this already, but I couldn't
really find it and back then it was independend of invokedynamic...
Anyway...
Assuming I have an interface Foo with a void method foo(). And assuming
I have the class Bar0, Bar1 to BarN implementing that interface. Let us
assume further I have code like this:
method(bar0)
method(bar1)
...
method(barN)
where bar0,bar1,..., barN are instance of the corresponding Bar classes
and method is more or less this:
void method(Foo f){f.foo();}
I was thinking about how I would have to implement the call site checks
for this case in invokedynamic in that method and the current approach
would be to check for the implementation class, meaning BarX and meaning
also to have an invalidation and reselection of the method each time
method is called. This is surely not the optimal case. It surely would
be better to check that f implements Foo... well or in the case here we
can simply forget that check on the receiver... if that where
reflection. But I think that does not work with MethodHandles I think. I
guess I will need the reference to the implementation method instead and
then also a guard for the receiver. Am I wrong? IS there a way around?
THis thought did lead me to another question how does the JVM do
this for the pure bytecode case? Wouldn't the JVM do mostly the same? I
mean add a receiver check for the implementation class, just to
invalidate this site for each of the calls to method? Or how is it done
there?
bye Jochen
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Boxing, still a limit of invokedynamic?
Hi all,
I wanted to ask you of your opinion. If I am going to compile something
like a+b-c and a,b,c are all primtives, but I won't know that the
results will be really the primtives too, then this means I will most
probably compile it like this:
invokedynamic("minus", invokedynamic("plus",a,b), c)
meaning the result of a+b will be an Object (since I won't know it is a
primitive) and then there will be one boxing for that, just to unbox
again for the minus and then box again for the result of the minus. If
now the result is not supposed to be a primitive, then there won't be
another unbox, till the next operation done with that value.
Now, even if the JIT is able to see through the one boxing and unboxing
fro the result of plus, what will stay is the boxing for the result of
the minus plus the many unboxing actions used when this result is
used. Isn't that a conceptual problem? And how do others deal with that?
I am asking because I was experimenting with method signatures and for
such plus and minus methods and got mixed results. I was expecting the
primtive versions would achieve the best results, but that was not the
case. a plus(int, int) had worse performance than a plus(int,Integer) or
plus(Integer,int) in some cases and sometimes it looked like
plus(Integer,Integer) is worse, in other cases not. Well, this is
causing me some problems. Why do I get such strange results? I would
assume it depends on the JIT and the boxing logic it is able to
recognize and not.
One more thing I noticed is, that if I have a = b+c, with all of them
being int and b+c returning object, then letting the MethodHandle do the
conversion from Object to int is actually much worse performance wise,
than a cast to integer and calling valueOf. Shouldn't that be at least
equal, if not fast considering that the result of b+c was first boxed
and then is unboxed?
Can anyone give me some advice on how to do these things?
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: Boxing, still a limit of invokedynamic?
Am 13.05.2012 19:21, schrieb Charles Oliver Nutter: [...] > You could also encode "a+b-c" as a single invokedynamic operation, but > I guess you're looking for a general solution... yes, I am looking for a general solution. I was thinking of making the whole expression as a MethodHandle combination, which then has a,b,c as input arguments... but that's a pretty big step to do. I don't want to spend months in changing the compiler just to find it doesn't give me the performance I am looking for. Plus this approach has its own problems with evaluation order and such. [...] > First of all...how are you expecting that JIT will see through the > first boxing? If the return result is going to be Object, it's going > to go into an Integer. Perhaps you are hoping for escape analysis to > get rid of it? I don't know what part it does, but I assume EA is right. > If that's the case, why wouldn't the same expectation apply to the > second call? If (a+b) returns an Integer that's immediately passed > into (tmp-c) and both calls inline, in theory EA should have enough to > eliminate the intermediate. If the result of (tmp-c) is never used as > an object and never escapes, then EA should be able to get rid of that > too. well.. in my example the result of tmp-c is returned, so it escapes. But even if I only store it in a bytecode slot... I mean I wouldn't EA expect to even optimize these cases on further thought though it might be possible. > Of course this is all assuming that EA will be working across indy > boundaries in the near future. Currently, it does not. Indeed, I was kind of assuming that. You telling me it does not makes some results much clearer to me. The question then is... should I wait for EA working across indy boundaries? And when would that be available? [...] > A confusing point for me: in your case, where you know they're all > ints, how do you not know that + and - also return int? Can't you > determine statically that this whole expression will return a > primitive int? I may not have written that part clearly enough. We don't know that + and - return int. You may vagualy remember my JVM talk 2 years ago in which I explained how I plan to make a primitive optimization path. In this path the compiler will indeed assume that a+b will return an int and will then emit iadd instead of using static method calls or any other helpers. This optimized path has basically the same performance as Java in the best case, but it is guarded, which reduces the performance to half of Java speed in the best case. The problem is that prim opts cannot handle more complex cases and it is really easy to turn them off... That plus the problem of almost doubling the method bytecode make them a sub optimal solution. But it is one indy has to compete with. >> I am asking because I was experimenting with method signatures and for >> such plus and minus methods and got mixed results. I was expecting the >> primtive versions would achieve the best results, but that was not the >> case. a plus(int, int) had worse performance than a plus(int,Integer) or >> plus(Integer,int) in some cases and sometimes it looked like >> plus(Integer,Integer) is worse, in other cases not. Well, this is >> causing me some problems. Why do I get such strange results? I would >> assume it depends on the JIT and the boxing logic it is able to >> recognize and not. > > What does the assembly look like? you mean the compiled code? I will try to give examples of this later. But if > And again remember...I don't think the JIT in u4- does anything with > the boxing coming out of these calls. It might do something on the > other side, but not across the invokedynamic call. is right, then it is no wonder, that one time this and another time that is faster. But I suspect it is worse. It is not only across indy calls, that the JIT does nothing with boxing, I assume it is even across MethodHandles in the same indy call. To be more exact with my suspecion, I expect a constant int boxed by an MethodHandle and then unboxed by another one in the same indy call to be slower, than just returning the int itself. If I have a+1, then the ideal plus is one that takes int,int and returns Integer, because that way everything can happen inside the invokeddynamic part. if I have a=a+1 (a being an int) then plus(int,int):int is probably better, but using the one from before and unboxing the Integer to int is not. And depending from where your results are coming from you get better performance by using plus(Integer,int) plus(int,Integer) and plus(Integer,Integer)... with different return types probably as well. >> One more thing I noticed is, that if I have a = b+c, with all of them >> being int and b+c returning object, then letting the MethodHandle do the >> conversion from Object to int is actually much worse performance wise, >> than a cast to integer and calling valueOf. Shouldn't that be at least >> equal, if not as f
Re: Boxing, still a limit of invokedynamic?
Am 13.05.2012 19:55, schrieb Rémi Forax: [...] > I think currently Groovy allows to replace + by a method > that will return everything you want. > But here, I think the spec of Groovy (if it means something) > should be changed to say that when your replace a method > by another, the return type must be a subtype of the > existing method. that helps if the argument types are known and there is an exact match to a method. It helps because in that case we can save the casting and converting plus the checks to see if we even have to do that. Yes. But currently that is not the case. And it won't change for Groovy2, maybe for a later Groovy. [...] > Object -> int is not equivalent to Object -> Integer -> int, > it can be Object -> Byte -> int by example. > You have to chain several calls to asType() > > see slide 20 of my jvm summit talk last year, > http://wiki.jvmlangsummit.com/images/9/93/2011_Forax.pdf so you mean to tell me that I have first to convert the Object to an Integer and that Integer to int, instead of directly converting the Object to an int? I see, I will try that out. bye Jochen ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Boxing, still a limit of invokedynamic?
Am 14.05.2012 01:16, schrieb Mark Roos: [...] > So I decided that all my ints will be boxed (references), added a cache > and some special prim > methods for now and then follow Charles approach of a good indy design > to take advantage > of the optimization efforts. Based on my large scale benchmarks this is > ok so I am focusing > on other places to optimize. This also supports my automatic conversion > to/from BigInts. > > Log term I am guessing that I will follow your path of special paths > with guards, Unless I can > get the performance I want with more cores. the special paths with guards in bytecode is actually a thing I was hoping to get rid of with indy. The current state of the implementation of indy in Groovy is, that it is slightly better than our call site caching and worse than our prim opts. In total that means, unless I combine indy with prim opts the indy versions is in general a tiny bit slower, since even the small advantage over call site caching is not always there. And call site caching in Groovy means we operate with at runtime generated classes, with call sites, that are mostly not inlined and other problems. Indy has the potential to be faster than that. Only in reality I am missing that extra of performance. And that is a bit sad. We had recently another 2.0 beta and a day later we had already people complaining why the indy version is not faster. I mean, if I find other places to optimize, then call site caching will profit from that as well, not giving indy the real advantage here. I am worried about indy getting a bad image here. 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: Boxing, still a limit of invokedynamic?
Am 14.05.2012 08:55, schrieb Rémi Forax: [...] >> so you mean to tell me that I have first to convert the Object to an >> Integer and that Integer to int, instead of directly converting the >> Object to an int? I see, I will try that out. > > Yes. > You should not have to do that because you first check if the > parameter is an Integer but currently the VM doesn't propagate > this information. > (there is a patch for that, but not yet integrated) > Also, it should be faster before the JIT is kicked in. That it is slower at first is ok. Only I kind of assumed, that such things can be optimized away. The less the JIT can optimize, the more I have to do that and work around the limitations, making my runtime more complex. And with the next JVM update all that work might be for nothing. 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: Boxing, still a limit of invokedynamic?
Am 14.05.2012 17:19, schrieb Charles Oliver Nutter: > On Mon, May 14, 2012 at 4:32 AM, Jochen Theodorou wrote: >> That it is slower at first is ok. Only I kind of assumed, that such >> things can be optimized away. The less the JIT can optimize, the more I >> have to do that and work around the limitations, making my runtime more >> complex. And with the next JVM update all that work might be for nothing. > > This is a key point you will have to weigh. > > You want to have Groovy 2.0 released by this fall, with invokedynamic > support. This fall? Ahem... ideally it would have been out already by now ;) If possible 1 month only is left that is late enough > It's certainly possible that your uses of invokedynamic have > not gotten the optimization love they need, and that your results > won't be to your liking until that happens. that might be, but I find some quite basic things that I really wonder if they are not really of relevance for your cases. The boxing issues I can understand, but that performance drops so drastically (it halves) once you use a catch guard is something I find strange... you are not using that one? > Getting JRuby + > invokedynamic to work well was the product of several months of > back-and-forth between me and the Hotspot guys, tossing assembly dumps > around, tweaking inlining budgets, trying out new optimization > strategies. The initial performance was terrible, but we all > persevered and I continued to wire things up and play with handles. > Ultimately we (well, mostly the Hotspot guys) worked out all (well, > almost all) of the performance issues I saw; that would not have > happened without a lot of back-and-forth. Yes the question is only if they are as eager on supporting my stuff. Nothing against John and all the other Hotspot guys, really, but their time is at least as limited as mine. [...] > And when you get to that point and can't figure out why the assembly > for your indy stuff is more complicated than the assembly for the > non-indy logic, we can help you decide if it's a JVM issue or a Groovy > issue :) well, if you offer to help, I take you by your word ;) > My attitude has been this: > > 1. I assume invokedynamic should be fast. > 2. If it's not, either I'm doing something wrong or the JVM's doing > something wrong. > 3. We figure out which one it is and fix it. yes, that is my approach as well, but you can see on the feedback on my catch exception guard problem, that this doesn't mean I will ever get to a fix in the JVM. It may happen or not... depending on the available time slots. Or maybe I should rant more ? ;) 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
performance degeneration from jdk7u2 to jdk7u6?
Hi all, I was about to get a brand new assembly to ask some questions on the list here when I installed the newest available jdk7 update 6. I ran my simple Fibonacci test program and noticed that the time it took was sudden 4.6s, where it was 3.5s before. This plus 1s doesn't look too god to me. Has there been anything special that causes this? I mean before the indy version was a little faster than our call site caching, now it is a little slower. General java performance seems not to be reduced, so I would assume it is special to indy. See http://rifers.org/paste/show/1702 ... so now... is there sombody who can tell me why my indy version is now even slower than my call site version? Sadly I am not really fit enough in assembler anymore, especially the one produced by hotspot to really read that output. So I have no idea what is wrong. Two things I should mention... the call to $getCallSiteArray is surplus, yes, but that doesn't take much time. The only thing I know that really takes a lot of time is the exception guard, but that I have to have until I find a way to avoid it and the call site version has both as well of course. They should not count as satisfying explanation. 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: performance degeneration from jdk7u2 to jdk7u6?
Am 21.05.2012 07:34, schrieb Mark Roos: > Hi Jochen > > I ran into a similar issue ( between versions within jdk8 ) where the > default compile > mode had changed to tieredCompile. This made the benchmark timing > inconsistent. > > I have learned to look closely at the defaults and have moved to > specifying quite > a few in my batch files. how can you see the defaults? and how can you change to the "old" hotspot engine? I also should mention that even under jdk7u2 the invokedynamic version was only minimally faster than my call site version. That's not what is to be expected of invokedynamic. 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: performance degeneration from jdk7u2 to jdk7u6?
Am 21.05.2012 20:18, schrieb Mark Roos: > Hi Jochen > > Since I am using a Mac I can get a wide range of builds to try (almost > daily) > http://code.google.com/p/openjdk-osx-build/ > > For the compiler Christian recommended I try > -XX:-TieredCompilation > > which was my problem on jdk8 versions ok, I see, I will try that... Though.. my problem is that in Groovy we don't have always full control over the JVM people run. So it is good if thinks can be tweaked by a command line option, but if the default is bad, it is bad for our indy port and ultimatively for invokedynamic itself 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: performance degeneration from jdk7u2 to jdk7u6?
no one helping me on the assembly analysis? Am 19.05.2012 09:23, schrieb Jochen Theodorou: > Hi all, > > I was about to get a brand new assembly to ask some questions on the > list here when I installed the newest available jdk7 update 6. I ran my > simple Fibonacci test program and noticed that the time it took was > sudden 4.6s, where it was 3.5s before. This plus 1s doesn't look too god > to me. Has there been anything special that causes this? I mean before > the indy version was a little faster than our call site caching, now it > is a little slower. General java performance seems not to be reduced, so > I would assume it is special to indy. > > See http://rifers.org/paste/show/1702 > > ... so now... is there sombody who can tell me why my indy version is > now even slower than my call site version? Sadly I am not really fit > enough in assembler anymore, especially the one produced by hotspot to > really read that output. So I have no idea what is wrong. > > Two things I should mention... the call to $getCallSiteArray is surplus, > yes, but that doesn't take much time. The only thing I know that really > takes a lot of time is the exception guard, but that I have to have > until I find a way to avoid it and the call site version has both as > well of course. They should not count as satisfying explanation. > > 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: performance degeneration from jdk7u2 to jdk7u6?
Am 23.05.2012 23:33, schrieb Rémi Forax:
> On 05/23/2012 07:50 PM, Jochen Theodorou wrote:
>> no one helping me on the assembly analysis?
>
> Wow, you have generated the biggest fib function I have ever seen.
>
> About the bytecode you generate, as you said you have to remove
> $getCallSiteArray() because it seems it does some side effects
> so the JIT is not able to remove it.
the first time an array is generated, later nothing happens anymore...
but yes, this has to go.
> I don't understand why when you call fib in the body of fib,
> you are not able to say that the signature is (Object)I. You detect
> that this is a recursive call (you don't use the same BSM)
> but it seems you think that because fib can be changed
> using the meta object protocol, you should type it (Object)Object.
> But because you are in already fib, you already suppose that
> at least the return type is int. Basically, you can change
> the method fib when being in the middle of the execution of fib,
> because at least one call of fib is on the stack,
> the new method must have a return type which is compatible with fib.
the method signature is (I)I, it is called with Object in the body,
because I cannot ensure that x-1 and x-2 will return an int. Since I
cannot know for sure that fib(I)I is called, the result of the recursive
fib call is seen as Object. All I know for sure is that the result of
"fib(x-1)+fib(x-2)" will be converted to an int later and will cause an
exception if the conversion is not possible. But that is the result of
the plus, thus you don't exactly need a compatible return type for fib.
In for example:
int fib(int x) {
if (x<2) return 1
this.metaClass.fib = {int i -> i==1?"Forax":"Remi "}
String.metaClass.plus = {String b -> delegate.length()+b.length()}
return fib(x-1)+fib(x-2)
}
assert fib(3)== 10
I replace fib inside fib with, well it returns a String, but signature
wise I replace it with a method returning Object. String is not
compatible with int. And it does not lead to an exception because I also
replace String#plus with a version that simply returns the added length
of both Strings. So fib(3) will call fib(2) and fib(1), which has the
results "Remi " and "Forax". Then I call plus on those results, leading
to String#plus, which returns the added lengths, which is 10 and
compatible with int.
> Also, you should never use methods like
> |DefaultTypeTransformation.intUnbox|
> because you know that the return type is an int, you should
> back-propagate it and the return type of plus should be (Object;Object)I
in the original example that is true, yes. That may allow to skip at
intUnbox call... but only if I later select a plus method that returns
int or Integer. In a different thread I already asked for requirements
in that direction and that I get very differing results depending on
what signatures I use. No I have at lest the hint, that returning int or
Integer might be a good idea.
> Now, the generated code, because of getCallSiteArray(),
> your real code starts at line 168 and here you start
> to box the two ints to two Integers to be able to call
> NumberMath.subtract(Number,Number) which call
> IntegerMath.substractImpl that unbox them.
> The VM is not able to remove calls to box / unbox for j.l.Integer.
I see... unfortunate.
> You should generate a must simpler path here.
> You should never call a class like g.r.typehandling.*Math because
> all of these methods takes Numbers as parameters.
> You should create one simple class, with methods like this:
> static int add(int left, int right) {
> return left + right;
> }
> because it doesn't force you to do the boxing.
> So you will do the boxing only if it's necessary, i.e. only
> when the parameter is Object.
> And to now which method you have to call, instead of
> relying on getMath() you should use guardWithTest and
> test only parameters that are Object.
Object is pretty often the case. Well if I count boxing and unboxing for
(a+b)+(c+d), then now I have to box a to d, unbox for the add, box the
result, no boxing for the outer plus call, but two unboxing and a boxing
for the result and... if the method returns int, a final unboxing. That
makes 7 boxing and 7 unboxing.
If I use your add(II)I and backpropagate the return type, then I have
one boxing each for the inner pluses, two unboxing for the outer plus.
Totals to 2 boxing, 2 unboxing. Sounds better... even without
backpropagating the call. I will try that out.
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: performance degeneration from jdk7u2 to jdk7u6?
Am 24.05.2012 13:43, schrieb Rémi Forax:
[...]
> if invokedynamic knows more, you can provide a path with
> less boxing so it's usually better.
I changed Groovy to get rid of getCallSiteArray and added
backpropagation of the return type to the next directly involved method
call. So in
int fib(int x) {
if (x<=1) return 1
return fib(x-1)+fib(x-2)
}
the plus will now have directly return type int, instead of Object.
In a first iteration I made a primitives taking minus method, that also
returns int. And nice, runtime is down from 3.5 (on update 2) to 2.5 (no
tiered compilation and update 6).
That is not yet making really use of the type back propagation, so in
the next iteration I added a (II)I plus method as well. Before the
callsite target type was (II)Object, now it is (Object,Object)I, so only
little I can save on boxing, but let us see... 2.1s! And it stabilizes
much faster than before too. That's almost as much gain as before (in
percent). Certainly more than I thought.
Had I only used the plus method and not the minus method as well, I
would have ended up with 4.2s. only both together do make it that fast
now. A behaviour I noticed with primitive optimizations as well. An
optimization done in isolation can make things slower or does show only
little gain, but in combination they are suddenly much better. Another
interesting aspect is, now I don't see the slowdown through tiered
compilation anymore. The times are more or less equal with and without
tiered compilation, while before it was always slower with tiered
compilation not disabled (in update 6 it is on by default).
So the current state of my fib program is:
indy: 2.1s
primopts: 1.2s
callsite caching: 4s
Now I know that using catchException is causing quite a problem for
indy, so I removed that guard for the math operations plus and minus. It
is legal, since in those cases I can be certain I don't need it. And now
indy is at 1.2s! That means primopts and indy are no on par. That's very
cool! I mean I expected indy to come near indy, but to actually get on
par with it... I would never have thought that is possible.
The assembly is still quite big: http://rifers.org/paste/show/1717
But much better already.
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
megamorphic lambda prevention
Hi all,
I was wondering... if I have code like this:
list.each { x -> foo(x) }
list.each { x -> bar(x) }
list.each { x -> something(x) }
then isn't it the a case where within the each method we easily get
something megamorphic, since there are too many different kinds of
lambdas involved? Isn't that a general problem with internal iterators
and is there any plan to enhance hotspot to counter that problem?
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: megamorphic lambda prevention
Am 21.06.2012 13:57, schrieb Krystal Mok: > That's "the inlining problem" that Cliff Click was talking about [1], right? yes, the issue was actually mentioned more than once on this list already > I wonder how well the new interpreter design in Graal would handle this > kind of case, since it's supposed to have picked the good parts from > trace-based compilation, but without actually having to do tracing. > Can't wait to see more details of it at this year's JVM Language Summit. If I understood Thomas right, then Graal doesn't have that problem. Afaik hotspot doesn't have to have that problem too. It just was a design decision not to make call site caching per execution path. Afaik chaning that now would take quite some effort, but is not impossible. 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: megamorphic lambda prevention
Am 21.06.2012 13:21, schrieb MacGregor, Duncan (GE Energy): > Yes, it is very easy for those sites to become megamorphic. We work round > this by using exactInvokers on function invocation call sites, and caching > on the method type of the functions rather than the types. So in my own words... you don't check on the type of the lambda, but on what it takes as input, thus you get no changes for differing lambdas. Is that about right? That's a nice idea, indeed 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: megamorphic lambda prevention
Am 21.06.2012 16:00, schrieb Rémi Forax: > On 06/21/2012 03:52 PM, Jochen Theodorou wrote: >> Am 21.06.2012 13:57, schrieb Krystal Mok: [...] >>> I wonder how well the new interpreter design in Graal would handle this >>> kind of case, since it's supposed to have picked the good parts from >>> trace-based compilation, but without actually having to do tracing. >>> Can't wait to see more details of it at this year's JVM Language Summit. >> If I understood Thomas right, then Graal doesn't have that problem. >> Afaik hotspot doesn't have to have that problem too. It just was a >> design decision not to make call site caching per execution path. Afaik >> chaning that now would take quite some effort, but is not impossible. > > You can create the execution path backward, when it's needed. you can in PHP.reboot, but in Groovy I don't have access to the full execution path. Inside "each" I don't know what did call me and at the point of where I call each, I don't see what each will actually do. 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: megamorphic lambda prevention
Am 21.06.2012 15:55, schrieb Jochen Theodorou: > Am 21.06.2012 13:21, schrieb MacGregor, Duncan (GE Energy): >> Yes, it is very easy for those sites to become megamorphic. We work round >> this by using exactInvokers on function invocation call sites, and caching >> on the method type of the functions rather than the types. > > So in my own words... you don't check on the type of the lambda, but on > what it takes as input, thus you get no changes for differing lambdas. > Is that about right? That's a nice idea, indeed actually I am wondering... I guess I didn't fully understand yet, since even if you avoid the call site invalidation that way, you still have kind of a "branch point" the JIT will not inline. What it can inline is everything till the actual invocation, then it ends, since there are different MethodHandles involved. 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: megamorphic lambda prevention
Am 21.06.2012 15:58, schrieb Rémi Forax: [...] > I spend a couple of days in Linz last month with the Autrian part of the > Graal team (Thomas, Lukas and Gilles) > and we discuss about this issue (among other things). > I think we should book a room during the Summit to try to see if > something can be done in Hotspot. cool, I would like to take part in that... even if I may not be of help since I am surely not hotspot internals expert 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: megamorphic lambda prevention
Mark, can you explain what you mean with "depth"? if you mean the depth of a call path, then more than 20 is indeed more rare, but it depends on the circumstances. In Grails for example (web frame work in the Groovy world) a depth of 20 should be a much more commen case, simply because there is a framework around it, that already has the usual call path depth. As for seeing depth of the call path from the point the blokc is called to the point the iterator method is called, that is usually a quite short path of maybe depth <3. But maybe you something else by depth. Anyway, the goal is inlining and inlining is something you get with a more or less constant call site. Invalidating it means to remove that attribute of being constant, the counter will start new. That's why you may be able to remove old cases from your call site structure that way, but for inlining it does not help at all. Well... I am sure Remi will correct me should I tell wrong things here ;) bye Jochen Am 21.06.2012 20:27, schrieb Mark Roos: > Hi Jochen > > I was wondering at what depth you would consider a call site to be > megamorphic? > > I have done quite a bit of profiling on Smalltalk ( which uses lots of > blocks as iterators) > and rarely see depths > 20. > > As this depth seems to be time dependent ( at any one time its < 3 but > over time it grows) > I just invalidate the site when it gets past 20. But I am wondering what > the best approach > would be. > > I would like to do real time gwt chain inspection and modification but I > don't think that is possible. > > regards > mark > > > ___ > 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
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
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
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
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 27.06.2012 17:47, schrieb Attila Szegedi: > Just out of curiosity, in what situation would you need to have an > invokedynamic vs. invokespecial call to super ? Need invocation > time overloaded constructor resolution? yes ;) 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
How to making Class.forName work in indy?
Hi all, assuming you have to compile code with indy that realizes this: Class.forName(x) Meaning, we want to execute forName from Class using invokedynamic. If you then have frames in your trace looking like this: > java.lang.Class.forName0(Native Method) > java.lang.Class.forName(Class.java:186) > java.lang.invoke.MethodHandleImpl$GuardWithCatch.invoke_L2(MethodHandleImpl.java:1130) > org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:680) > groovy.util.JavadocAssertionTestSuite.(JavadocAssertionTestSuite.groovy:71) then it is clear to me, why it is failing. At least the Indyinterface part, if not even the GuradWithCatch part are disturbing the stack walking Class#forName is using. has anyone any idea on how to make this work across JVMs? One version, that sounds quite crazy to me, but may just work, is to compile a helper method on the class, that directly calls Class#forName and thus making it work, since there is no longer a wrong stack frame at the position Class#forName is looking for. But well... it may be a possibility 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: How to making Class.forName work in indy?
Am 10.07.2012 22:56, schrieb Rémi Forax: [...] > Class.forName(name) is equivalent to Class.forName(name, true, > lookup.lookupClass().getClassLoader()) > As true and lookup.lookupClass().getClassLoader() are constant in the BSM, > you can bound them using insertArguments. also an interesting idea, true, never thought of that... which is exactly why I ask here ;) 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: Backport 2.0 RC
Am 27.07.2012 18:44, schrieb Rémi Forax: > As traditionally for the JVM Summit, > I'm please to announce a new version of the JSR 292 backport, > http://code.google.com/p/jvm-language-runtime/downloads/list > > This version as some speed improvements and numerous bug fixes thanks to > the Nashorn Team. > > I'm still interested by any report of your favorite language running > with the backport, > Jochen?, Mark?, Duncan?, Charles*? or anyone that develop a language > runtime. The Groovy plans for invokedynamic are that version 3 of Groovy, coming next year, will use invokedynamic per default and the backport will be then used as a way to make it run on earlier VMs. I haven't really tried it out yet, instead in Groovy 2.0.1 we support invokedynamic as a Groovy VM plugin for jdk7. But I intend to test your backport against our call site caching after the summit well... I will be in Santa Clara on Sunday already if you want we could meet up and try making an integration of your backport. A meeting with whoever wants to participate in the invokedynamic workshop to speak what to do there is also something that could be done. Otherwise I will have to think of it all by myself. 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
strange ClassFormatError with indy
Hi all, I originally wrote that to the asm list, but nobody seems to know there. Anyway, for my generated bytecode the verifier complains with this message: java.lang.ClassFormatError: Method "" in class test has illegal signature "(Ljava/lang/Class;Ljava/util/Map;)Ljava/lang/Object;" Now... there is not a single method of that signature in the class test. What is new though (before it worked) is this indy call: > INVOKEDYNAMIC (Ljava/lang/Class;Ljava/util/Map;)Ljava/lang/Object; [ > // handle kind 0x6 : INVOKESTATIC > > org/codehaus/groovy/vmplugin/v7/IndyInterface.bootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;) > // arguments: none And this call has the signature the verifier complains about. Is this an illegal invokedynamic call? 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: strange ClassFormatError with indy
Hi, To me it did read like Remi says the name is wrong. I was wondering if it is related to void as well... Maybe it is better to give the method name as explicit argument and use the bytecode name for something else instead. Only... the bytecode started to read well again just now... But I guess I have to do that step, since Groovy allows in theory method names, that are not legal in bytecode. Am 30.08.2012 15:59, schrieb Douglas Simon: > Is is something to do with the fact that methods always have a void > return type? > > On Aug 30, 2012, at 3:35 PM, Remi Forax wrote: > >> The JVMS says the name must be a method name, >> http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.1 >> >> A symbolic reference to a call site specifier is derived from a >> CONSTANT_InvokeDynamic_info structure (§4.4.10) in the binary representation >> of a class or interface. Such a reference gives: >> • a symbolic reference to a method handle, which will serve as a >> bootstrap method for an invokedynamic instruction (§invokedynamic); >> >> • a sequence of symbolic references (to classes, method types, and >> method handles), string literals, and runtime constants (i.e. primitive >> numeric values), which will serve as static arguments to a bootstrap method; >> >> • a method name and method descriptor. >> >> >> so "" should be possible, but I don't think the EG discuss this corner >> case. >> >> Rémi >> >> On 08/30/2012 03:19 PM, Jochen Theodorou wrote: >>> Hi all, >>> >>> I originally wrote that to the asm list, but nobody seems to know there. >>> Anyway, for my generated bytecode the verifier complains with this message: >>> >>> java.lang.ClassFormatError: Method "" in class test has illegal >>> signature "(Ljava/lang/Class;Ljava/util/Map;)Ljava/lang/Object;" >>> >>> Now... there is not a single method of that signature in the >>> class test. What is new though (before it worked) is this indy call: >>> >>> >>>> INVOKEDYNAMIC >>>> (Ljava/lang/Class;Ljava/util/Map;)Ljava/lang/Object; [ >>>>// handle kind 0x6 : INVOKESTATIC >>>> >>>> org/codehaus/groovy/vmplugin/v7/IndyInterface.bootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;) >>>>// arguments: none >>>> >>> And this call has the signature the verifier complains about. Is this an >>> illegal invokedynamic call? >>> >>> bye blackdrag >>> >>> >> >> ___ >> 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 > -- 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: strange ClassFormatError with indy
Am 31.08.2012 01:22, schrieb John Rose: [...] to sum it up... JVMS 4.2.2 says it is not allowed, JVMS 4.4.6 kind of allows it... the discussion in 4.10.1.4 says usages of and are not typesafe ... > So if you want your code to pass the verifier, avoid (and ). ok, so it is the name after all, because and are not regular names at all. I was aware of the restriction of not being able to call "super()" in a constructor, but that this extends to not being able to do a "new ArrayList()" using no extra method name argument, is new to me... Why is that? Because the verifier only checks for the inits and we didn't want to change the verifier here? Given that you can use "new ArrayList()" by reflection I don't think that security concerns really hold here. They where given for super()... and even though I don't understand why (if someone can explain it would be nice) I see a "new ArrayList()" security wise as a whole different case than "super()" Basically it means that even if you wanted to do a Java using invokedynamic only, you cannot do. You will at least need an invokeSpecial as well. Either only for super() and you do extra method name work, or for both. > P.S. Value types (see my blog) will need to make be private, > since the new & invokespecial idiom is totally incompatible with > value types. If we bake them into the class file format (which I don't > advocate at present) we would have to define a syntax for building > value-type instances that does not mention ; this leads to ideas > like canonical factory methods, of which the obvious name is . For > now, I'm just proposing a design pattern (public static factory methods, > which internally use private new & ) that the JVM internally rewrites. I see that you may want to let the VM create them. But why is new & invokespecial totally incompatible? Ignoring the verifier problem, a new and invokespecial is still something that could be done kind of intrinsic for value types - or not? or do you mean something else? 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: thinking about proper implementation of tail calls
Am 31.08.2012 02:39, schrieb John Rose: [...] > Suppose you are compiling your favorite high-level language to the > JVM, and you start running into the various size limits in class > files. (Usually they come from the 16-bit indexes in various > places.) What do you do, dear? (H/T to Maurice Sendak, > http://www.amazon.com/What-Do-You-Dear/dp/0064431134 .) you mean like for example the number of methods ;) (We ran into this in the past). Of course you mean the size of a method. [...] > It would be great if there were an ASM module which could > automatically render an over-sized "mega-method" into some > JVM-compliant form. What would this take? As Charles already mentioned, there is currently something in work on the asm list... maybe you want to contribute? > A number of things: > > 1. The proposed mega-method would have to be broken into a control > flow graph of basic blocks. > > 2. The basic blocks would have to be packed into one or more > automatically-generated normal "mini-methods" (of JVM-compliant > sizes). > > 3. Control transitions between basic blocks would have to be > re-coded, if they cross from one mini-method to another. 3a. These > transitions would not be allowed to blow the stack. 3b. The live data > in local variables (as of the given transition) would have to be > transmitted somehow. > > 4. Something clever would have to be done to make the runtime stack > walker see the originally named mega-method. > > Step 3b is non-trivial, and probably requires boxing on the heap, in > general. (Remember that you can have up to 2^16-1 locals, but only > 2^8-1 parameters.) In the case where there are only a few locals, > they can just be passed in registers as parameters. > > Step 3a would seem to require tail calls. Specifically, the act of > leaving one mini-method M1 to go to a block in another mini-method M2 > requires a hard tail call from M1 to M2, passing any live data values > that the M2 block requires. You can handle part of the problem with normal calls, possibly exceeding the stack depth limit. Whatever code goes in there needs to maximally return 1 value. As long as that constraint is met, you can split the method. of course if your code more or less has the from (assignment, method call)*, then it is not helping. I wonder how such a split with hard tail calls would handle the exception table. > The corresponding act of entering a given target block in M2 also > requires some thought. Unless you are lucky or clever, or unless you > render one basic block to one mini-method, M2 will (logically) have > multiple entry points, one for each basic block that is a successor > of a basic block in some other mini-methd M1. Representing such > multiple entry points is tricky. Here are three ways to do it: > > A. Add an integer parameter (basic block selector index) to M2, and > structure M2 as a Big Switch. (This is a common technique; Rhino > does this for example.) Then M1 passes the selector as an extra > parameter. > > B. Add multiple entry points to the class file format. In > particular, allow M2 to declare multiple entry points, perhaps with > an entry point instruction which looks like a Big Switch. Compile > the rest of M2 as in A. Link calls into M2 using compound symbolic > references such as "M2.42", where 42 is the switch selector. (Note > that dot '.' is illegal in method names.) > > C. Structure M2 as in A, but run the call from M1 through > invokedynamic, without the extra parameter. When linking the call > from M1, bind the extra parameter into the method handle for M2. Ask > your friendly neighborhood JVM implementor to optimize this method > handle, at link time, into a form which is equivalent to the extra > entry points in B. First, this all reminds me of continuations. Second, the motivation for not doing basic-block-small-methods is the limit on the number of methods in a class imho. Third I see two different ways of splitting, the continuation style, where you kind of cut off a method by putting the cut part into a new method. Since the cut off part may contain several entry points, you need the above, but they are known at compile time and there is no need for anything beyond (B). Of course if you want to go further to continuations, then A/C become more interesting. But I see it currently out of scope for tail calls. > P.S. The distinction between "soft" and "hard" tail calls is > described here: > https://blogs.oracle.com/jrose/entry/tail_calls_in_the_vm > > I don't care much about soft tail calls (as an elective optimization) > as much as hard tail calls (proper implementation, which makes a > contract not to blow the application stack under defined > conditions). I agree 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 __
unreflectGetter and static class initialization
Hi, while working routing property access in Groovy through invokedynamic I stumbled upon one confusing part... If I have a static field and use Lookup#unreflectGetter to get a handle and then execute that handle, then it seems as if the class containing that field is not initialized. If I first get the field value, it is of course initialized and everything works as it should. I have for example a final static field INSTANCE, initialized in cinit with a value. If I use the handle only, then INSTANCE will be null. Now... is that really as it should be? Is that a known bug of 1.7.0_06-ea-b10 and fixed in a later version? bye Jochen ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: unreflectGetter and static class initialization
Am 24.10.2012 21:50, schrieb John Rose: [...] > > Yes, it's a bug, and there is a fix for this integrated into JDK8: > http://hg.openjdk.java.net/jdk8/jdk8/jdk/log?rev=7023639 what do you suggest as workaround? bye Jochen ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: unreflectGetter and static class initialization
Am 29.10.2012 17:03, schrieb Christian Thalinger: [...] > ...or move to JDK 8 until 7u with an updated 292 is released. Doesn't > the NoClassDefFoundError bite you anyway? you want me earnestly to tell the Groovy users that invokedynamic on JDK7 is useless ;) It is difficult enough to let people try JDK7 In fact I could so far work around the NoClassDefFoundError problem. I need a solution that works on any not too old JDK7 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: unreflectGetter and static class initialization
Am 29.10.2012 17:29, schrieb Remi Forax: [...] > In my opinion, the best is to use Unsafe.ensureClassInitialized() the > first time you call the BSM, it should be enough. That one I did not know so far, interesting. My current work around is to go with the fallback internal old MOP path... which means Reflection. Now I think Reflection is using that method as well, but my problem is a bit that I have no idea about the side effects of that method and its availability on other JDKs. Though, maybe it is less an issue for invokedynamic, since there are probably not many JDKs that support it. So in general I try to avoid Unsafe... but maybe it is ok to use here? 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: unreflectGetter and static class initialization
Am 29.10.2012 22:13, schrieb Christian Thalinger: [...] > What version of Groovy uses JSR 292? starting Groovy 2.0 you can enable invokedynamic. Though I use it only for method calls there and the implementation has still many quirks. Soon we will release Groovy 2.1, in which invokedynamic will be used for everything I didn't forget to change (that means field access, methods, initializer, ...). The plan is for Groovy 3.0 (to be released in 2013) to have a Groovy with a real invokedynamic core with an adapted MOP. Currently it is easily possible to produce structures invokedynamic cannot make much use of. 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
Question about MethodHandles#explicitCastArgument
Hi, I have a call to MethodHandles#explicitCastArgument with first argument being my MethodHandle(Groovy3135Bug,String,float,float,float,float,float)Object and the type I cast to being (Groovy3135Bug,String,Byte,Short,Integer,Long,Float)Object Ignoring the first two I should have some kind of unboxing followed by casting for most arguments. In the javadoc to that method I read: """ If T0 is a reference and T1 a primitive, an unboxing conversion will be applied at runtime, possibly followed by a Java casting conversion (JLS 5.5) on the primitive value, possibly followed by a conversion from byte to boolean by testing the low-order bit. """ Aren't T0 and T1 in my case for example T0=Byte and T1=float? Unless I mix up T0 and T1, this should be working, or not? Well... it fails with a NPE... that can't be right, can it? If I first cast to an all-Object signature, and then to the target, then it works... but that can't be how it should be, or not? 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: Question about MethodHandles#explicitCastArgument
Hi John, Am 16.11.2012 04:09, schrieb John Rose: > On Nov 15, 2012, at 3:32 PM, John Rose wrote: > >> It can be right, but only if the actual argument is a null reference. >> If it is a non-null Byte, it must unbox to a byte and then widen to a >> float. > > Well, actually, in this case, the NPE should not happen either. even if a null value would cause a NPE, I would expect that once the handle is executed, not while I cal explicitCastArguments. > Nulls are explicitly cast (though not merely "converted") to zeroes. > (The theory here is that an uninitialized Object reference can be > usefully reinterpreted as an uninitialized primitive value. The zero of > a type is exactly the values of an uninitialized field or array element > of that type.) > > Here's the spec.: >> f T0 is a reference and T1 a primitive, >> and if the reference is null at runtime, a zero value is introduced. > > So, explictCastArguments should not produce a MH which can throw NPE. > > CCE is still possible, e.g., if a String is cast to a File or a float, > or vice versa. Well, again... it does not, it cannot, since the call of explictCastArguments itself causes the NPE. That means I found a bug? ;) I am using build 1.7.0_09-b05 on Ubuntu 64bit. Currently I work around this by leaving primitive2primitive conversions as well as boxing and unboxing and anything a bytecode cast could do to explictCastArguments. But when it comes to chain primitive conversions and (un)boxing, I am doing that myself... even if the documentation says it is supposed to work. 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: Question about MethodHandles#explicitCastArgument
Am 16.11.2012 00:32, schrieb John Rose: [...] > What you are seeing is a bug. I can reproduce this in JDK 7 but not in > JDK 8. The upcoming JDK 7 update will fix this, since it is a backport > from 8. ah, finally the backport of jdk8 ;) I hope it does not break other things;) Btw, I noticed this not only with Byte, but with almost any wrapper type... of course Float did work. There is one part of he documentation that makes me a bit wonder though... If I want to convert a Long argument to an int argument it will not work? I mean it is not according to the Java widening rules afaik. And the documentation is telling about that. But since there are bytecode instructions for this - why the limitation? For me it means a lot of more work, since I not only have to check if they are primitives, I also have to check the widening conversions of Java are followed and if not apply my own transformations. And checking the widening rules... that is I think 19 cases. 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
Way to statically initialize a class before or during MethodHandle creation, Unsafe crashes JVM
Hi all,
in another thread I was already explaining, that I do need for a certain
method call the initialized class, to select the right method. Remi for
example then adviced me to use Unsafe and the method
ensureClassInitialized... well after adding that I get a nice hs_err log
file with
> Stack: [0x7f8fc9ae4000,0x7f8fc9be5000], sp=0x7f8fc9be1520, free
> space=1013k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V [libjvm.so+0x57] Unsafe_EnsureClassInitialized+0x67
> j sun.misc.Unsafe.ensureClassInitialized(Ljava/lang/Class;)V+0
> j org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.getMetaClass()V+63
Is this another bug? I assume it is... unless someone can explain me how
to workaround in my workaround ;)
Anyway... since that is crashing the JVM (and it must be some special
case) I am wondering now how I can ensure class initialization in my
bootstrap method. Or another solution for the problem without changing
the language.
Background is that in Groovy we may have something like this:
> class A {
> static {
> A.metaClass.static.empty << {-> '123' }
> }
> }
> assert A.empty() == '123'
Since the method empty() does not exist before the static initializer is
executed, I have to somehow enforce the execution of that, because
otherwise the meta class will not have the empty() method.
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: Way to statically initialize a class before or during MethodHandle creation, Unsafe crashes JVM
Am 16.11.2012 16:05, schrieb Remi Forax: > Jochen, > can you extract a simple test class that reproduce the bug ? > > Also, methods of sun.misc.Unsafe are not protected again send null as > arguments, > so you have to do the check before calling unsafe.XXX. I am sure it is not null... as for a testcase... the groovy program is simple, but that does not contain the unsafe call. The unsafe call is in the bootstrapping code, so you would have to use the Groovy runtime. I will try if it is always for the same class, but since that class is absolutely nothing special I highly doubt it. Also the call to ensureClassInitialization is done thousands of times without problem ... as for another way to ensure cinit has been executed... do you have any idea how to get this done without Unsafe? bye Jochen ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Way to statically initialize a class before or during MethodHandle creation, Unsafe crashes JVM
Am 16.11.2012 17:31, schrieb Remi Forax: [...] > is called the first time you call a constructor, a static > method or get/set the value of a static field. Remi I am aware of that, but I cannot simply call a static method, or create an instance of a class that I don't know. As for a static field... that might be save actually, only... what if there is no static field? The example I gave has three at least, but the class could have been written in Java, then there would be no such field and I still need that information from after cinit. I am looking of course for a general purpose solution here 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: Way to statically initialize a class before or during MethodHandle creation, Unsafe crashes JVM
Am 16.11.2012 20:43, schrieb Jochen Theodorou: > Am 16.11.2012 17:31, schrieb Remi Forax: > [...] >> is called the first time you call a constructor, a static >> method or get/set the value of a static field. > > Remi I am aware of that, but I cannot simply call a static method, or > create an instance of a class that I don't know. As for a static > field... that might be save actually, only... what if there is no static > field? The example I gave has three at least, but the class could have > been written in Java, then there would be no such field and I still need > that information from after cinit. > > I am looking of course for a general purpose solution here seems like Class.forName in the long form is the best for me. 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: Java 7 update 12 issue with MethodHandles.catchException.
Am 12.12.2012 20:42, schrieb John Rose: > On Dec 12, 2012, at 11:33 AM, Christian Thalinger wrote: > >> That helps. I can't recall code that has a "8 argument limitation" >> and does something else with 9+. Maybe John has an idea. > > The bug is probably in GuardWithCatch.invoke_V, in this file: > http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/MethodHandleImpl.java > > I'll look into it. that reminds me... will I be able to use LambdaFrom.Hiden in my code as well? And... is the speed penalty through the guard still that bad? 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
again on megamorphic problems
Hi,
let us assume the following example... I have a method foo
public Object foo(Object arg){return bar(arg)}
nothing fancy, quite simple... and let us assume foo is called from
dozens of places with differing argument types.
If I understood right, then the call site in foo will become
megamorphic, making it impossible to inline bar into the place from
where foo is called. foo becomes like a inlining barrier so to say.
The question is now more or less, if I can avoid that problem with
MethodHandles. I mean the pattern should occur with lamdas more than
once and I am wondering if there is anything planed to do against this
or if there has been already done something, or well, if I can bypass
the problem in indy.
bye Jochen
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: again on megamorphic problems
ok, but what would a a more generic linkage in this case here?
Actually... maybe I am wrong with seeing bar as megamorphic in terms of
indy. In the shown case it is most probably enough to not to test the
argument at all, since the receiver has an Object parameter and is not
overloaded. I won't get into the trouble of having to call another bar,
so it is pretty save. And if I don't need to change the call site target
I won't need to worry about megamorphic trouble, right?
bye Jochen
Am 20.12.2012 14:32, schrieb Attila Szegedi:
> I will just toot my own horn and say that Dynalink handles this -
> Nashorn actually leverages this feature to detect megamorphic sites and
> relink them differently. Dynalink keeps track of number of times a call
> site is relinked, and if it reaches a configurable threshold [1], it'll
> start returning true in "isCallSiteUnstable" [2] method in the link
> requests it sends to the linkers, who are then at a discretion to create
> different linkage - supposedly something more generic that might be less
> efficient than any individual narrow linkage, but wins in the end as
> it's more stable and avoids further relinking.
>
> Attila.
>
> [1]
> https://github.com/szegedi/dynalink/blob/master/src/main/java/org/dynalang/dynalink/DynamicLinkerFactory.java#L169
> [2]
> https://github.com/szegedi/dynalink/blob/master/src/main/java/org/dynalang/dynalink/linker/LinkRequest.java#L59
>
>
> On Thu, Dec 20, 2012 at 2:10 PM, Jochen Theodorou <mailto:blackd...@gmx.org>> wrote:
>
> Hi,
>
> let us assume the following example... I have a method foo
>
> public Object foo(Object arg){return bar(arg)}
>
> nothing fancy, quite simple... and let us assume foo is called from
> dozens of places with differing argument types.
>
> If I understood right, then the call site in foo will become
> megamorphic, making it impossible to inline bar into the place from
> where foo is called. foo becomes like a inlining barrier so to say.
>
> The question is now more or less, if I can avoid that problem with
> MethodHandles. I mean the pattern should occur with lamdas more than
> once and I am wondering if there is anything planed to do against this
> or if there has been already done something, or well, if I can bypass
> the problem in indy.
>
> bye Jochen
> ___
> 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
>
--
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: again on megamorphic problems
Am 20.12.2012 22:35, schrieb Mark Roos: [...] > I see the same for my Smalltalk implementation. In looking at my > problem it seems that the > megamorphic problem is temporal. In other words over a short time > period the site is monomorphic > then becomes megamorphic as more code runs. yes, that is what I expect. A callsite could be monomorphic for a long time, then be megamorphic and then turn monomorphic again. > Currently I detect the depth of the call site and drop its target chain > when it gets too deep. Now this > site starts over. I am sure the JIT is not thrilled and it is not a > general solution but for now it seems > OK. well, looking at what I said before, this approach has a good chance of "cleaning" a call site. That is why I tihnk this approach is surely not bad. How many targets do you usually keep in the chain before dropping? > Longer term I was thinking of a way to determine if a site is > megamorphic and if it is replace the callsite > GWT with something tailored. In my case the code is usually the same > for all receivers so it would > be interesting to find a way to use the same method code and only look > for the receivers where the > code changes. hmm... for Groovy I don't think I can really tailor something down all that much. If I can, then I didn't see it yet. > Another thought I had was to determine if a method has megamorphic call > sites internally and if so > then creating new methods during my lookup rather than caching the > existing ones. This would move > the specialization up one level but the internal sites would now be > monomorphic ignoring that I cannot easily do that, this surely is an approach, but I am worried about memory here. For one you would have a tendency to keep references to class you may garbage collect otherwise, for the other your class would grow and grow... bye Jochen ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: again on megamorphic problems
Hi Remi, yes, I remember the discussion you had with John. I was there too ;) Am 21.12.2012 00:32, schrieb Remi Forax: > On 12/20/2012 11:44 PM, Jochen Theodorou wrote: >> Am 20.12.2012 22:35, schrieb Mark Roos: >> [...] >> > [...] > >> >>> Another thought I had was to determine if a method has megamorphic call >>> sites internally and if so >>> then creating new methods during my lookup rather than caching the >>> existing ones. This would move >>> the specialization up one level but the internal sites would now be >>> monomorphic >> ignoring that I cannot easily do that, this surely is an approach, but I >> am worried about memory here. For one you would have a tendency to keep >> references to class you may garbage collect otherwise, for the other >> your class would grow and grow... > > The real solution is to have a way to say, I want a method handle on a > method but with a fresh profile. > John and I discuss about that after the last JVM Summit, he says that > being able to separate the profile from the method will be hard to do in > Hotspot. > > The main issue with the duplication of methods at bytecode level to have > several profiles is that the freshly generated bytecode have the wrong > performance counter and can be considered by the JIT has never been > called or at least not called enough to be JITed. > This is a known issue of the current implementation of JDart. > > A compromise can be to have a way to read/write the profile and the perf > counter of any methods, > Graal already provides these features. > It will be also very useful when you want to test a Java code to be able > to inject a profile artificially. > >> >> bye Jochen > > cheers, > Rémi > > ___ > 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: again on megamorphic problems
Am 21.12.2012 06:03, schrieb Charles Oliver Nutter:
> On Thu, Dec 20, 2012 at 7:10 AM, Jochen Theodorou wrote:
>> let us assume the following example... I have a method foo
>>
>> public Object foo(Object arg){return bar(arg)}
>>
>> nothing fancy, quite simple... and let us assume foo is called from
>> dozens of places with differing argument types.
>>
>> If I understood right, then the call site in foo will become
>> megamorphic, making it impossible to inline bar into the place from
>> where foo is called. foo becomes like a inlining barrier so to say.
>
> This is no different than for Java code, of course.
Yes, and especially in the light of lambda I am a bit hoping for the
bright minds to have a plan of action ;)
[...]
> It's not a problem in indy, it's just a limitation of how Hotspot
> inlines.
I am aware of this. But I have a missing bit of information here. If you
have an indy call site that involves different runtime types, but the
call site is not invalidated, can then Hotspot still inline? I assume it
could, so I guess the question should be more: will Hotspot still inline
then? If I get Remis test about Hotspot profiles right, then I have the
tendency to answer that it will still not be inlined... but that is an
interpretation of sparse information and likely to be wrong.
> This also impacts any methods that accept a closure as an
> argument;
and as such it should affect lambda a lot too, or not?
> if there's more than a couple different closures, the
> callback is megamorphic.
internal iterators have this problem imho very fast
> The only solution for you (and for Hotspot)
> is to specialize the foo method on a per-type (argument type, that is)
> basis, so that the type profile carries all the way through to a
> unique call target at bar.
>
> We are experimenting with that in JRuby, since we usually have the
> full AST available for every method (so we can emit multiple
> specialized versions of it). If you can't, then your best bet is just
> failing the bar call size (in JRuby, we do it if we see more than
> three types) and forever bind a simple non-indy cache to it (we bind a
> simple single-element, MRU inline cache).
imho generating methods at runtime is... well, I wrote already to Mark,
that I am worried about memory here. But maybe I worry too much. Nothing
in the generated code needs to refer other classes than those in the
original method. Actually all I have to do is to copy the method into a
new class. Well, it is not exactly so easy, but that is what I think is
to be done.
The question though is, if it is that easy, why doesn't hotspot do this?
To citate Remi: """
The main issue with the duplication of methods at bytecode level to have
several profiles is that the freshly generated bytecode have the wrong
performance counter and can be considered by the JIT has never been
called or at least not called enough to be JITed.
This is a known issue of the current implementation of JDart.
A compromise can be to have a way to read/write the profile and the perf
counter of any methods, Graal already provides these features.
It will be also very useful when you want to test a Java code to be able
to inject a profile artificially.
"""
In my own words... such a duplicated method would, for a long time, not
be considered for optimization by the JIT, because the original profile
information is lost. I mean if at least the old path is still fast, then
this is maybe less a problem.
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: again on megamorphic problems
Am 21.12.2012 12:28, schrieb MacGregor, Duncan (GE Energy Management): > I've been thinking about this due to the extensive mixin hierarchy in our > runtime presenting some potential problems with the number of types being > seen by some areas of code in some applications. It's going to be hard to > magic this problem away at the JVM level due to the restrictions stated in > the JVM specification for invokeDynamic, specifically, "The result of > successful call site specifier resolution is a call site object which is > _permanently_ bound to the dynamic call site." In order for the JVM to > create specialised version of methods, and for them to get their own call > sites (to avoid the megamorphic problems) that restriction would have to > be relaxed and it could potentially break the semantics for some languages. the call site object should not be copied, yes > For example, Charles, how do you handle the creation of literals / > constants when building specialised methods? Are the literals instantiated > by two specialised versions identical or simply equal? I must confess, I didn't even think about this yet. That could indeed cause problems. simply copying the bytecode of the method would maybe not be ok then 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: Proposal for Property Accessors
To drive the language list down there further I name the Groovy
variant... fully aware that it is not likely something for Java at all.
In Groovy we do:
class Egg {
int color
}
This will generate a getColor and a setColor method, just like you
expect from the Java Bean Spec. You can still write those methods, if
you want, then the method is taken instead of the generated version
In code you can access the property like this: egg.color
so exactly the same as a field. And that is actually a problem, since
you now have to make a difference between a field and a property.
Because sometimes you don't want to call the getter or setter, sometimes
you want to write directly into the field, since getter or setter may
contain additional code. If you would not need additional code, you
could simply go with fields.
If you go the route with user getter/setter and generated getter/setter
at the same time, you get problems with knowing when you need what.
Another problem are indexed properties. It is no problem in Groovy to
have a property return a field, but getter/setter with the index as
parameter look in Groovy like method calls. So they would either need
another syntax or they are not supported... which is what Groovy does in
the end. You can still call them as methods, but if you want to do
egg.color[1], you need a color property returning an array.
As for a special bytecode instruction... normally invokedynamic is
powerfull enough to resolve such things on the bytecode level. I see the
problem much more on the syntax side.
Recognizing what a property is from existing Java code is also an issue.
Thanks to our approach, if there are getter/setter, then they are
properties. A compiler then can for example simply call the getter and
setter like a normal method... really no special need for a special
instruction just for a static compiler. At least that is what the Groovy
static compiler is doing.
bye Jochen
Am 06.01.2013 10:43, schrieb Noctarius:
[...]
>> but, how about the syntax: public int get color() { return
>> iColor; } public void set color(int value) { iColor=value; }
>> public int get[](int idx) { return array[idx]; } public void
>> set[](int idx, int value) { array[idx]=value; }
>>
> The idea about the proposed syntax was to be minimalistic, it
> should prevent you from writing getters and setters which are just
> a big bunch of boilerplate codebase.
[...]
>>> Here's the C# approach:
>>> public class Egg {
>>> private int color;
>>>
>>> public int color {
>>> get
>>> {
>>> return this.color;
>>> }
>>> set
>>> {
>>> this.color = value;
>>> }
>>> }
>>> }
>>
>> yes, and with an AS3-like approach:
>> public function get color():int { return this.color; }
>> public function set color(value:int):void { this.color=value; }
>>
>
> The problem is, I see no clear standard what makes sense to say
> "yeah let's gonna go that way".
>
> AS3:
> public function get color():int { ... }
> public function set color(value:int):void { ... }
>
> C#:
> private int color;
> public int color {
>get {
> ...
>}
>set {
> ...
>}
> }
>
> Ruby:
> attr_accessor :color
>
> C++:
> Well no real kind of property but could be emulated using operator
> overloading
>
> MS C++:
> __declspec(property(get = getprop, put = putprop)) int the_prop;
>
> D:
> private int m_color;
> @property public int color() { ... }
> @property public int color(int value) { ... }
>
> Delphi had some way but I don't remeber it (thanks to god I finally
> forgot about Delphi).
>
> JS:
> color: {
>get: function() { ... },
>set: function(value) { ... }
> }
>
> Objective-C:
> @property int *color;
> @synthesize color;
>
> PHP:
> function __get($property) { ... }
> function __set($property, $value) { ... }
>
> I guess there are a lot more kinds of properties syntax out there
> and it neither seem to have a clean standard and nor that anyone of
> the above examples is better then the other. The interesting fact
> is, that AS and JS are totally different even though both are ECMA
> Script derived. JS in this case is more similar to C# (or other way
> round ;-)).
>
>> now, if one takes the above, and converts it to Java-like declarations,
>> one gets:
>> public int get color() { return this.color; }
>> public void set color(int value) { this.color=value; }
>>
>> more-or-less...
>>
>>
>> at least in my language, getters/setters are internally mostly just
>> normal methods, so the above would internally become something more like:
>> public int _get_color() { return this.color; }
>> public void _set_color(int value) { this.color=value; }
>>
>> with index properties having names like "_getindex_" and "_setindex_".
>>
>> actually, more-so, they are currently handled as a parser-hack.
>>
>>
>> the other part of the process is basically just handling getting/setting
>> them differently.
>> the closest direct JVM analogue o
about NoClassDefFoundErrors
Hi all, I just noticed something interesting. I had a small program that constantly failed with the famous NoClassDefFoundError, that is still such an major annoyance, even in jdk7u11. I tried out jdk8b78 and the program failed to start as well. But this time because I tried to lookup a virtual method on an interface that does not have that method. In all cases of this handle being called later the method exists in the end, but at the Lookup it did not - still jdk7 did not complain. I assume strongly this is a bug in jdk7 Now the fun part is: once I fixed those two problems, the very same program under the very same jdk7u11 did no longer fail with the class exception. It could be that by chance the conditions for the problem have changed enough to not appear again anymore... or there is something leaking from those LOOKUP.findVirtual calls, leading to that famous error. Is this known? 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: about NoClassDefFoundErrors
Am 25.01.2013 22:51, schrieb John Rose: > On Jan 25, 2013, at 7:04 AM, Jochen Theodorou wrote: > >> I just noticed something interesting. I had a small program that >> constantly failed with the famous NoClassDefFoundError, that is still >> such an major annoyance, even in jdk7u11. I tried out jdk8b78 and the >> program failed to start as well. But this time because I tried to >> lookup a virtual method on an interface that does not have that >> method. In all cases of this handle being called later the method >> exists in the end, but at the Lookup it did not - still jdk7 did not >> complain. I assume strongly this is a bug in jdk7 > > Can you give me a small test case or sketch of this interface and the > relevant implementation? Is it a simple failure in Lookup? actually I have to withdraw partially. The method does exist. I was only so happy to get around the error that I did not check carefully. But the whole thing still is fishy - and maybe it is even a bug in jdk7 and one in jdk8 Both lookup-problems where about a Lookup#findVirtual on an interface that extends an interface and the method is defined in the parent interface. So for example there is https://github.com/groovy/groovy-core/blob/master/src/main/org/codehaus/groovy/vmplugin/v7/IndyGuardsFiltersAndSignatures.java#L91 looking for the method invokestatic on Metaclass which is https://github.com/groovy/groovy-core/blob/master/src/main/groovy/lang/MetaClass.java and doesn't define the method on its own. Intead it is defined in MetaObjectProtocol which has the method here https://github.com/groovy/groovy-core/blob/master/src/main/groovy/lang/MetaObjectProtocol.java#L176 and is the parent interface. The other case is about GroovyInterceptable extending GroovyObject and the invokeMethod method. In jdk8 the above mentioned IndyGuardsFiltersAndSignatures.java line 91 failes, where jdk7 does not, but then jdk7 has these NoClassDefFoundError problems, that vannish after fising this. Imho findVirtual should not fail for the lookup on the childinterface, which is why I consider that a bug in jdk8 at least... but maybe that one is known. bye Jochen ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Looking for comments on paper draft "DynaMate: Simplified and optimized invokedynamic dispatch"
I would be very interested in reading that Am 19.02.2013 14:37, schrieb Eric Bodden: > Hi all. > > Kamil Erhard, a student of mine, and myself have prepared a paper > draft on a novel framework for invokedynamic dispatch that we call > DynaMate. The framework is meant to aid language developers in using > java.lang.invoke more easily by automatically taking care of common > concerns like guarding and caching of method handles or adapting > arguments between callers and callees. > > By March 28th, we plan to submit the draft to OOPSLA, at which point > we will probably also make the publication available as a Technical > Report, and will also open-source the implementation. Right now, I > would like to use this email to reach out to experts in the community > to get some feedback on this work, both in terms of what could be > improved w.r.t. the paper and in terms of the DynaMate framework > itself. > > So please let me know if you are interested in obtaining a copy of the > draft to then provide us with feedback. In this case I would email you > the PDF some time this week. > > Best wishes, > Eric > > P.S. Here is the current abstract: > > Version 7 of the Java runtime includes a novel invokedynamic bytecode > and API, which allow the implementers of programming languages > targeting the Java Virtual Machine to customize the dispatch semantics > at every invokedynamic call site. This mechanism is quite powerful and > eases the implementation of dynamic languages, but is is also hard to > handle, as it allows for many degrees of freedom and much room for > error. While implementers of some dynamic languages have successfully > switched to using invokedynamic, others are struggling with the steep > learning curve. > We present DYNAMATE, a novel framework allowing dynamic-language > implementers to define dispatch patterns more easily. Implementations > using DYNAMATE achieve reduced complexity, improved maintainability, > and optimized performance. Moreover, future improvements to DYNAMATE > can benefit all its clients. > As we show, it is easy to modify the implementations of Groovy, JCop, > JRuby, Jython to base their dynamic dispatch on DYNAMATE. A set of > representative benchmarks shows that DYNAMATE-enabled dispatch code > usually achieves equal or better performance compared to the code that > those implementations shipped with originally. DYNAMATE is available > as an open-source project. > -- 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
another question about megamorphic call sites in combination with MethodHandles
Hi all,
assuming I have in Java a method:
public static Object invoke(MethodHandle mh, Object[] args) {
try {
return mv.invokeWithArguments(args);
} catch (Throwable th) {
ExceptionUtils.sneakyThrow(th);
}
}
(sneakyThrow is to work around checked exceptions and does basically
just throw the throwable again without declaring it)
I am wondering if the call site in this method can become megamorphic or
not. And assuming it does not, I further assume the call to this method
cannot become megamorphic as well... so my next question is if that can
be always be potentially inlined then.
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: another question about megamorphic call sites in combination with MethodHandles
Am 21.03.2013 20:49, schrieb Remi Forax: [...] > I suppose you take a look to the instances. > You can do something similar actually by using invokedynamic + > a guardWithTest that checks already seen instances instead of doing a > plain mh.invoke* > I think Duncan and Georges do something like that in Magik. the example is supposed to be Java code, so I cannot use invokedynamic directly. The goal was to avoid the user having to write try-catch all the time. Is then sam conversion the best way here to avoid the problem? 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: another question about megamorphic call sites in combination with MethodHandles
Am 21.03.2013 20:31, schrieb Krystal Mo:
> Hi Jochen,
>
> At least with the current tip version of HotSpot, the
> mh.invokeWithArguments() callsite is not likely to get its actual target
> inlined into the caller; we depended a lot on being able to prove that
> the MethodHandle is a (JIT-)compiled-time constant to be able to do
> inlining across the MethodHandle.invoke/invokeExact boundary.
ah yes, I forgot that.
> I'm working on adding profiling support for
> MethodHandle.invoke/invokeExact (which invokeWithArguments() will call),
> and it looks at what MethodHandles get passed in.
> When that work lands in HotSpot, your example will be a source of
> profile pollution just like the well-known megamorphic callsites in the
> old days, so I wouldn't suggest doing that.
ok, thanks. I guessed it would be.
but maybe some can give my an alternative solution then. My "problem" is
that if you have a Java program (1.7) and that is supposed to call
something available as MethodHandle, and several of these, then you have
either a big useless try-catch or several of them, bloating your code a
lot. My idea with
> public static Object invoke(MethodHandle mh, Object[] args) {
> try {
> return mv.invokeWithArguments(args);
> } catch (Throwable th) {
> ExceptionUtils.sneakyThrow(th);
> }
> }
was to give an alternative way of calling, without having to try-catch
every time. Then sam conversion seems to be the only way left for this.
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: another question about megamorphic call sites in combination with MethodHandles
Am 22.03.2013 10:11, schrieb Remi Forax: [...] > I don't think it's a good idea to expose directly method handles to users, > it's better to encapsulate it into a Groovy object corresponding to a > function or a closure so you can add a bunch of invoke overloads. what invoke overloads are you thinking of here? 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: another question about megamorphic call sites in combination with MethodHandles
Am 22.03.2013 10:35, schrieb Remi Forax: > On 03/22/2013 10:24 AM, Jochen Theodorou wrote: >> Am 22.03.2013 10:11, schrieb Remi Forax: >> [...] >>> I don't think it's a good idea to expose directly method handles to users, >>> it's better to encapsulate it into a Groovy object corresponding to a >>> function or a closure so you can add a bunch of invoke overloads. >> what invoke overloads are you thinking of here? > > traditionnal ones, > invoke(Object) > invoke(Object,Object) > ... > invoke(Object...) Well, I would probably use different name, to avoid the problem of having a call with a single argument being an Object[] but then done with invoke(Object...), which would use the array elements as arguments instead of the array itself. We have this problem in Closure#call already, if done from Java... Which is why the method will go. Our groovy.lang.Closure will become only a thin wrapper ideally. Anyway... so you suggest having a general class we can use for invocations, then make some method to request the invoker, which will produce a subclass, with an implementation that can call the target? 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
some thoughts on ClassValue
Hi all, basically ClassValue is there so that my runtime/framework or whatever can store information and bind it to a class. The information is then available as long as the class exists. In Groovy3 I am going to use this for meta classes. Some time ago a user came up with a special need, he wanted to be able to replace the groovy runtime at runtime but could not do so because of classes being referenced that keep classloaders alive, which then lock the jar on the file system on windows. This did let me to the thought, that as soon as I start storing meta classes using ClassValue, my Groovy runtime will never unload again as soon as I store for the example a meta class on ArrayList (which is likely to happen) or Object, or any other java core class for that matter. This makes me think that I should not directly use ClassValue to enable unloading... but I also do not want unloading to happen when I still need the value. Does anyone have any idea on now to solve this problem? 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: some thoughts on ClassValue
[...] > Could you describe in some > more detail, what are "meta classes" in groovy runtime in terms of how > they are generated (lazily at runtime or ahead of runtime?), what > dependencies they can have and who is dependent on them. I assume they > are generated at runtime, since if they were accessible as class files > on the classpath of some loader, you would not have to design your own > caching/loading/defining layer (Class.forName() would do). That's still > an option if you create your own ClassLoader subclass that would use a > naming convention (say groovymeta.some.pkg.ClassName would be the name > of meta class "belonging" to some.pkg.ClassName main class) and use that > ClassLoader as the class loader for groovy apps. But that's hard to > enforce in various environments... So dynamic generation then. a meta class in groovy is a class containing the information the runtime has about a class. That includes methods and properties (which might be added at runtime) and different other things. It is basically administrative stuff and an important element in caching. In Groovy3 a class can have more than one meta class, depending on the context the class is used in... but that is probably already more than enough detail. Important is that I don't generate classes for this at any time, the structure is represented by a bunch of classes from my runtime. It can be best compared with Class from Java Reflection. The problem I have is, that if for example Object has a ClassValue based hard reference to MetaClass (my meta class class), then there will be always a class from the groovy runtime that stays referenced, thus not allowing it to be replaced or simply unloaded. I was already wondering if I can just use a WeakReference to my MetaClass instance. But the isnstance could be collected before the runtime is not needed anymore. At least in some cases this is nor acceptable. Just to make the problem more clear... Imagine there is some kind of App-Server and it laods something that uses Groovy, and maybe it loads this not at the system level, but per application and imagine the application is loaded and unloaded several times... a meta class is a large structure with a lot of objects. I could very easily write a Groovy script for such an environment that will eat up all the memory in this new meta class system while currently it should run with some big gc runs, but still run endlessly. For for example web applications this scenario is even likely to happen. bye Jochen ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: some thoughts on ClassValue
Am 27.04.2013 23:26, schrieb John Rose: ... > Each instance of the Groovy runtime will use a distinct ClassValue instance. > > If the ClassValue instance goes dead, then all the values (for each > class) bound using that instance should go dead also. > > If they don't it's a bug. well... I assume that if I have a ClassValue for Object that is an isntance of Foo, that this instance will stay as long as I don't delete it myself. That is how ClassValue works, or not? And that is exactly my problem too. bye Jochen ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: some thoughts on ClassValue
sorry for answering so late...
Am 27.04.2013 23:54, schrieb John Rose:
[...]
> As a simple example: Make a ClassValue object, bind a 1Mb array to
> Object.class using it, and then throw it all away. (Except
> Object.class, naturally.) Even if you do this in a loop, you should not
> get a storage leak.
>
> (A class value bound to a class is live only if both the Class and the
> ClassValue instance are both live.)
sometimes it is like having bricks in front of your eyes ;) I think I
understand now.
> Often people bind ClassValue instances to "static final" variables. If
> the class containing the static variable goes away, then the ClassValue
> goes away, and anything bound (to whatever class, including Object)
> should go away. That's nice, at least in theory.
>
> Things get tricky (this probably happens in practice) when there is a loop:
>
>class MyRuntimeInMyClassLoader { static final MyClassValue MYCV = ...
> } => instance of MYCV
>instance of MYCV x Object.class (say) => instance of MyMetaStuff
>instance of MyMetaStuff => MyRuntimeInMyClassLoader.class
>
> Although I am not one of the 12 people on the planet who fully
> understand class loader interactions with GC, I suspect this loop might
> be "sticky", and might have to be broken by (say) a SoftReference. (You
> can use a SoftReference if you are willing to have the GC break
> references not recently used, which you can reconstruct if needed.)
I think that is a case the GC has to resolve ;)
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
speed of invokeExact
Hi, I am currently investigating here some performance issues and I may have found a culprint here - invokeExact. My case is one where method caching fails and I will have to do an invokeExact from Java - meaning without the invokedynamic bytecode and with a non constant method handle. I am aware of that being a non optimized path in indy, but it does not really look fast to me at all. Maybe compared to Reflection, but to a runtime generated class for the method invocation, it seems to be very very slow- at least on my "64-Bit Server VM (build 25.0-b14, mixed mode)" here. Now.. is that commonly known? Did I see wrong? Is there a way to improve the speed (it is a DirectMethodHandle I am invoking already)? bye Jochen ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: speed of invokeExact
Am 07.05.2013 17:42, schrieb MacGregor, Duncan (GE Energy Management): > Which version of the jvm are you seeing this problem on, and are you > adapting the method handle every time as well as exact invoking it? the version is a 1.8.0-ea. Since this is a generic way of method invocation I have to adapt it a tiny bit (the arguments come in an Object[]) > We avoided invoke and invokeExact calls from Java (because they were > sometimes painful to get correct in the case of varargs methods) by having > the fallbacks return the adapted method handle to an exact invoker, like > this > > MethodHandle invoker = MethodHandles.exactInvoker(type()); > setTarget(MethodHandles.foldArguments(invoker, fallback)); my handles originate from reflection. I don't get them new every time, still I have to adapt the handle for actual invocation... like this: > MethodHandle mh = call.target.asSpreader(Object[].class, > call.args.length); > mh = MethodHandles.insertArguments(mh, 0, call.receiver); > mh = mh.asType(VC); mh is then used for the invocation using invokeExact 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: speed of invokeExact
please forget what I wrote... I made a mistake Am 08.05.2013 11:59, schrieb Jochen Theodorou: > Am 07.05.2013 17:42, schrieb MacGregor, Duncan (GE Energy Management): >> Which version of the jvm are you seeing this problem on, and are you >> adapting the method handle every time as well as exact invoking it? > > the version is a 1.8.0-ea. Since this is a generic way of method > invocation I have to adapt it a tiny bit (the arguments come in an Object[]) > >> We avoided invoke and invokeExact calls from Java (because they were >> sometimes painful to get correct in the case of varargs methods) by having >> the fallbacks return the adapted method handle to an exact invoker, like >> this >> >> MethodHandle invoker = MethodHandles.exactInvoker(type()); >> setTarget(MethodHandles.foldArguments(invoker, fallback)); > > my handles originate from reflection. I don't get them new every time, > still I have to adapt the handle for actual invocation... like this: > >> MethodHandle mh = call.target.asSpreader(Object[].class, >> call.args.length); >> mh = MethodHandles.insertArguments(mh, 0, call.receiver); >> mh = mh.asType(VC); > > mh is then used for the invocation using invokeExact > >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: speed of invokeExact
Am 07.05.2013 19:31, schrieb Christian Thalinger: [...] > Do you have any numbers?The problem is that if the MH is not constant > we can't do any inlining and it will be an out-of-line call (with a > trampoline in between). Is > your DMH a static or virtual? arg... looks like I made a mistake. It is not the invokeExact that is slow, it is my preparation of the handle that is slow. I get the arguments as Object[] so I do: > MethodHandle mh = call.target.asSpreader(Object[].class, call.args.length); > mh = MethodHandles.insertArguments(mh, 0, call.receiver); > mh = mh.asType(VC); I found this code doesn't really make sense in my case, since the arguments length is 0. But even if I replace it by > MethodHandle mh = MethodHandles.dropArguments(call.target, 1, > Object[].class); > mh = MethodHandles.insertArguments(mh, 0, call.receiver); > mh = mh.asType(VC); //VC= Object[]:Object it takes long. It improved in my test from 15000 to 3000. The only problem is that my old way still takes only a fraction of that. In 3000 I can not only do the invocation plus adaption for the call, I can even do full method selection... and it still totals to only about 200. And of that 3000 an estimated 2900 goes into adapting the handle. Now I am a bit unsure of how to get this better. The problem is that I have such an invokeExact path in Groovy today already. It is called the first time the handle is selected and in case of a callsite that does not cached, or that got invalidated. In a typical microbenchmark that situation may not appear often, but in a general application it does. In further experiments I used spreadInvoker, which did help to get times down to 1500 > MethodHandle mh = MethodHandles.spreadInvoker(call.target.type(), > call.args.length+1); > mh = mh.asType(VC) //VC= MethodHandle,Object,Object[]:Object but I cannot get rid of the asType call in my generic code. If I use casts to force the right types and don't use asType I get about 250 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: speed of invokeExact
Am 08.05.2013 23:12, schrieb John Rose:
> On May 8, 2013, at 5:33 AM, Jochen Theodorou wrote:
>
>> Am 07.05.2013 19:31, schrieb Christian Thalinger:
>> [...]
>>> Do you have any numbers?The problem is that if the MH is not constant
>>> we can't do any inlining and it will be an out-of-line call (with a
>>> trampoline in between). Is
>>> your DMH a static or virtual?
>>
>> arg... looks like I made a mistake. It is not the invokeExact that is
>> slow, it is my preparation of the handle that is slow.
>
> So it's an insertArgs and asType that's slow. Can you distill the operations
> into a micro-benchmark for us?
to reduce it to only asType:
compare the times of this:
> MethodHandle mh = MethodHandles.lookup().findVirtual(String.class,
> "toString", MethodType.methodType(String.class));
> int tmax = 1_000_000;
> for (int k=0; k<20; k++) {
> long t1 = System.nanoTime();
> for (int i=0; i String s = (String) mh.invokeExact(str);
> }
> long t2 = System.nanoTime();
> System.out.println((t2-t1)/tmax);
> }
with this:
> MethodHandle mh = MethodHandles.lookup().findVirtual(String.class,
> "toString", MethodType.methodType(String.class));
> MethodType invokeType = MethodType.methodType(Object.class,
> String.class);
> int tmax = 1_000_000;
> for (int k=0; k<20; k++) {
> long t1 = System.nanoTime();
> for (int i=0; i MethodHandle invoker = mh.asType(invokeType);
> Object o = invoker.invokeExact(str);
> }
> long t2 = System.nanoTime();
> System.out.println((t2-t1)/tmax);
> }
The first one has times of about 9-15 on my machine, the later one
800-900. I am aware that this is a test in which hotspot should throw
out the invocation completely, but it does not. Even more interesing is
when you reduce the test even further:
> MethodHandle mh = MethodHandles.lookup().findVirtual(String.class,
> "toString", MethodType.methodType(String.class));
> MethodType invokeType = MethodType.methodType(Object.class,
> String.class);
> int tmax = 1_000_000;
> for (int k=0; k<20; k++) {
> long t1 = System.nanoTime();
> for (int i=0; i MethodHandle invoker = mh.asType(invokeType);
> }
> long t2 = System.nanoTime();
> System.out.println((t2-t1)/tmax);
> }
Now this should really be optimized away completely by hotspot, but is
not and takes about the same time as the second case... which is not
surprising since the asType call is totally dominating the "benchmark".
btw, the test was with a jdk 1.8.0 ea with tiered compilation turned
off. The tests contain no warmup, but that's what why the test is
repeated 20 times to see the development of the values instead of doing
a one time measurement. And the values in this test go up and down a lot too
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: speed of invokeExact
Am 10.05.2013 02:40, schrieb Christian Thalinger:
[...]
> That's because your method handle is not constant and so the compiler cannot
> inline the call.
And you tell me that in the first case the call was inlined? That is
unexpected. And if that is the case, then why does this:
>>> MethodHandle mh = MethodHandles.lookup().findVirtual(String.class,
>>> "toString", MethodType.methodType(String.class));
>>> MethodType invokeType = MethodType.methodType(Object.class,
>>> String.class);
>>> int tmax = 1_000_000;
>>> for (int k=0; k<20; k++) {
>>> long t1 = System.nanoTime();
>>> for (int i=0; i>> MethodHandle invoker = mh.asType(invokeType);
>>> }
>>> long t2 = System.nanoTime();
>>> System.out.println((t2-t1)/tmax);
>>> }
take that long as well? Maybe it changed, but I thought only handles
coming from a final field are constant enough for inlining. If I compare
to 1.7.11 (or 1.7.6) then I get around 23 for the first, and 200-300 for
the second and third test. That is about a factor 10-15 slowdown, that
is what I would expect from the call not being inlined for example. But
I always thought 1.7 will not inline in this case at all. On my 1.8 it
was almost a factor 100. So unless the noninlined call on a method
handle got extremely expensive compared to 1.7, there must be something
else too.
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: speed of invokeExact
Am 10.05.2013 02:40, schrieb Christian Thalinger:
[...]
> That's because your method handle is not constant and so the compiler cannot
> inline the call.
If I change the test to (using 1.8.0):
> Object[] os = {"str", 1, new ArrayList(), new Object()};
> MethodType invokeType = MethodType.methodType(String.class,
> Object.class);
> MethodHandle[] mhs = new MethodHandle[os.length];
> for (int i=0; i MethodHandle mh =
> MethodHandles.lookup().findVirtual(os[i].getClass(), "toString",
> MethodType.methodType(String.class));
> mhs[i] = mh.asType(invokeType);
> }
> int tmax = 1_000_000;
> for (int k=0; k<20; k++) {
> long t1 = System.nanoTime();
> for (int i=0; i for (int j=0; j String s = (String) mhs[j].invokeExact(os[j]);
> }
> }
> long t2 = System.nanoTime();
> System.out.println((t2-t1)/tmax/os.length);
> }
then I doubt there is still any inlining happening. Here I get around 63
(case1). Since I have some probably complex toString action in here I
guess I cannot really compare that number with the test before. But it
is still under those 800. If I pull the asType into the loop (case2)
then I get something of 830-1000. And if I actually remove the
invokeExact and leave only the asType in the loop (case3), I get 730-840
For jdk 1.7.11 I get in
case 1: 70-100
case 2: 380-480
case 3: 300-400
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
sun.reflect.Reflection.getCallerClass(int) is going to be removed... how to replace?
Hi all, """The Oracle JDK internal method sun.reflect.Reflection. getCallerClass(int) is planned to be disabled in Oracle JDK 7u40. It is considered for removal in a later 7 update release. As you may be aware, the Oracle JDK internal sun.reflect.Reflection.getCallerClass(int) method has been removed from JDK 8. [1] The method is also planned [2] to be disabled in the 7u40 release. A call to the method would then trigger an UnsupportedOperationException.""" That means the method will be fully away for jdk8 and is going away in 7u40, but can still be enabled by a command line switch. There is a @CallSensitve annotation which allows calling Reflection.getCallerClass(). But this is causing some problems for us actually. Even if Reflection.getCallerClass() is ignoring all frames added by reflection (what about those added by invokedynamic/lambda?), it is not enough for us, since we will have also runtime generated classes appearing in there. A simple example is a Groovy program calling ResourceBundle#getBundle(String). While in non-indy mode the first access from that call site may be done by reflection and then work, subsequent calls would be done with runtime generated classes and then it can stop working very fast. Another one is Groovy grapes, which add libraries to the classpath at runtime, and it depends on being able to get the caller class loader for that. The usual depths here are 3-4, and that means 3-4 frames, that are not our callsite caching or indy, or reflection. With the runtime generated classes in the way I am not sure we can resolve the issue without really major changes, or we simply say that Groovy 2.x and earlier may not properly work on post jdk 7u40... unless you use indy, where I would still need confirmation there are no frames in the way from that then. I imagine other languages will have similar problems here and there... or not? 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: sun.reflect.Reflection.getCallerClass(int) is going to be removed... how to replace?
Am 02.07.2013 15:10, schrieb Attila Szegedi: > FWIW, I'm currently working on Dynalink correctly supporting methods > that are marked with @CallerSensitive; My tests from Nashorn show > things work as expected, i.e. you can give some permissions to your > script based on its URL in the security policy, and e.g. invoking > AccessController.doPrivileged() through INVOKEDYNAMIC works as > expected; it is actually a pretty big deal getting this to work right > :-) (doPrivileged, of course, being @CallerSensitive). I imagine INVOKEDYNAMIC may not have a problem here, if additional frames added by it are taken into account as well. But in Groovy we have not only invokedynamic and reflection. 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: sun.reflect.Reflection.getCallerClass(int) is going to be removed... how to replace?
Am 02.07.2013 15:10, schrieb Alessio Stalla: > On Tue, Jul 2, 2013 at 2:56 PM, Jochen Theodorou wrote: >> I imagine other languages will have similar problems here and there... >> or not? > > Hmm... what are you using that method for? I'm not aware of uses of it > in ABCL, but that may be because we aren't smart enough... ;) for example... Class.forName(String). Not that I advice people using this at any time, but this class gets the caller class, to use its class loader, to load a class by name. If your language does not generate a direct method call, then the code in forName assumes, that additional frame by you is the caller and uses its classloader instead the real one. There are many such things, but I don't know if they are relevant for ABCL. 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: sun.reflect.Reflection.getCallerClass(int) is going to be removed... how to replace?
Am 02.07.2013 20:13, schrieb John Rose:
[...]
> The upshot of all this is that if you encapsulate your CS method calls
> in method handles obtained from a BSM or MethodHandles.lookup, your code
> won't be sensitive to the dynamic context of those calls.
Your are of course right here, but you miss one important part, because
you limit it to direct reflection and direct invokedynamic.
Let me make an example:
> class Foo {}
> Foo.metaClass.bar = {throw new Exception("buh")}
> def foo = new Foo()
> foo.bar()
This code adds a method bar to the class Foo. To show the involved trace
I made it throw an exception. We can assume, that I for example call
Class#forName(String) here or something similar. The first call is done
using reflection and the trace to the caller (where the exception is
thrown) looks like this:
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:399)
> at
> org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:77)
> at
> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:102)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:57)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:182)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:190)
> at test$_run_closure1.doCall(test.groovy:1166)
As I understand the new implementation the first 4 frames would be
ignored, but that still leaves 5 more in the way here. An if you think
just doing this with indy will solve the problem... no:
> at
> java.lang.invoke.MethodHandleImpl$GuardWithCatch.invoke_L2(MethodHandleImpl.java:1130)
> at
> org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:212)
> at test$_run_closure1.doCall(test.groovy:1166)
since I need the dynamic types for a first call, I have one additional
frame in here, which will be in the way and give me the wrong class loader.
With our callsite caching, if we look not on the first call and say we
call a method bar statically defined in Foo, the trace to the caller
would look like this:
> at Foo.bar(test.groovy:1167)
> at Foo$bar.call(Unknown Source)
> at test$_run_closure1.doCall(test.groovy:1171)
the unknown source here is the runtime generated class. The defining
loader of that class is a child of the defining loader of the caller
(here test). So this can work... sometimes. For indy, there will be a
java.lang.invoke.MethodHandleImpl$GuardWithCatch.invoke_L1 in between,
so I assume it will work there. But the first call will fail in both cases.
And for Groovy 1.0 it looks even worse.
Of course we have to do tricks to get around the limitations. In the
past we could for example "replace" the method. Instead of using
Class#forName(String) directly we have our own Class#forName, which then
calls the bigger variant where I can give in a ClassLoader. We do that
for example for ResourceBundle#getBundle(String)
But with the new logic I see no other way, then to throw an exception
and walk the trace.
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: sun.reflect.Reflection.getCallerClass(int) is going to be removed... how to replace?
Am 03.07.2013 10:50, schrieb Jochen Theodorou: [...] > But with the new logic I see no other way, then to throw an exception > and walk the trace. addendum: Somehow I thought the trace has classes... it does not. With only Strings I can do exactly nothing, since I need the loader and by String I will not get the loader. So I have no idea about how to get around the problem. 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: sun.reflect.Reflection.getCallerClass(int) is going to be removed... how to replace?
Hi all, 5 days nothing... Does that mean it is like that, there is no way around and I have to explain my users, that Java7/8 is going to break some "minor" functionality? 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: sun.reflect.Reflection.getCallerClass(int) is going to be removed... how to replace?
Am 10.07.2013 10:40, schrieb Noctarius: [...] > Maybe a solution could be an annotation to mark calls to not > appear in any stacktrace? I had that idea too, and then found it no solution... only I don't remember why anymore.. Didn't JSR292 include at one time such an annotation? 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: sun.reflect.Reflection.getCallerClass(int) is going to be removed... how to replace?
Am 11.07.2013 06:09, schrieb Charles Oliver Nutter: [...] > In JRuby, we pass the calling object into every call site to check > Ruby-style visibility at lookup time (we can't statically determine > visibility, and we do honor it). That gets you a bit closer to being > able to get the caller's classloader without stack tricks (though I > admit it does nothing for methods injected into a class from a > different classloader). If we would need the caller class on a regular base, we would have something for this in Groovy. But since a call can come from anywhere in Java too, the caller class is no information we can depend on. The current implementation does allow us to get the caller class in the call site, but from there it does not go to the place where it is needed, which is inside the method. Any change to make the caller class passed to the method will require bigger and deep changes. The method will need an additional parameter, which means the signature will not match anymore; the method needs to be recognized in its special function; rules for overriding and overwriting have to be defined (including fun with generics); we have to define what to do in case the call is not from a callsite where the call class is available and so on. It is much more for us than only an internal change. It is a conceptional change and the user will have to know about it (including a bunch of new special rules). I don't see so much a problem here for Groovy 3, but 1.x and 2.x have a problem. 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: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)
Am 30.07.2013 14:17, schrieb Peter Levart: [...] > So what would give Groovy or other language runtimes headaches when all > there was was a parameter-less getCallerClass() API? Aren't the > intermediate frames inserted by those runtimes controlled by the > runtimes? Couldn't the "surface" runtime-inserted methods capture the > caller and pass it down? I guess the problem is supporting calling the > caller-sensitive methods like Class.forName(String) and such which don't > have the overloaded variant taking caller Class or ClassLoader as an > argument... Speaking for Groovy... those intermediate frames are runtime controlled, yes, but passing down the caller class is exactly the problem. Imagine I would suggest that each and every method definition in Java automatically gets an additional parameter for the caller class, just to have access to it inside the method. You would not accept that for Java, would you? And so we cannot accept that for Groovy if we want to keep integration with Java... and the good integration with Java is one of the key points of Groovy. Even if we make something like that @CallerSensitive and add the parameter only in those cases, we break being able to override methods. Plus, before Groovy3 is not done we have to support several call paths. And the oldest one, which is still a fallback, does not support transporting the caller class through the runtime layers at all. Changing here is a breaking change. > John Rose suggested to "capture" the caller in the "surface" method and > bind it with a MethodHandle and then pass such MH down the runtime API > and finally call that method via MH. Only that you then need a java7+ only version, plus the already mentioned problem, that not all of the three general call paths support that or can be changed in a way to enable that without breaking user code. 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: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)
Am 30.07.2013 14:17, schrieb Peter Levart: [...] > So what would give Groovy or other language runtimes headaches when all > there was was a parameter-less getCallerClass() API? Aren't the > intermediate frames inserted by those runtimes controlled by the > runtimes? Couldn't the "surface" runtime-inserted methods capture the > caller and pass it down? I guess the problem is supporting calling the > caller-sensitive methods like Class.forName(String) and such which don't > have the overloaded variant taking caller Class or ClassLoader as an > argument... Speaking for Groovy... those intermediate frames are runtime controlled, yes, but passing down the caller class is exactly the problem. Imagine I would suggest that each and every method definition in Java automatically gets an additional parameter for the caller class, just to have access to it inside the method. You would not accept that for Java, would you? And so we cannot accept that for Groovy if we want to keep integration with Java... and the good integration with Java is one of the key points of Groovy. Even if we make something like that @CallerSensitive and add the parameter only in those cases, we break being able to override methods. Plus, before Groovy3 is not done we have to support several call paths. And the oldest one, which is still a fallback, does not support transporting the caller class through the runtime layers at all. Changing here is a breaking change. > John Rose suggested to "capture" the caller in the "surface" method and > bind it with a MethodHandle and then pass such MH down the runtime API > and finally call that method via MH. Only that you then need a java7+ only version, plus the already mentioned problem, that not all of the three general call paths support that or can be changed in a way to enable that without breaking user code. 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
