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
./images/jdk/lib/server/classes.jsa
So where's the bug ??
David
-----
> 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