RFR (xs) 8166203 NoClassDefFoundError should not be thrown if class is in_error_state

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Wed Oct 12 08:08:04 UTC 2016


Hi Ioi,

The fix looks good to me.
But I agree with David below that the catch statement is somewhat confusing.
The test needs to fail in such a case with a message like "Unexpected 
NoClassDefFoundError <...>".

Thanks,
Serguei



On 10/11/16 22:58, David Holmes wrote:
> Hi Ioi,
>
> On 12/10/2016 2:47 PM, Ioi Lam wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8166203
>> http://cr.openjdk.java.net/~iklam/jdk9/8166203_init_state_error_bug/
>>
>> Summary:
>>
>> Kudos to Coleen for noticing the bug.
>>
>> When dumping the CDS archive, we would throw NoClassDefFoundError inside
>> InstanceKlass::link_class_impl() if the current class is in_error_state.
>> This was only intended to be a convenient way to deal with verification
>> errors during CDS dumping time. However, if the code is executed in
>> normal VM execution time, it would violate the JLS.
>>
>> The fix is to throw the NoClassDefFoundError only when
>> DumpSharedSpaces==true, to avoid affecting normal VM execution.
>
> Fix looks fine.
>
> Test change is somewhat confusing. What bug does this still refer to?
>
>  160         try {
>  161             boolean bb = Iunlinked.v;
>  162         } catch(NoClassDefFoundError e) {
>  163             System.out.println("NoClassDefFoundError thrown 
> because of bug");
>  164         }
>
> Either the try block should complete exceptionally or the catch block, 
> to indicate a failure.
>
> Thanks,
> David
>
>
>> Thanks
>> - Ioi
>>



More information about the hotspot-runtime-dev mailing list