Request Review: JDK-6479237 (cl) Add support for classloader names

Brent Christian brent.christian at oracle.com
Fri Oct 28 18:11:28 UTC 2016


On 10/27/16 7:54 PM, Mandy Chung wrote:
>> On Oct 27, 2016, at 3:28 PM, Brent Christian <brent.christian at oracle.com> wrote:
>>
>> * Throwable.java
>>
>> 832             // VM to fill in StackTraceElement
>> 833             getStackTraceElements(stackTrace);
>> 834             // ensure the proper StackTraceElement initialization
>> 835             for (StackTraceElement ste : stackTrace) {
>> 836                 ste.buildLoaderModuleClassName();
>> 837             }
>>
>> For my own curiosity, why is this buildLoaderModuleClassName() call needed?
>
> When the VM fills in the stack trace, it sets Class object in
> StackTraceElement and the buildLoaderModuleClassName() call here to
> (1) build the output string whose format as described in the javadoc,
> and stored in a serial form (2) not to hold a strong reference to
> Class object.  StackTraceElement is serializable and it can’t build
> the correct string, when deserialized.

Should something be done for STEs returned from 
StackFrameInfo.toStackTraceElement() ?  These are also filled in by the 
VM.  The strong Class reference is probably not such a concern, as the 
StackFrameInfo itself also holds one, but would we run into trouble upon 
trying to deserialize such an STE?

Thanks,
-Brent


More information about the hotspot-runtime-dev mailing list