Re: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java

Changes look fine. I will work on integrating this shortly. Valerie On 1/30/2017 12:08 PM, Sean Mullan wrote: The fix looks ok to me, but I would also like Valerie to review it since she is more familiar with this code. As far as JDK 9 goes, we are in Rampdown Phase 1. According to the rules

Re: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java

Thank you! On Mon, Jan 30, 2017 at 3:15 PM, Valerie Peng wrote: > > I can push the fix for you after looking it over and running it through > the regular testing process. > Thanks, > Valerie > > > On 1/30/2017 2:13 PM, Chuck Rasbold wrote: > > Thanks, Sean. Waiting for Valerie sounds good to me.

Re: RFR: 8160655 Fix denyAfter and usage types for security properties

On 01/23/2017 03:27 PM, Anthony Scarpino wrote: Hi, I need a code review of this change that brings more detail constraints checking and control to certpath and jar disabled algorithm Security properties. http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ thanks Tony Updated review http

Re: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java

I can push the fix for you after looking it over and running it through the regular testing process. Thanks, Valerie On 1/30/2017 2:13 PM, Chuck Rasbold wrote: Thanks, Sean. Waiting for Valerie sounds good to me. It has been quite some time since I've had the joy of directly pushing my own

Re: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java

I am currently in a meeting and will take a look after this meeting finished. Thanks, Valerie On 1/30/2017 2:27 PM, Martin Buchholz wrote: I judge this to be more serious than P3, even though correctness is not affected, since production services have noticed unacceptable performance regress

Re: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java

I judge this to be more serious than P3, even though correctness is not affected, since production services have noticed unacceptable performance regressions. On Mon, Jan 30, 2017 at 12:08 PM, Sean Mullan wrote: > The fix looks ok to me, but I would also like Valerie to review it since > she is

Re: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java

Thanks, Sean. Waiting for Valerie sounds good to me. It has been quite some time since I've had the joy of directly pushing my own fix. I can do it myself, or hand it over to the Security team - whatever you prefer. On Mon, Jan 30, 2017 at 12:08 PM, Sean Mullan wrote: > The fix looks ok to me,

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: > > >> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >> >> >>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>> >>> I’ve extended the webrev with that change - please re-review: >>> >>> http://cr.openjdk.java.net/~dnsimon/8145337_make/web

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On 30 Jan 2017, at 17:11, Mandy Chung wrote: > > Moving it to platform class loader is okay with me. I’m still unsure if > jdk.vm.compiler should be defined by the boot loader instead and you may want > to look into in a future release. We also want jdk.vm.compiler to be upgradeable (as di

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On 29 Jan 2017, at 20:34, Igor Veresov wrote: > >> >> On Jan 27, 2017, at 3:40 PM, Christian Thalinger >> wrote: >> >>> >>> On Jan 26, 2017, at 7:40 AM, Doug Simon wrote: >>> On 26 Jan 2017, at 17:55, Mandy Chung wrote: > On Jan 26, 2017, at 3:13 AM, Doug Sim

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On Jan 26, 2017, at 7:40 AM, Doug Simon wrote: > >> >> On 26 Jan 2017, at 17:55, Mandy Chung wrote: >> >> >>> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote: >>> jdk.vm.compiler is defined by the application class loader and it’s used by AOT tool. I wonder why it has to

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On Jan 27, 2017, at 3:40 PM, Christian Thalinger > wrote: > >> >> On Jan 26, 2017, at 7:40 AM, Doug Simon > > wrote: >> >>> >>> On 26 Jan 2017, at 17:55, Mandy Chung >> > wrote: >>> >>> On Jan 26, 2017, at 3:13 AM, Doug Si

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: > > I’ve extended the webrev with that change - please re-review: > > http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev > +1 > Strangely, there was no existing declaration of jdk.vm.compiler in > Modules.gmk. > Default is to be defin

Re: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java

The fix looks ok to me, but I would also like Valerie to review it since she is more familiar with this code. As far as JDK 9 goes, we are in Rampdown Phase 1. According to the rules [1], since it is a P3 and is new in JDK 9 we should try to fix this issue if we can. Were you offering to pus

RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java

Here's a tiny fix for an unintended, but clear, performance regression. I'm not familiar of the current criteria for jdk9 changes. Please advise this mostly HotSpot engineer if / how to move forward. http://cr.openjdk.java.net/~rasbold/8173581/webrev.00/

Re: RFR: 8160655 Fix denyAfter and usage types for security properties

Hi Sean, Actually Sean M and I were talking about that offline on thursday. That file is changing a lot. The three sections you mention have changed a lot, but the general idea is the disabled algorithms are captured and reported after all the checks were done. This is because the we can h

Re: RFR: 8160655 Fix denyAfter and usage types for security properties

src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java CertPathValidatorException is caught 3 times in new code but we're not printing out the exact algorithm that caused the exception. AFAIK, that should be in the exception message. Would it be possible to use something e.ge