Agreed.. webrev updated.. I inadvertently updated in-place.
Tony
On 2/6/19 2:19 PM, Valerie Peng wrote:
Hi Tony,
Changes look fine, just some nits.
- line 402, 96 bit should be 96-byte?
- line 408, can we not use "l"? It looks too similar to "1"
- As for the comments on line 586, 587, It
Hi Tony,
Changes look fine, just some nits.
- line 402, 96 bit should be 96-byte?
- line 408, can we not use "l"? It looks too similar to "1"
- As for the comments on line 586, 587, It seems to be for the "else"
part of this if-condition. So I find it a bit confusing. Maybe simplify
it to s
Andrew's fix looked much more complicated than running a simple loop in
the byte code. The way I read CompileCommand, I don't think it applies
to intrinsics, or at least I don't see how it relates to make this easier.
The slow start seems to be getting enough attention that addressing it
is p
I'm still not sold on this---it seems like a specific solution to a
single instance of a more general problem.
Have you investigated any tweaks to the JVM or compiler settings? Andrew
prototyped something[1], but it looks like this is also specific to GCM.
A more general solution would be some
Hi Séan,
Change looks fine.
I usually think there is no need to provide data in the debug output that were
already available from public APIs (i.e. they are not something that can only
be revealed from "internally"), but these numbers could help a supporter
engineer to quickly find out if ther
Looking to improve debug output in the keystore area.
It's useful to know how many keys/certs are found in such stores
to ensure correct set up.
https://bugs.openjdk.java.net/browse/JDK-8218553
http://cr.openjdk.java.net/~coffeys/webrev.8218553/webrev/
--
Regards,
Sean.
