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