Hi Jochen,
I read through the thread in mlvm-dev [1] that has a good discussion
there. I have filed a RFE:
8020785: caller-sensitive methods to skip dynamic generated frames
and look up the true caller
This seems that java.lang.instrument might be an appropriate place for
this support. This certainly requires further investigation.
Mandy
[1] http://mail.openjdk.java.net/pipermail/mlvm-dev/2013-July/005387.html
[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020785
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?
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
