RFR 8140685: Fix backtrace building to not rely on constant pool merging (original) (raw)
Coleen Phillimore coleen.phillimore at oracle.com
Fri Oct 30 22:16:17 UTC 2015
- Previous message: RFR 8140685: Fix backtrace building to not rely on constant pool merging
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 https://bugs.openjdk.java.net/browse/JDK-8043814. 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 hotspot/test/runtime/RedefineTests. Thanks, Coleen
- Previous message: RFR 8140685: Fix backtrace building to not rely on constant pool merging
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]