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 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 Boolean b = hasKeyAttributes;
if (b != null) return b;
synchronized (this) {
b = hasKeyAttributes;
1926 if (b != null) return b;
1927 String s;
1928 s = getAttribute("SupportedKeyFormats");
...
1948 hasKeyAttributes = b;
1949 }
1950 return b;
1951 }
best regards,
-- daniel
On 11/03/2020 20:31, 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 the second check.
Bug: https://bugs.openjdk.java.net/browse/JDK-8238566
Webrev: http://cr.openjdk.java.net/~valeriep/8238566/webrev.00/
Thanks,
Valerie
