RFR(xxs, jdk10): 8171508: os::jvm_path -XXaltjvm processing error after 8066474

Thomas Stüfe thomas.stuefe at gmail.com
Wed Apr 26 08:43:47 UTC 2017

Hi David,

thanks for reviewing! See comments inline:

On Wed, Apr 26, 2017 at 9:39 AM, David Holmes <david.holmes at oracle.com>

> Hi Thomas,
> On 26/04/2017 5:10 PM, Thomas Stüfe wrote:
>> Hi all,
>> may I please have a review for this tiny fix. 8066474 removed the <arch>
>> directory from the images and since then -XXaltjvm was slightly broken.
>> When handling XXaltjvm, os::jvm_path() examines the path of the libjvm.so
>> to check if it is part of what it considers a standard JDK by traversing a
>> number of slashes up the path and looking for "/jre/lib". That number of
>> slashes was off since 8066474.
> On BSD we never had the <arch> directory so that seems to have always been
> broken - despite the updated comment!

This seems to be not well tested, but then, I also did not find much
information about how altjvm is supposed to work. Is this even an official

> webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8171508-os_jvm_pa
>> th_xxaltjvm_processing_error_after_8066474/jdk10-webrev.00/
>> webrev/index.html
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8171508
>> Note that this only affects cases where the alternate libjvm.so is part of
>> a full jdk, so it does not affect the gtestLauncher.
> Changes look good.
> I wonder whether we can easily write a simple sanity test for this? eg by
> pointing altjvm to the actual JDK path?

One could test this by starting the VM with -XXaltjvm=<path>
-XX:ErrorHandlerTest=<xx> and let the VM crash. Then examine the hs_err
file - the loaded libjvm.so location should be <path>, but libjava.so and
friends should be loaded either from <path> or from JAVA_HOME, depending on
whether <path> is a full jdk.

But currently I have not the time to write this test. I am currently
working on fixing gtests for AIX and this is a side issue I encountered. So
I'd like to make the test a separate issue.

Could you please sponsor the fix? Bug ID seems to be fine this time :)

Thanks, Thomas

> Thanks,
> David
> Thanks & Regards, Thomas

More information about the hotspot-runtime-dev mailing list