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

David Holmes david.holmes at oracle.com
Wed Apr 26 23:31:51 UTC 2017

Hi Thomas,

Backing up a few steps ...

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.

Hold on a moment! We don't have a jre subdirectory any more either! The 
image for a jdk directly contains lib/server/libjvm.so (for example).

Also jvm_path is used for dumping the shared archive using the default 
location. If I do:

 > ./images/jdk/bin/java -XXaltjvm=images/jdk/lib/server/ -Xshare:dump

it works perfectly correctly:

  > find . -name classes.jsa

So where's the bug ??


> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8171508-os_jvm_path_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.
> Thanks & Regards, Thomas

More information about the hotspot-runtime-dev mailing list