<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body style="background-color: rgb(255, 255, 255); color: rgb(0, 0,
0);" bgcolor="#FFFFFF" text="#000000">
Hi Claes,<br>
<br>
A nice find! This is certainly a straightforward and low-risk fix
for breaking the initialization cycle problem with JDK-8062389.<br>
<br>
Related to VarHandles, the call trace of the initialization cycle
also includes the following part of code in VarHandle:<br>
<br>
<br>
AccessMode(final String methodName, AccessType at) {<br>
this.methodName = methodName;<br>
this.at = at;<br>
<br>
// Assert that return type is correct<br>
// Otherwise, when disabled avoid using reflection<br>
assert at.returnType == getReturnType(methodName);<br>
}<br>
<br>
...<br>
<br>
private static Class<?> getReturnType(String name) {<br>
try {<br>
Method m = VarHandle.class.getMethod(name,
Object[].class);<br>
return m.getReturnType();<br>
}<br>
catch (Exception e) {<br>
throw newInternalError(e);<br>
}<br>
}<br>
<br>
<br>
... where enabling assertions (tests enable assertions) causes the
initialization of VarHandle(s) to involve reflection. This is also a
place that could be made more robust, perhaps by devising a special
test that verifies method return types, instead of embedding the
check into the AccessMode constructor...<br>
<br>
Regards, Peter<br>
<br>
<br>
<div class="moz-cite-prefix">On 12/27/2016 03:04 PM, Claes Redestad
wrote:<br>
</div>
<blockquote
cite="mid:a69399a5-7138-4fdd-234e-6a241a020a4f@oracle.com"
type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->Hi,
<br>
<br>
since java.util.concurrent.AtomicReference was changed to use a
<br>
VarHandle internally, using it from within the security libraries
can
<br>
lead to hard to diagnose bootstrap cycles (since VarHandles has to
do
<br>
doPrivileged calls during setup). The need to initialize
VarHandles is
<br>
also cause for a small startup regression for any application run
with
<br>
a security manager.
<br>
<br>
The use of AtomicReference in java.security.Policy is not really
<br>
motivated, though, since only the .get/.set methods are used, thus
a
<br>
rather straight-forward fix is to convert the code to use a
volatile
<br>
reference instead with identical semantics:
<br>
<br>
Bug: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8172048">https://bugs.openjdk.java.net/browse/JDK-8172048</a>
<br>
Webrev: <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~redestad/8172048/webrev.01/">http://cr.openjdk.java.net/~redestad/8172048/webrev.01/</a>
<br>
<br>
While a rather insignificant startup improvement in and off
itself,
<br>
this would help to unblock the attempted fix to resolve
<br>
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8062389">https://bugs.openjdk.java.net/browse/JDK-8062389</a>
<br>
<br>
Thanks!
<br>
<br>
/Claes
<br>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
</body>
</html>