Perfect, thank you for encoding exact 16 bytes on each line and have them
aligned.
Thanks,
Max
> On Jun 23, 2020, at 7:39 AM, Jamil Nimeh wrote:
>
> Hi Weijun,
>
> I've got a new webrev with the test vectors as hexdumps of the DER encoding.
> Let me know what you think.
>
> https://cr.open
Hi Weijun,
I've got a new webrev with the test vectors as hexdumps of the DER
encoding. Let me know what you think.
https://cr.openjdk.java.net/~jnimeh/reviews/8239950/webrev.02
--Jamil
On 6/22/20 7:56 AM, Jamil Nimeh wrote:
Sure, I have code in other tests to do the conversions into hexdum
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
Hello,
while investigating an issue I've found out that assignment of default value to
volatile fields slows down object instantiation.
Consider the benchmark:
@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@BenchmarkMode(value = Mode.AverageTime)
@Fork(jvmArgsAppend = {"-Xms2g", "-
HI Sean,
Looks OK based on our exchanges. Thank you for your time on this one!
Best
Lance
> On Jun 22, 2020, at 7:22 AM, Seán Coffey wrote:
>
> Thanks Lance.
>
> I've updated the patch with some extra offline feedback from yourself and Max.
> A new warning is printed with use of the new flag
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
Sure, I have code in other tests to do the conversions into hexdumps as
well. I'll convert those today and send a new review out. Thanks for
looking this over, Max!
--Jamil
On 6/22/2020 12:42 AM, Weijun Wang wrote:
Source change looks fine to me.
One small suggestion: Is it possible to enc
Thanks Lance.
I've updated the patch with some extra offline feedback from yourself
and Max.
A new warning is printed with use of the new flag. A warning is also
printed when file posix permissions are detected on resources being
signed. Test updated for that also.
https://cr.openjdk.java.ne
On 18/06/2020 19:33, Martin Balao wrote:
> * sharedRuntime_x86_64.cpp
> * L3685
>* Do we still need 'long long' type for 'i' and 'cnt' local variables?
No, but this is 64-bit-only code. And len is a long, so let's keep it.
> * L3724
>* The last argument of 'sub' has type 'int', while
Source change looks fine to me.
One small suggestion: Is it possible to encode the bytes in the test as HEX
instead of BASE64? If so, I can use my human eyes to look at the content.
HexPrinter in test/lib can be used to generate them and Utils.toByteArray can
be used to translate them back to b
14 matches
Mail list logo
