RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables
coleen.phillimore at oracle.com
Wed Dec 2 23:23:44 UTC 2015
Thank you Stefan for making the distinction between debugging Java
inside an IDE vs. the JVM.
On 12/2/15 6:00 PM, Paul Sandoz wrote:
> Hi Stefan,
>> On 2 Dec 2015, at 17:20, Stefan Särne <stefan.sarne at oracle.com> wrote:
>> Hi Paul,
>> The reason we stick on standard jtreg tests is because it is simpler.
>> For us, a java test is not a unit test, it is an application. :)
> I tend to think of that as an artificial distinction since such java test classes often contain a logical grouping of tests (and perhaps data over which to test) and make test assertions. Let’s call it duck unit testing, it looks and quacks like a unit test :-)
>> I agree with you that when writing and debugging java code, I would choose testng over jtreg and run and debug it inside my java IDE.
> In the case of the JDK it's not jtreg over testng it is jtreg + testng.
We already use jtreg and do not welcome another layer on the java class
When debugging a jtreg failure, I go to the "rerun" section in the .jtr
file. Edit it for 10 minutes to remove the extra '\' at the end and
remove jtreg so that I get simply:
java <some options> ClassFile
and save it to a rerun.sh file.
I haven't figured out which -D test option I need for the test, but try
to remove most of them also.
Generally, I debug like:
gdb --args $JAVA_HOME/bin/java <some options> ClassFile
What we're interested in is generally in the ClassFile and not in the
jtreg java code.
I do not want to spend an additional 10 minutes to hack out testng.
Also, if the test fails and has a agent.jar file, that's usually found
in the directory below, so I have to copy my rerun.sh file there.
>> But debugging the VM is instead done with a native debugger and what the framework gives you for java development, becomes a level of indirection in VM land. Just adding the test class as argument to the java launcher where a main method exists is preferred.
> How do HotSpot engineers debug the VM with a jtreg test that uses @library (or @module once Jigsaw gets integrated), or uses WhiteBox, or uses ProcessTools?
See above. Luckily CLASSPATH points to it in the end of the jtr file.
So no. We do not want testng harness code added to the the Hotspot
More information about the hotspot-dev