RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

[Coleen Phillimore]

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 
files.

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:

export CLASSPATH=...
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 
runtime tests.

Coleen
>
> Paul.