> On 19 Apr 2017, at 20:01, Mandy Chung <mandy.ch...@oracle.com> wrote:
>
>>
>> On Apr 19, 2017, at 8:03 AM, Peter Levart <peter.lev...@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
