RFR: 8350905: Releasing a WeakHandle's referent may extend its lifetime

[William Kemper]

On Mon, 10 Mar 2025 07:26:02 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> When weak handles are cleared, the `nullptr` is stored with the `ON_PHANTOM_OOP_REF` decorator. For concurrent collectors using a SATB barrier, this may cause the referent to be enqueued and marked when it would be otherwise unreachable. The problem is especially acute for Shenandoah's generational mode, in which a young region holding the otherwise unreachable referent, may become trash after the referent is enqueued for old marking. We are proposing that native weak references are cleared with an additional `AS_NO_KEEPALIVE` decorator. This is similar to what was done for j.l.r.WeakReference in [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696).
>> 
>> # Testing
>> 
>> GHA, `hotspot_gc_shenandoah`. Additionally, for G1, ZGC, and Shenandoah we've run Extremem, Dacapo, SpecJVM2008, SpecJBB2015, Heapothesys and Diluvian. All executions completed without errors.
>
> @fisk gave an offline comment that he would prefer if this could be handled by the GC Barrier backend instead of having to change the runtime code to understand how SATB and weak handles work.
> 
> Take a look at how ZGC deals with this:
> 
> template <DecoratorSet decorators, typename BarrierSetT>
> inline void ZBarrierSet::AccessBarrier<decorators, BarrierSetT>::oop_store_not_in_heap(zpointer* p, oop value) {
>   verify_decorators_absent<ON_UNKNOWN_OOP_REF>();
> 
>   if (!is_store_barrier_no_keep_alive<decorators>()) {
>     store_barrier_native_without_healing(p);
>   }
> 
>   Raw::store(p, store_good(value));
> }
> 
> 
> and then how `is_store_barrier_no_keep_alive` ensures that ON_PHANTOM_OOP_REF stores are treated as no-keepalive stores.

Thank you @stefank , will take a look at this today.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23935#issuecomment-2711314050