Hi all, It's been a while since I mentioned this and I wanted to let you know what I've been doing. Apologies this is a bit long.
To recap, the issue is a crash when using the Java profiler under Windows https://issues.apache.org/jira/browse/NETBEANS-1428 NB starts the profiled app under a separate JVM with an agent attached. This agent uses native code to get a stack trace and, later, to get the names of the methods in that stack trace. Information is passed between NB and the agent via IPC. The methods in the stack trace are identified by a 'jmethodid' - this is a JNI type. Originally, under 32-bit JVMs, jmethodid is a 32-bit quantity, so the agent returned a list of jmethodids as an int[]. All the profiler code in NB is based on ints. Now for 64-bit JVMs, jmethodid is 64-bit, so the agent does a trick to carry on returning 32-bit quantities. The trick is to assume that jmethodids are numerically clustered, in which case the agent splits it into a 34-bit base and a 30-bit offset. It stores up to four unique bases and returns a 32-bit int composed of the 2-bit base index and the 30-bit offset. As long as the jmethodids are clustered into no more than four groups this works. The original NETBEANS-1428 bug was just some faulty casting and I fixed this. I've been in touch with the people in the servicebility-dev mailing list (http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-November/026068.html) and they say that this assumption is not guaranteed to hold - indeed changes in allocation of jmethodids was why this bug was never seen in JDK1.8 and earlier, then appeared for JDK9. So I am looking for a more robust solution. I have thought of 3 options: 1. Change the type used to hold a jmethodid from jint to jlong (int & long in Java terms) 2. Implement a list of jmethodids in the native code and return integer indices. 3. Return an int[] for 32-bit platforms and long[] for 64-bit platforms A constraint is that the agent should be fast and not use too much RAM because that will affect the performance of the profiled app. For method 1 - advantages are that it's straightforward and simplifies the native code, disadvantages are that it requires touching the C code and the Java, and it means more data needs to be transmitted via IPC (twice as much). Also it would need the native code for all platforms to be recompiled. For method 2 - the Java code doesn't need changing at all and only natve code for affected platforms need recompiling. However the native code becomes slower/ more complicated and it needs more RAM to hold a hash-table of jmethodids on the profiled application side. For method 3 I haven't looked into it much but it would require some careful work on the IPC protocol. I think it would be quite awkward to do. Has anyone any comments or opinions on this? I am tending to option 1 as the simplest. Thanks, Peter --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
