RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API (original) (raw)

Kim Barrett kim.barrett at oracle.com
Tue Nov 28 00:33:45 UTC 2017

On Nov 27, 2017, at 10:33 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:

Hi, The ResolvedMethodTable has weak oop references in it. Currently it uses explicit SATB enqueueing for G1 to make the weak semantics work. This should be refactored to use the Access API instead. The previous raw loads should be ONPHANTOMOOP | ASNOKEEPALIVE and the loads followed by explicit G1 SATB enqueueing should be ONPHANTOMOOP. Webrev: http://cr.openjdk.java.net/~eosterlund/8191904/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8191904 Thanks, /Erik

============================================================================== src/hotspot/share/prims/resolvedMethodTable.cpp 44 // The ACCESS_PEEK peeks at the oop without keeping it alive.

ACCESS_PEEK => AS_NO_KEEPALIVE.

============================================================================== src/hotspot/share/prims/resolvedMethodTable.cpp 43 oop ResolvedMethodEntry::object_peek() {

Maybe the function should be called object_no_keepalive(), for consistency with the access decorator.

==============================================================================
src/hotspot/share/prims/resolvedMethodTable.cpp 43 oop ResolvedMethodEntry::object_peek() { 44 // The ACCESS_PEEK peeks at the oop without keeping it alive. 45 // This is dangerous in general but is okay in this specific 46 // case. A subsequent oop_load keeps the oop alive if it it matched 47 // a target object before leaking out.

I think the comment is misleading. There is nothing about this specific function that makes it "okay"; what makes it okay is that each use is careful about how it uses the result.

============================================================================== src/hotspot/share/prims/resolvedMethodTable.cpp

Many (though not all) uses of object_peek occur in conjunction with a call to vmtarget for the peeked object. It might be worth adding a helper for that case, to reduce the number of peek calls that need to be monitored to ensure the peeked value doesn't escape.

Hm, but what happens to the vmtarget if the peeked object were to die? If the vmtarget dies too (or might die too), then this might not help after all.

==============================================================================

More information about the hotspot-dev mailing list