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

[dean.long at oracle.com]

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:

http://cr.openjdk.java.net/~dlong/8218700/webrev.3/

> 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.

dl

> 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