<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Max,<br>
<br>
On 6/17/15 2:42 AM, Weijun Wang wrote:<br>
</div>
<blockquote cite="mid:5580C272.60407@oracle.com" type="cite">1478
final int plast = restrictedPkg.length() - 1;
<br>
<br>
Why is it named plast?
<br>
</blockquote>
<br>
Right. That's a bad name. Maybe 'rlast' would be more appropriate.<br>
Any better name for 'the index of the last character in
restrictedPkg'?<br>
<br>
<blockquote cite="mid:5580C272.60407@oracle.com" type="cite">
<br>
1494 // - we check that restrictedPkg.length is pkg.length +
1,
<br>
1495 // - we check that restrictedPkg starts with pkg,
<br>
1496 // - and we check that the last character in
restrictedPkg
<br>
1497 // is '.'
<br>
<br>
Seems redundant. The check below is not difficult to read.
<br>
<br>
Also, is checking the "." at the end of restrictedPkg useful? On
the one hand we know every item in package.access should always
end with it. On the other hand, if someone really adds a "sun"
there, the 1st part of the check could go wrong (For example,
"sunw" matches). IMHO, either we don't check it at all (hoping
property is always set correctly), or we always check for it
(cover both "sun.tail" and "sun").
<br>
</blockquote>
<br>
Possibly - but that would be a behavioral change. The current test:<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<pre><span class="changed">plast == plen && restrictedPkg.startsWith(pkg) &&</span> <span class="changed">restrictedPkg.charAt(plast) == '.'
</span></pre>
<br>
is strictly equivalent to the old test:<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<pre><span class="changed">restrictedPkg.equals(pkg + ".")</span></pre>
<br>
(side note: pkg + "." was the root of the perf issue).<br>
<br>
<br>
best regards,<br>
<br>
-- daniel<br>
<br>
<blockquote cite="mid:5580C272.60407@oracle.com" type="cite">
<br>
Thanks
<br>
Max
<br>
<br>
On 06/16/2015 10:54 PM, Sean Mullan wrote:
<br>
<blockquote type="cite">This is the sixth in a series of fixes for
JEP 232 (Improve Secure
<br>
Application Performance) [1].
<br>
<br>
webrev:
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~mullan/webrevs/8072692/webrev.00/">http://cr.openjdk.java.net/~mullan/webrevs/8072692/webrev.00/</a>
<br>
bug: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8072692">https://bugs.openjdk.java.net/browse/JDK-8072692</a>
<br>
<br>
This fix adds several optimizations to the package matching
algorithm
<br>
used by the SecurityManager.checkPackageAcccess method. These
<br>
improvements result in a 5-7x increase in throughput of this
method. A
<br>
performance chart has been attached to the bug with more
information.
<br>
<br>
A new test is included which uses a state machine to verify that
the
<br>
matching algorithm is working correctly.
<br>
<br>
Special thanks to Daniel Fuchs for contributing this fix and the
test.
<br>
<br>
Thanks,
<br>
Sean
<br>
<br>
[1] <a class="moz-txt-link-freetext" href="http://openjdk.java.net/jeps/232">http://openjdk.java.net/jeps/232</a>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>