RFR(xxs, jdk10): 8171508: os::jvm_path -XXaltjvm processing error after 8066474
thomas.stuefe at gmail.com
Wed Apr 26 08:43:47 UTC 2017
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
>> 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 & Regards, Thomas
More information about the hotspot-runtime-dev