On 17/02/2015 20:59, Jason Uh wrote:
Please review this fix, which removes the sun.security.acl package.
webrev: http://cr.openjdk.java.net/~juh/8072663/00/
jbs: http://bugs.openjdk.java.net/browse/JDK-8072663
The sun.security.acl package is the default implementation of
java.security.acl but
Hi,
CipherInputStream and CipherOutputStream call the Cipher methods update
and doFinal which produce new byte array. It may consume a large amount
of memory.
The purpose of my patch is to avoid this. Could you review the patch?
Thanks,
Dai
--- old/src/share/classes/javax/crypto/CipherInputStre
On 02/17/2015 03:52 PM, Florian Weimer wrote:
On 02/17/2015 11:30 PM, Vladimir Kozlov wrote:
The concern was about java code and not intrinsic. If intrinsic is not
used we will get additional range checks which were not present before.
By indirect load I mean object->array_oop->element instead
Ok, I'll add these checks.. Thanks for looking through this.
Tony
On 02/17/2015 02:30 PM, Vladimir Kozlov wrote:
The concern was about java code and not intrinsic. If intrinsic is not
used we will get additional range checks which were not present before.
By indirect load I mean object->array_
On 02/17/2015 11:30 PM, Vladimir Kozlov wrote:
> The concern was about java code and not intrinsic. If intrinsic is not
> used we will get additional range checks which were not present before.
>
> By indirect load I mean object->array_oop->element instead of
> object->field.
>
> But in blockMult
The concern was about java code and not intrinsic. If intrinsic is not
used we will get additional range checks which were not present before.
By indirect load I mean object->array_oop->element instead of object->field.
But in blockMult() you access them outside main loops. As result the
code
On 02/17/2015 01:14 PM, Vladimir Kozlov wrote:
Florian's concern is valid.
"Range check elimination" means that C2 moves checks from a loop. Checks
are still present. Since 'state' array is not final we can't eliminate
range check.
I don't understand the concern here. The arrays are private a
Looks fine to me (pending CCC approval).
--Sean
On 02/17/2015 03:59 PM, Jason Uh wrote:
Please review this fix, which removes the sun.security.acl package.
webrev: http://cr.openjdk.java.net/~juh/8072663/00/
jbs: http://bugs.openjdk.java.net/browse/JDK-8072663
The sun.security.acl package is
Florian's concern is valid.
"Range check elimination" means that C2 moves checks from a loop. Checks
are still present. Since 'state' array is not final we can't eliminate
range check. An other thing is an additional indirect load to access
arrays elements.
I would suggest to keep original c
On 02/17/2015 12:05 PM, Florian Weimer wrote:
On 02/17/2015 08:59 PM, Anthony Scarpino wrote:
On 02/17/2015 12:57 AM, Florian Weimer wrote:
On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
I think the “state” field in GHASH should be f
Please review this fix, which removes the sun.security.acl package.
webrev: http://cr.openjdk.java.net/~juh/8072663/00/
jbs: http://bugs.openjdk.java.net/browse/JDK-8072663
The sun.security.acl package is the default implementation of
java.security.acl but it's not used in JDK. The JCK tests fo
On 02/17/2015 09:03 PM, Anthony Scarpino wrote:
> On 02/17/2015 02:59 AM, Florian Weimer wrote:
>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
>>> Hi,
>>>
>>> I'm requesting a code review to intrinsify the GHASH operations for both
>>> x86 and SPARC platforms. This greatly increases performanc
On 02/17/2015 08:59 PM, Anthony Scarpino wrote:
> On 02/17/2015 12:57 AM, Florian Weimer wrote:
>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
>>
>> I think the “state” field in GHASH should be final. Is C2 able to
>> eliminate the
On 02/17/2015 02:59 AM, Florian Weimer wrote:
On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
Hi,
I'm requesting a code review to intrinsify the GHASH operations for both
x86 and SPARC platforms. This greatly increases performance over
software for AES/GCM crypto operations, details are in the
On 02/17/2015 12:57 AM, Florian Weimer wrote:
On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
I think the “state” field in GHASH should be final. Is C2 able to
eliminate the array bounds checks? (Although it's not in the inner loop
an
On 02/17/2015 10:41 AM, Vladimir Kozlov wrote:
On 2/17/15 10:31 AM, Anthony Scarpino wrote:
On 02/16/2015 06:01 PM, Vladimir Kozlov wrote:
There is #ifdef _WIN64 in stubGenerator_x86_32.cpp. It is not needed
since it is 32-bit code.
Sure.. Do I still need to save the xmm6 and xmm7 on 32bit co
You should probably update the keytool doc to say that if duplicate
extensions are specified, only the last one is added.
Also, unrelated to you fix but can you break up that really long line
(1213) in KeyToolTest?
Looks fine otherwise.
--Sean
On 02/16/2015 02:56 AM, Weijun Wang wrote:
Ple
On 02/16/2015 06:47 PM, John Rose wrote:
Cool stuff. I'm glad to see SPARC xmulx getting some play.
This is not a review, but I have a small and a big comment.
You don't need the argument vmIntrinsics::ID id unless you are going
to do something with it, such as expand one of a family of intrin
On 2/17/15 10:31 AM, Anthony Scarpino wrote:
On 02/16/2015 06:01 PM, Vladimir Kozlov wrote:
On 2/16/15 5:23 PM, David Holmes wrote:
Hi Tony,
Not a review as hotspot compiler folk need to review this.
On 17/02/2015 7:11 AM, Anthony Scarpino wrote:
Hi,
I'm requesting a code review to intrinsi
Looks good.
--Sean
On 02/16/2015 01:53 PM, Jason Uh wrote:
Thanks Sean.
Here it is with your suggested changes:
http://cr.openjdk.java.net/~juh/8042967/04/
Opened an issue to track the docs changes:
https://bugs.openjdk.java.net/browse/JDK-8073261
Jason
On 02/16/2015 10:22 AM, Sean Mullan
On 02/16/2015 06:01 PM, Vladimir Kozlov wrote:
On 2/16/15 5:23 PM, David Holmes wrote:
Hi Tony,
Not a review as hotspot compiler folk need to review this.
On 17/02/2015 7:11 AM, Anthony Scarpino wrote:
Hi,
I'm requesting a code review to intrinsify the GHASH operations for both
x86 and SPARC
On 02/16/2015 11:13 PM, Sean Mullan wrote:
>> Based on that, PolicyQualifierInfo should have implemented value-based
>> equals() and hashCode(), and the identity-based set is just a bug. (But
>> the requirement I cited is a stronger requirement the Set would not
>> enforce.)
>>
>> However, I thin
On 02/16/2015 06:32 PM, Anthony Scarpino wrote:
On 02/16/2015 02:48 PM, Sean Mullan wrote:
On 02/16/2015 02:57 PM, Anthony Scarpino wrote:
FYI, the bug number should be JDK-8043951. The one I listed was the
backport ID. The link below is still valid
Normally, the bug in the comment above a
On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
> Hi,
>
> I'm requesting a code review to intrinsify the GHASH operations for both
> x86 and SPARC platforms. This greatly increases performance over
> software for AES/GCM crypto operations, details are in the bug.
>
> The review is for two repos,
On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
I think the “state” field in GHASH should be final. Is C2 able to
eliminate the array bounds checks? (Although it's not in the inner loop
and thus probably not relevant for performance.)
25 matches
Mail list logo
