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

[Coleen Phillimore]

On 1/27/17 12:52 AM, David Holmes wrote:
> Bug update looks good!

Thank you, David.
Coleen

>
> Thanks,
> David
>
> On 26/01/2017 7:58 AM, Coleen Phillimore wrote:
>>
>>
>> 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
>>