[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