Yes one review is enough to push to jdk9/dev (until later in the development
cycle).
Your change looks fine to me. What about the question Sean asked about
CheckPackageMatching? I think that test is passing.
Mandy
> On Aug 27, 2015, at 7:12 PM, Pete Brunet wrote:
>
>
>
> On 8/27/15 8:37
On 8/27/15 8:37 PM, Sean Mullan wrote:
> Great, go ahead and push the fix.
Is one review (yours) enough?
>
> --Sean
>
> On 8/27/15 7:49 PM, Pete Brunet wrote:
>> JPRT jdk_lang tests ran clean, 7 builds passed, 8 tests passed.
>> http://scaaa637.us.oracle.com//archive/2015/08/2015-08-27-204226.pbr
Great, go ahead and push the fix.
--Sean
On 8/27/15 7:49 PM, Pete Brunet wrote:
JPRT jdk_lang tests ran clean, 7 builds passed, 8 tests passed.
http://scaaa637.us.oracle.com//archive/2015/08/2015-08-27-204226.pbrunet.dev
command line:
jprt submit -stree . -email [email protected] -c JDK-
On 8/27/15 4:43 AM, Sean Mullan wrote:
I don't think the different signature variants buy you much, since
what you are mainly testing here is the ability to parse the created
certificate without errors. I would simplify the test by just having a
single test for each key type.
--Sean
Test up
JPRT jdk_lang tests ran clean, 7 builds passed, 8 tests passed.
http://scaaa637.us.oracle.com//archive/2015/08/2015-08-27-204226.pbrunet.dev
command line:
jprt submit -stree . -email [email protected] -c JDK-8134456
-buildenv SKIP_BOOT_CYCLE=false -noqa -ot '.*product.*' -onlytests
'.*jdk_la
Hi Sean, I might need to make a change but this is the JTREG output from
my local run
jtreg -jdk:./build/windows-x86_64-normal-server-release/images/jdk
./jdk/test/java/lang/SecurityManager/
Execution successful
java/lang/SecurityManager/CheckPackageAccess.java: Make sure all
restricted packages
This looks good to me, if the JPRT results are good. However, does this
also fix the failure in CheckPackageMatching? I would have expected you
needed an additional fix - see my subsequent comment:
https://bugs.openjdk.java.net/browse/JDK-8134456?focusedCommentId=13837407&page=com.atlassian.ji
Please review a patch for a test change which is needed to fix an issue
caused by JDK-8051626. Tier 1 tests are being impacted.
http://cr.openjdk.java.net/~ptbrunet/JDK-8134456/webrev.00/
Pete
I've been looking at the performance of AES/GCM. The profile is quite
surprising:
samples cum. samples %cum. % symbol name
476009 47600936.7033 36.7033 aescrypt_encryptBlock
297239 77324822.9190 59.6224 ghash_processBlocks
195334 96858215.0615 74.6839 i
On 08/26/2015 07:16 PM, Rajan Halade wrote:
Hi Sean,
On 8/26/15 8:39 AM, Sean Mullan wrote:
This looks ok now, although I would probably eliminate the tests for
SHA-1 and bump up the keysize to 2048, so that this test won't have to
be updated when those algorithms/keysizes are constrained in th
10 matches
Mail list logo