RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API (original) (raw)
coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Mon Nov 27 18:33:05 UTC 2017
- Previous message: RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API
- Next message: RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
This looks good. I think we should make the literal() function in this hashtable a pure virtual function and ShouldNotReachHere to not allow it for these classes derived from oop.
BTW, should we expect a StringTable and ProtectionDomainEntryTable change as well? The latter is missing the SATB barrier at the moment.
Coleen
On 11/27/17 10:33 AM, Erik Österlund 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
- Previous message: RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API
- Next message: RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]