RFR(M): 8203824: Chain exception from initialization in later NoClassDefFoundErrors.

[Karen Kinnear]

Goetz,

Thank you for improving the information from NoClassDefFoundErrors.
As far as I can tell, your implementation is still within the specification.

I agree with David that this does not belong in java.lang.Class.

Could you possibly explore extending the resolution errors hash map?
My thinking is that this should be rare, and that we don’t want to add a field for every instanceKlass to
hold an error and waste the space.

Does this work correctly for:
threads trying to initialize this class in parallel?
nested initialization by the same thread?

thanks,
Karen


> On Jun 5, 2018, at 9:21 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi David, 
> 
> I also would prefer to keep this field within hotspot.
> 
> The reason we use a Java function is that that 
> also calls out to a routine that transforms the 
> backtrace to stackTrace recursively for the chained
> exceptions, which was implemented in Java.
> We did this to make sure we don't keep any classes 
> alive that are referenced by the backtrace.
> I didn't include that (yet), because that calls back into
> the VM ... 
> Do you think I should address this issue right away, 
> or do you think it's overly cautious to free the backtrace?
> 
> Best regards,
>  Goetz.
> 
> 
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Dienstag, 5. Juni 2018 04:36
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: RFR(M): 8203824: Chain exception from initialization in later
>> NoClassDefFoundErrors.
>> 
>> Hi Goetz,
>> 
>> On 2/06/2018 2:02 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>> 
>>> If static initialization of a class fails, an ExceptionInInitializerError
>>> is thrown. Later accesses to this class will fail, too. They report
>>> a NoClassDefFoundError. This is misleading, as the class has been
>>> found in first place but the initialization failed.
>>> 
>>> To give more context, retain the previous ExceptionInInitializerError
>>> and chain it into the NoClassDefFoundError:
>>> 
>>> I added a field to java/lang/Class to retain the exception.
>>> This is the design we followed in SAP JVM. I am not sure whether
>>> the additional memory consumption of Class is acceptable, or whether
>>> a hash map holding the exceptions internally would be a better
>>> design.
>> 
>> I suggest moving the field to instanceKlass and keeping this entirely
>> within the VM. I would not want to see the change on the Java side or
>> the need for a Java upcall to set this - you might hit more exceptions
>> in the process! Any change on the Java side has to go through the
>> core-libs folk anyway.
>> 
>> Thanks,
>> David
>> -----
>> 
>>> I also left out code that transforms the Throwable::backtrace in the
>> retained
>>> ExceptionInInitializerError and it's recursively chained exceptions into
>>> Throwable::stackTrace and limits the recursively chained exceptions.
>>> If this change is appreciated, I'll add that in a later change.
>>> 
>>> I found a test for NoClassDefFoundError messages and extended that.
>>> I moved the existing test into the canonical location under
>> /exceptionMsgs/
>>> 
>>> Best regards,
>>>   Goetz.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Failing class initialization throws a ExceptionInInitializerError.
>>> Later accesses to this class throw a NoClassDefFoundErrors
>>> hiding the original cause.
>>> 
>>> This change adds code to chain the initial EIIE in the NCDFE.
>>> http://cr.openjdk.java.net/~goetz/wr18/8203826-exMsg-
>> NoClassDefFoundError/webrev
>>> 
>>> The initial EIIE is stored in the Class that failed to initialize.
>>> I thought
>>>