RFR 8080911: sun/security/krb5/auto/UseCacheAndStoreKey.java timed out intermittently

[Xuelei Fan]

On 5/26/2015 9:06 AM, Weijun Wang wrote:
> On 5/26/2015 7:59 AM, Xuelei Fan wrote:
>> synchronized on class looks a little bit unsafe to me.
> 
> Why? Isn't it the same as making a static method synchronized? [1]
> 
Other code may be also able to lock on class.

Code 1:
lock on MyClass.class

Code 2:
lock on MyClass.class

Code 1 and 2 know nothing about each other.  The behavior may be weird.
 I don't think it is a good practice.

>> As singleton is
>> a static variable, creating the instance during initialization looks
>> safer.
>>
>> -   private static Config singleton = null;
>> +   private static Config singleton = new Config();
> 
> This line might throw an exception. Also, do you intend to make
> getInstance() simply returning singleton? This means if the first call
> to new Config() throws an exception, getInstance() will not try to
> reconstruct it. This might not be common in production, but I don't want
> to make any behavior change.
> 
I see you point.  Maybe, you can lock on a object.

Xuelei

> --Max
> 
> [1]
> https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3.6
> 
>>
>> Xuelei
>>
>> On 5/25/2015 10:16 PM, Weijun Wang wrote:
>>> Hi All
>>>
>>> Please review a code change at
>>>
>>>    http://cr.openjdk.java.net/~weijun/8080911/webrev.00/
>>>
>>> I've limit the synchronized block to Config creation only and therefore
>>> won't deadlock with EType's class initialization.
>>>
>>> Noreg-hard. The EType call is at class initialization and only run once
>>> in a VM session, which is extremely difficult to catch.
>>>
>>> Thanks
>>> Max
>>