RFR(S) 8218700: infinite loop in HotSpotJVMCIMetaAccessContext.fromClass after OutOfMemoryError

dean.long at oracle.com dean.long at oracle.com
Fri May 3 06:47:29 UTC 2019

On 5/1/19 5:44 PM, Tom Rodriguez wrote:
> You'll need to update your webrev after Vladimir's push.  This code 
> has moved into HotSpootJVMCIRuntime.java.

Here's the updated version:


> Maybe WeakReferenceHolder instead of WeakTypeRef?  It needs a comment 
> explaining that we're intentionally avoiding the use of 
> ClassValue.remove as well.  Shouldn't the ref field be volatile? 
> ClassValue includes some barrier semantics and the new code needs 
> similar guarantees.

I went ahead and made it volatile, but I don't understand what guarantee 
was missing, and what problem we want to eliminate, unless it is to 
reduce the possibility of duplicates.  But the fix for JDK-8201248 
assumes that duplicates are possible, so I wasn't worried about that.


> tom
> dean.long at oracle.com wrote on 4/26/19 12:09 PM:
>> https://bugs.openjdk.java.net/browse/JDK-8218700
>> http://cr.openjdk.java.net/~dlong/8218700/webrev.2/
>> If we throw an OutOfMemoryError in the right place (see JDK-8222941), 
>> HotSpotJVMCIMetaAccessContext.fromClass can go into an infinite loop 
>> calling ClassValue.remove.  To work around the problem, reset the 
>> value in a mutable cell instead of calling remove.
>> dl

More information about the graal-dev mailing list