RFR: 8177845: Need a mechanism to load Graal

[Doug Simon]

> On 19 Apr 2017, at 20:01, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
>> 
>> On Apr 19, 2017, at 8:03 AM, Peter Levart <peter.levart at gmail.com> wrote:
>> 
>> Hi Alan,
>> 
>> On 04/19/2017 03:41 PM, Alan Bateman wrote:
>>> On 19/04/2017 08:37, Peter Levart wrote:
>>> 
>>>> :
>>>> 
>>>> Note that Properties class is thread-safe, while HashMap isn't. But I think this should not be a problem here, as during initPhase1(), as far as I know, no threads apart from main thread are started yet (is this true?), so anyone accessing getSavedProperty(ies) will either be the main thread itself or a thread started afterwards, so there is a happens-before relationship.
>>> The ReferenceHandler and Finalizer threads are started early, before initPhase1. However, both should immediately block and in the case of the Finalizer, await the completion of initPhase1 before polling.
>>> 
>>> -Alan
>> 
>> Just out of curiosity, what guarantees are there that no code before VM.saveAndRemoveProperties() ever executes Integer.valueOf(int) method for example? Note that this call is implicitly hidden in autoboxing of int(s)...
>> 
>> If this happens, then class initialization of Integer.IntegerCache may fail, because it is using VM.getSavedProperty():
>> 
>>   public static String getSavedProperty(String key) {
>>       if (savedProps.isEmpty())
>>           throw new IllegalStateException("Should be non-empty if initialized");
>> 
>>       return savedProps.getProperty(key);
>>   }
>> 
>> Hm....
> 
> We should catch this issue and detect if VM.getSavedProperty is called when init level < 1 during early startup.

What are you proposing? Some extra testing of VM startup to see if this is an issue? If so, can you please suggest what testing is to be performed.

-Doug