No problem, thanks for double checking. ;)
Valerie
On 3/12/2020 4:42 AM, Daniel Fuchs wrote:
Hi Valerie,
Please ignore my comment. Sorry for the noise.
I somehow clicked on the wrong webrev link :-(
best regards,
-- daniel
On 12/03/2020 11:35, Daniel Fuchs wrote:
Hi Valerie,
Given that ha
Hi Valerie,
Please ignore my comment. Sorry for the noise.
I somehow clicked on the wrong webrev link :-(
best regards,
-- daniel
On 12/03/2020 11:35, Daniel Fuchs wrote:
Hi Valerie,
Given that hasKeyAttributes is already decelared as volatile,
may I suggest the following change that uses do
Hi Valerie,
Given that hasKeyAttributes is already decelared as volatile,
may I suggest the following change that uses double locking?
It will avoid synchronizing in the happy case where `hasKeyAttributes`
has already been computed.
1924 private boolean hasKeyAttributes() {
1925
Looks fine to me.
Xuelei
On 3/11/2020 1:31 PM, Valerie Peng wrote:
Anyone can help reviewing this?
I addressed this by applying the double-checked-locking pattern for lazy
initialization of instance fields.
Existing code already have most of the code structured for the pattern
but misses
Anyone can help reviewing this?
I addressed this by applying the double-checked-locking pattern for lazy
initialization of instance fields.
Existing code already have most of the code structured for the pattern
but misses the second check.
Bug: https://bugs.openjdk.java.net/browse/JDK-823
