[sh/11] 8239926: Shenandoah: Shenandoah needs to mark nmethod's metadata

Zhengyu Gu zgu at redhat.com
Thu Mar 26 12:00:40 UTC 2020



On 3/26/20 1:28 AM, Aleksey Shipilev wrote:
> On 3/25/20 9:41 PM, Zhengyu Gu wrote:
>> On 3/25/20 2:20 PM, Aleksey Shipilev wrote:
>>> On 3/25/20 1:17 PM, Zhengyu Gu wrote:
>>>> What our next release is based on?
>>>
>>> April: 11.0.7
>>> July: 11.0.8
>>>
>>> We are currently in deep stabilizing for April release.
>>>
>>>> If 11.0.7, we should consider backport both.
>>>
>>> Yes. But I think for 11.0.8.
>>>
>>> 8237396 can be picked up to sh/jdk11, but we would need to protect it with UseShenandoahGC and
>>> maintain the upstream behavior without Shenandoah. It is too risky at this point otherwise.
>>>
>>
>> How about:
>>
>> http://cr.openjdk.java.net/~zgu/shenandoah/sh11u-jvmti/webrev.00/
>>
>>    100   inline oop object_raw() {
>>    101     if (UseShenandoahGC) {
>>    102       return RawAccess<>::oop_load(object_addr());
>>    103     } else {
>>    104       return object_peek();
>>    105     }
>>    106   }
> 
> That might work. Needs a comment saying this is the variant of 8237396.
> 
> But generally, I think you are too late for April release for either 8237396 or 8237632. RC was
> there for weeks already [1], the backports should have been done way before today. At this point,
> 8237396 or 8237632 do not look critical enough to risk destabilizing the release, and/or warrant
> more emergency work after the last pre-CPU tag is pushed [2]. Push these the first thing in 11.0.8,
> once it is open?

Okay. Given it is JVMTI specific, not an urgent one.

-Zhengyu

> 



More information about the shenandoah-dev mailing list