Testing <was> Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

[Paul Sandoz]

> On 3 Dec 2015, at 14:12, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>> 
>> It does involve the jtreg and testing launcher but is that really a major issue? If the test fails when running with the launcher class then presumably debugging wise it’s also useful to run with that too? but i can understand in certain cases it may be preferable not to do that. Overall, with my admittedly more JDK core libraries goggles, on the above does not seems that different to your existing process.
> 
> No, we're not trying to debug the launcher but the little java program that we're testing.  Do -Xlog:itables=debug with your experiment, or TraceClassInitialization or set a breakpoint in InterpreterRuntime::resolve_invoke.
> 

IIUC the examples you present are also relevant to Java classes before main is invoked.

How do you deal with the “noise” of Java booting up before main is invoked?

Do you have some conditional breakpoint logic configured?

A data point: AFAICT (e.g. with TraceClassInitialization) the use of the jtreg TestNGAction$TestNGRunner launcher results in ~the same number of classes initialized up to the actual test class as occurs between startup and the main class.


> The point is that we don't have extra time to hack out out new frameworks in order to get to the problem that we're trying to solve.  It's a time issue, not a possibility issue.
> 
> In your sample below, I'd hack out at least 10 more lines to get to the java class for the test program but I haven't had time to test if this works yet.  Last time I tried to debug a test with testng in jdk/test/java/lang/invoke, I had to run it in the background and do 'ps' to find the java command.  I may have had to give up and look through the hotspot sources.
> 

That’s odd, i don’t know the particular details and constraints of what you were testing, but if you use the script jtreg spits it will not fork a new Java process (unless the test explicitly does so). I was just able to run a debug VM with no issue with a j.l.invoke testng test.


> As I said, you can see if the compiler group will accept these tests.  They seem to belong in the hotspot repository, not the jdk repository because we run these tests with JPRT.
> 

Yes, my reluctance to move to jdk was because they may get run less often.

There does appear there might be less resistance from members of the compiler group :-)

Paul.