Hi Jochen,
On 7/11/2013 4:21 PM, Jochen Theodorou wrote:
Hi all,
I started a thread about this already on the mlvm list, but since I
get no responses there I am going to ask here as well. Plus I have an
actual problem with openjdk 7u25 related to this it seems.
First the u25 problem. According to
https://jira.codehaus.org/browse/GROOVY-6246 openjdk 1.7.0_25 freezes
with 100% CPU load in this code:
https://github.com/groovy/groovy-core/blob/master/src/main/org/codehaus/groovy/reflection/ReflectionUtils.java#L105
This is surely not the nicest piece of code and all that, but that is
not the point. The point is that this worked in openjdk 1.7.0_9 and
does not in openjdk 1.7.0_25. Where it does work is in the oracle jdk
1.7.0_25. Btw: it is too bad there are no .tar.gz packages of the
openjdk builds available. Assuming the diagnosis is right, this should
help pinpointing the problem. Has there been any changes already to
that method?
There is a regression in 7u25 that is fixed in 7u40:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016814
The workaround is to call it with depth+1 when running in 7u25. I will
reply the second part next (currently OOTO).
Mandy
Of course Reflection.getCallerClass(int) is a bigger problem for us.
It was announced, that in u40 of jdk 1.7.0 this method will be no
longer operational, unless you use a jvm switch. This is quite
troublesome for us, but at least there is some way. In jdk 1.8 this
method is supposed to disappear without replacement. There seems then
to be the getCallerClass() method, which ignores frames from
reflection (I strongly hope for you guys that lambda and indy are
included here), but this will not rescue us at all. We have almost
always a frame of our own appearing in a "first call" in Groovy. And
there is no way to avoid that (not even in indy). That means for us,
that any functionality depending on this cannot be called from a
Groovy program anymore. We already replace
RessourceBundle.getBundle(String) to let it discover the right loader.
But after the change this will not help. Transporting the not always
available caller class from the callsite into the method is for
current versions of Groovy (and all versions of Groovy are influenced
here)
We are currently investigating if we can find a workaround for @Grab
(http://groovy.codehaus.org/Grape) in some cases. There won't be one
for all cases of course.
What I would like to hear is a statement if this is taken as serious
or if it will be ignored. From the mlvm list I have so far the
impression, that it will be ignored.
bye Jochen
