RFR (S) 8140685: Fix backtrace building to not rely on constant pool merging

Coleen Phillimore coleen.phillimore at oracle.com
Wed Jan 25 21:58:41 UTC 2017



On 1/23/17 7:11 PM, David Holmes wrote:
> Hi Coleen,
>
> On 24/01/2017 9:00 AM, Coleen Phillimore wrote:
>> Summary: Store Symbol* for the name in the backtrace
>>
>> There was some thought that storing a u2 for cpref would be more memory
>> efficient than storing Symbol* in the backtraces, but recent runs of
>> Jetty show that this doesn't cause footprint increases or performance
>> decreases.   Storing the Symbol* for the method name guarantees it is
>> there when creating the StackTraceElement, whereas cpref relies on
>> constant pool merging for redefinition and is dependent on being an
>> index in the right constant pool, which has been a source of bugs in the
>> past.
>
> This all sounds reasonable. But I'm not very clear on the Symbol 
> ref-counting protocol, so can't really say if this may leak them or not.

I tried to explain in the bug.
>
>> dev-submit performance testing was run with no regressions.  Also, all
>> hotspot jtreg tests were run.
>>
>> This is a change for JDK10 whenever that opens.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>
> The bug refers to a method-id to Method* change, nothing about cpref 
> to Symbol*. Can you update the bug so that it reflects the actual 
> change please.

Yes, sorry, I hadn't fixed the bug.  I've changed the description now to 
be more accurate.  Let me know if it makes sense to you or if there's 
some better rewording that I can do.

Thanks,
Coleen

>
> Thanks,
> David
>
>> Thanks,
>> Coleen



More information about the hotspot-runtime-dev mailing list