jps fix and test exclude list for jdk-module-image

[Alan Bateman]

Mandy Chung wrote:
>  I am taking a pass at the regression test failures when running with 
> jdk-module-image.  My goal is to get all the test targets in a JPRT 
> job to succeed with modules build (i.e. testing jdk-module-image) so 
> that we can easily identify regressions with the jigsaw development 
> and also with the periodic update with jdk 7 repositories.
>
> First batch of changes:
>    http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/jps-module-fix/
>
> Summary of changes:
> 1. Add jdk_jigsaw in the jprt testset.
> 2. Add regression test failures in jdk/test/ModulesProblemList.txt to 
> temporarily exclude them until the bugs are fixed.
> 3. Some minor cleanup in the class analyzer tool
> 4. Fix jps to print the correct information (main change in this 
> webrev) and details below.
>
> A number of jps unit tests failed because jps (and a number of other 
> jdk tools) now is launched in module mode.  jps used to print the 
> class name (e.g. sun.tools.jps.Jps).  In module mode, jps now prints 
> the module name e.g. 'jdk.tools at 7-ea'.  The tests check if it shows 
> jps itself by comparing the output.  Jps also truncates the package 
> name to show the class name in a short form and thus it shows 
> 'tools at 7-ea' rather than the full module name.
>
> The fix involves changes in java launcher, hotspot VM and jps.
> 1. the java launcher will pass -Dsun.java.main to the VM.  This 
> property will be either the main class name or the module name being 
> launched.
> 2. the VM adds two new jvmstat counters (sun.rt.javaMain and 
> sun.rt.javaModule).
> 3. If an application is running in module mode (ie. non-empty 
> sun.rt.javaModule), then jps will print the full module name even for 
> the short form.  jps -l option prints the long form that will show the 
> full path of a class name.
> 4. If the application is a jdk tool (e.g. jps and jstat), it launches 
> the 'jdk.tools' module and pass the main class name as the first 
> argument [1] (that is the current workaround for multi entry point 
> support).  It's not as useful if jps just shows 'jdk.tools'.  So in 
> this case, jps will print the main class name of the tool instead of 
> the module name.
>
> There is a jps RFE to support printing the classname of an applet or a 
> webstart application.  The -Dsun.java.main property can be extended 
> for this purpose in the future.
>
> With the above changes, langtools_jtreg and jdk_jigsaw are the 
> remaining test targets with failures.
>    langtools_jtreg has about 8 failures
>    jdk_jigsaw tests depend on gawk and cc compiler.  I'll ask if we 
> can get help to install gawk on all JPRT systems and deal with the 
> compilation of the native library next.
>
> Anyone has cycle to review this?
>
> Mandy
>
> [1] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-September/001118.html 
>
>
Apologies for the late review, but I finally got to this.

The addition of the jdk_jigsaw tests looks good but it's not clear to me 
why the jdk_rmi batch is being added to JDK_TEST_LIST (it's also on 
JDK_TEST_LIST2, the batches that require a display for some reason). I 
wonder if this is something we should get sorted out upstream as the 
jdk_rmi batch is not run by default (to my knowledge).

Also you've added a few tests to the problem list:

  85 java/nio/channels/FileChannel/ClosedByInterrupt.java    generic-all
  86 java/nio/channels/SocketChannel/AdaptSocket.java        linux-x64
  87 java/nio/channels/SocketChannel/Connect.java            linux-x64
  88 java/nio/MappedByteBuffer/Force.java                    windows-i586

In the case of java/nio/channels/FileChannel/ClosedByInterrupt.java, I 
will guess that jdk and langtools weren't in sync at the time of the 
test run. I can't tell why the next two are on the list. In the case of 
java/nio/MappedByteBuffer/Force.java  I assume it's the clean-up issue 
we have on Windows where file mappings can remain for a period after the 
process terminates. This isn't technically a test bug but I have created 
7012823 to track looking for ideas on how to avoid these false failures.

You've also added a few RMI tests to the list:

 100 # Need further investigation
 101 # TestFailedException: TEST FAILED: could not create registry
 102 sun/rmi/runtime/Log/checkLogging/CheckLogStreams.java   solaris-all
 103 sun/rmi/runtime/Log/checkLogging/CheckLogging.java      solaris-all
 104
 105 java/rmi/transport/dgcDeadLock/DGCDeadLock.java         solaris-all

I guess we aren't seeing these upstream because the jdk_rmi batch isn't 
run (as I mentioned above).

The updates to the class analyzer look fine to me. Amusing to see 
application.vendor=mchung :-)

The changes to get jps to print the correct information mostly looks 
okay to me. Some of the code in the launcher is starting to get tricky 
with the tools running in module mode.

A small comment is that it would be nice if SetJavaMainProp didn't use 
sprintf.

On the jvmstat counters, should we skip create the javaModule counter if 
not set?

In MonitoredVmUtil.java, you're using "sm" as the StringMonitor in a few 
places that a bit inconsistent with the existing code. Should it be 
javaModule instead?

That's all I have.

-Alan.