RFR 8187436: -Xbootclasspath/a causes sanity check assertion with exploded build
harold.seigel at oracle.com
Thu Sep 14 20:19:34 UTC 2017
Thanks for the review!
I tried using "@run ... -Xbootclasspath/a=. ..." to simplify the test
but JTReg adds the location of the test class file to CLASSPATH, causing
it to get loaded by the app-class loader, not the boot loader.
On 9/14/2017 3:33 PM, Alan Bateman wrote:
> On 14/09/2017 20:02, harold seigel wrote:
>> Please review this JDK-10 change to fix an assertion involving
>> ClassLoader::_num_entries. The assertion gets triggered when running
>> the exploded build. ClassLoader::_num_entries is only used by CDS,
>> which is not supported for exploded builds. So, assertions involving
>> _num_entries should check for a normal build before doing their check
>> involving _num_entries.
>> Note that a new RFE will be filed shortly requesting a re-design of
>> the confusing boot classpath entries code as requested in one of the
>> comments in this JBS bug.
>> Open webrev:
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8187436
>> The change was tested with the JCK Lang and VM tests, the JTreg
>> hotspot, java/io, java/lang, java/util, and other tests. The test
>> were run with both the normal and exploded builds.
> This looks okay. An alternative for the test is to put "@run
> main/othervm -Xbootclasspath/a:." so that you don't need to generate a
> source file, compiler it, and run in another VM.
More information about the hotspot-runtime-dev