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