RFR 8140685: Fix backtrace building to not rely on constant pool merging
coleen.phillimore at oracle.com
Mon Nov 2 22:04:27 UTC 2015
On 11/2/15 3:43 AM, serguei.spitsyn at oracle.com wrote:
> Hi Coleen,
> The fix looks good to me.
> I like the simplifications!
> A minor comment:
> 34 // doesn't get deallocatd.
> typo: deallocatd => deallocated
Thank you Serguei for reviewing this. I thought you'd like the
simplification after all the work we've done on this.
I fixed the typo above.
> On 10/30/15 15:16, Coleen Phillimore wrote:
>> On 10/30/15 6:01 PM, Coleen Phillimore wrote:
>>> Summary: Save Throwable in a list which is a weak GC root for
>>> walking during MetadataOnStackMark
>>> This was the original implementation that I had for finding Method*
>>> in backtraces but it was slow because I had used jweak to save the
>>> Throwable object. Using internal vm weak GC roots, this does not
>>> cause a performance regression in refWorkload. This fix is more
>>> straightforward and does not rely on the constant pool index of the
>>> merged constant pool during redefinition to find the method's name.
>>> This is one fix that enables removing merged constant pools during
>>> redefinition (work in progress). It also is would be used as a
>>> model for JEP 259: Stack Walking API
>>> The code that registers MemberNames for replacing Method* during
>>> redefinition may need to use the same mechanism for performance, if
>>> MemberName arrays are used for the Stack Walking API.
>>> I assume this will generate comments from the GC group.
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>> Tested with RBT quick (former "quick" tests),
>>> jdk/java/lang/instrument tests and the test that I wrote for
>>> handling backtraces with redefinition in
More information about the hotspot-dev