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

[David Holmes]

Bug update looks good!

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
>