On 6 mar 2014, at 14:41, Alan Bateman <[email protected]> wrote:
> On 06/03/2014 13:29, Staffan Larsen wrote: >> >> : >> >> I’m not sure how these things work, but I’ve built and tested this on all >> platforms, so it seemed to work. I see that WIN_JAVA_LIB is already added on >> windows so perhaps that is why. I’ve changed the fix slightly to remove the >> -ljava from the windows LDFLAGS and verified that it builds and tests on all >> platforms. > I'm sure the build group can advise on the best approach but I think what you > have looks okay now . > > >> >> This turned out to be a mistake. According to the JVMTI spec, the agent does >> not have access to the JNIEnv during Agent_OnLoad(). Since Canonicalize() >> does not use the value it didn’t matter what I sent to it. >> >> I would like to continue sending NULL to Canonicalize() as the JNIEnv since >> there is no way I can get a correct env in Agent_OnLoad. It would >> not be correct, but it would work. >> >> The other option is to add a Canonicalize_NoEnv() function to libjava that >> does not take a JNIEnv parameter. >> >> Thoughts on this? > This looks okay to me. It does assume that the JNIEnv is not used so somewhat > fragile but anyone tempted to change anything will find the issue quickly. > One idea is to change the name of the parameter in jni_util.c to "unused", > same thing in the function prototype/extern. At some point we should consider > removing the parameter but that is somewhat disruptive in that it means > hotspot changes at the same time. Thanks. I’ll change the parameter name to “unused” before pushing. /Staffan
