RFR(S) 8176887: SIGSEGV in AOTCodeHeap::next when using specific configuration
igor.veresov at oracle.com
Fri Apr 7 21:33:08 UTC 2017
> On Apr 7, 2017, at 1:29 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> This could be good fix for JDK 9.
> Are you sure that functions called for Metadata scan will not barf on MethodCounters?
Yes, there shouldn’t be any problems. In the context of class redefinition it calls mark_on_stack(), which is empty by default except for Method and ConstantPool.
> You need also ask Runtime group to look on this change.
CCing the runtime mail list. Guys, any objections to making MethodCounters a Metadata ?
> When fixing 8173794 I missed this case (MethodCounters*). We should not put them into metaspace_got array since GC don't need to process them. And they increase metaspace_got array significantly.
> For 10 we should fix JAPTC code - metaspace_got array should contain only Klass* pointers. May be to add a separate array since extLinkageGOTContainer may not right for MethodCounters*.
In the context of class redefinition the scan is actually interested only in methods, rather than classes. Going forward, yes, it would probably be better if we had separate GOT arrays for each MetaspaceObj subtype, so that we can separate Methods out and scan only them.
> On 4/7/17 11:55 AM, Igor Veresov wrote:
>> The problem here is that AOTCodeHeap::got_metadata_do() iterates over the _metaspace_got array assuming that the array contains Metadata*, indeed the array is declared as such. However it also happens to contain MethodCounters*, and MethodCounters is not Metadata, but MetaspaceObj. The simplest and minimal risk solution is to make MethodCounters a subclass of Metadata (we’d like to have this fix in jdk9).
>> Webrev: http://cr.openjdk.java.net/~iveresov/8176887/webrev.00/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176887
More information about the hotspot-runtime-dev