On 16/06/15 18:49, Thomas Lußnig wrote:
Hi,
two points that come directly to my mind when i checked the code:
1) An Error in the description.
+ // If plast >= plen then restrictedPkg is longer than pkg by at
+ // least one char. This means pkg cannot start with restrictedPkg,
+ // since restrictedPkg will be longer than pkg.
+ //
+ // Similarly if plast != plen, then pkg + "." cannot be the same
+ // as restrictedPkg, since pkg + "." will have a different length
+ // than restrictedPkg.
If this would be correct then where would never be an match because
!(plast >= plen) && !(plast != plen) must be true for an possible match.
That could be rewriten to (plast < plen) && (plast == plen) and this is
always FALSE.
Hi Thomas - I believe the description is correct:
plast >= plen <=> restrictedPkg.length() -1 >= pkg.length()
<=> restrictedPkg.length() >= pkg.length() + 1
which does means pkg.startsWith(restrictedPkg) == false
plast != plen <=> restrictedPkg.length() -1 != pkg.length()
<=> restrictedPkg.length() != pkg.length() + 1
which does means that restrictedPkg.equals(pkg + ".") == false
2) Would it be worth to use the state Engine instead of looping over the array ?
When I investigated the issue I found that using the state engine only
brought a marginal improvement - compared to what is proposed here.
Given the additional complexity that the state engine brings - I
believe that looping over the array is the appropriate choice.
The state engine is still in the test in case someone decides one
day that the marginal improvements are worthy ;-)
best regards,
-- daniel
Gruß Thomas
On 16.06.2015 16:54, Sean Mullan wrote:
This is the sixth in a series of fixes for JEP 232 (Improve Secure
Application Performance) [1].
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8072692/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8072692
This fix adds several optimizations to the package matching algorithm
used by the SecurityManager.checkPackageAcccess method. These
improvements result in a 5-7x increase in throughput of this method. A
performance chart has been attached to the bug with more information.
A new test is included which uses a state machine to verify that the
matching algorithm is working correctly.
Special thanks to Daniel Fuchs for contributing this fix and the test.
Thanks,
Sean
[1] http://openjdk.java.net/jeps/232
