On 2020-06-23 00:30, Roger Riggs wrote:
Hi Claes,
Looks good.
Thanks!
Thanks for the followup.
No problem.
/Claes
Roger
On 6/22/20 6:29 PM, Claes Redestad wrote:
Hi,
inlining the new method actually messed up microbenchmark scores a
lot (15-80% overhead). I settled for simplifying
Hi Claes,
Looks good.
Thanks for the followup.
Roger
On 6/22/20 6:29 PM, Claes Redestad wrote:
Hi,
inlining the new method actually messed up microbenchmark scores a
lot (15-80% overhead). I settled for simplifying the duplicate
permsMap.get in the outer method in a way that keeps scores neu
Hi,
inlining the new method actually messed up microbenchmark scores a
lot (15-80% overhead). I settled for simplifying the duplicate
permsMap.get in the outer method in a way that keeps scores neutral:
http://cr.openjdk.java.net/~redestad/8247995/open.01/
Benchmark
Hi Roger,
I prototyped it as such, and saw a 0.4ns/op overhead in the
PermissionImplies.withoutPermission. Thinking about it a bit now, this
should be the rare path taken, since it means the permission is not
implied and the performance largely irrelevant. I'll simplify as you
suggested.
/Clae
Hi Claes,
Its correct as is but I would have written it without duplicating the
'permsMap.get(p.getClass())' invocation
and as a single method (unless the inlining of
getPermissionCollection(p,create)) is important.
A patch on top of yours:
diff --git a/src/java.base/share/classes/java/secur
Hi,
this patch fixes a corner-case performance issue with
Permissions.implies(Permission) by not needing to allocate a mapper
function (or lambda) on each invocation of getPermissionCollection
when there are unresolved permissions present.
Bug: https://bugs.openjdk.java.net/browse/JDK-8247995
