[PATCH] continuation of JDK-6736490

[Сергей Цыпанов]

Hello,

in June I sent a letter regarding clean-ups of unnecessary explicit initialization of volatile variables [1].
Original mail caused some discussion regarding whether clean-up is safe as of JMM.

It turned out that Aleksey Shipilev tried to find conter-example against removal of explicit initialization of volatile variables
in concurrency-interest [2] and didn't find any.

Also Doug Lea mentions in the same discussion [3]

> But your account is a more careful version of reasoning
we've done before to conclude that there is never any reason to explicitly
initialize fields to 0/0.0/false/null.

The original message of mine was then forwarded to security-dev list as affected code related to security-libs [4]
and Sean Mullan issued JDK-8251548 as sub-issue of JDK-6736490 which already includes similar clean-up done for
java.base.

There is also a plenty of possible volatile clean-ups (I've included them into a separate patch here), so I have two questions:

1) Could anyone sponsor the changes related to JDK-8251548 (patch is attached to [1])?
2) Should we create one more sub-issue in JDK-6736490 to handle the rest of changes (attached to this mail) or handle them
module by module?

Patch is attached, tier1 and tier2 are ok

1. https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067341.html
2. http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html
3. http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html
4. https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022289.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: volatile-rest.patch
Type: text/x-diff
Size: 26564 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20200820/6208d939/volatile-rest-0001.patch>