RFR 8187436: -Xbootclasspath/a causes sanity check assertion with exploded build

[harold seigel]

Hi Alan,

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.

Harold

On 9/14/2017 3:33 PM, Alan Bateman wrote:
>
>
> On 14/09/2017 20:02, harold seigel wrote:
>> Hi,
>>
>> 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: 
>> http://cr.openjdk.java.net/~hseigel/bug_8187436/webrev/index.html
>>
>> 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.
>
> -Alan