Re: RFR 7143743: (zipfs) Potential memory leak with zip provider

Looks fine Lance. I forgot about the copyright year, thank you for taking care of that one too. -Jaikiran On 14/01/20 1:56 am, Lance Andersen wrote: > > >> On Jan 13, 2020, at 1:53 PM, Alan Bateman > > wrote: >> >> On 13/01/2020 10:31, Jaikiran Pai wrote: >>>

Re: RFR: JDK-8233578: Document configurable parameters of msi packages

Looks good. Thanks, Alexander On 12/20/2019 8:56 AM, Andy Herrick wrote: looks good. /Andy On 12/19/2019 8:52 PM, Alexey Semenyuk wrote: Please review fix [2] for jpackage bug [1]. Comments added to the default WiX source file explaining how the default file is expected to be overridden.

Re: RFR: JDK-8232077: Investigate if default behavior should allow downgrade scenario

Looks good. Thanks, Alexander On 12/20/2019 8:53 AM, Andy Herrick wrote: fix looks fine. /Andy On 12/19/2019 8:02 PM, Alexey Semenyuk wrote: Please review fix [2] for jpackage bug [1]. The fix changes the default setting for Windows installers to allow downgrades. - Alexey [1]

Re: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

On Jan 13, 2020, at 1:23 PM, Claes Redestad wrote: > > On 2020-01-13 22:18, Paul Sandoz wrote: >> That’s fine, it was really for informational purposes in case it comes in >> handy later on. > > Got it. > >> Speculating: if we had such a public method (with minimal dependencies) I >> suspect

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

Thanks Alan. Updates made and changes pushed. regards, Sean. On 13/01/2020 18:50, Alan Bateman wrote: On 13/01/2020 10:28, Seán Coffey wrote: some off line comments suggested that I could move the jar initialization checks to the EventHelper class. With that in place, the EventHelper utility

Re: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

On 2020-01-13 22:18, Paul Sandoz wrote: That’s fine, it was really for informational purposes in case it comes in handy later on. Got it. Speculating: if we had such a public method (with minimal dependencies) I suspect we would reach for it in this case even if overkill. It reduces the

Re: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

> On Jan 13, 2020, at 1:12 PM, Claes Redestad wrote: > > On 2020-01-13 20:49, Paul Sandoz wrote: >> Looks good. > > Thanks! > >> 78 private static final Object[] EMPTY; >> Is there a specific reason related to archiving that this is Object[] and >> not Object and instead assigned a

Re: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

On 2020-01-13 20:49, Paul Sandoz wrote: Looks good. Thanks! 78 private static final Object[] EMPTY; Is there a specific reason related to archiving that this is Object[] and not Object and instead assigned a value of new Object() ? No, this was part of an experiment I did to have

Re: RFR 7143743: (zipfs) Potential memory leak with zip provider

> On Jan 13, 2020, at 1:53 PM, Alan Bateman wrote: > > On 13/01/2020 10:31, Jaikiran Pai wrote: >> Hello Christoph, >> >> Setting inodes to null sounds fine to me and as you say since its usage >> is already guarded by ensureOpen, IMO, it should be fine. I've now >> updated the patch to set

Re: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

On Jan 13, 2020, at 11:49 AM, Paul Sandoz wrote: > > For information purposes: an alternative salt might be to use mix32 from > Splittable random: > > /** > * Returns the 32 high bits of Stafford variant 4 mix64 function as int. > */ > private static int mix32(long z) { >z = (z ^ (z >>>

Re: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

Looks good. 78 private static final Object[] EMPTY; Is there a specific reason related to archiving that this is Object[] and not Object and instead assigned a value of new Object() ? -- For information purposes: an alternative salt might be to use mix32 from Splittable random: /** *

Re: RFR 7143743: (zipfs) Potential memory leak with zip provider

On 13/01/2020 10:31, Jaikiran Pai wrote: Hello Christoph, Setting inodes to null sounds fine to me and as you say since its usage is already guarded by ensureOpen, IMO, it should be fine. I've now updated the patch to set inodes to null in close() and the new updated webrev is at

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

On 13/01/2020 10:28, Seán Coffey wrote: some off line comments suggested that I could move the jar initialization checks to the EventHelper class. With that in place, the EventHelper utility class should never initialize the logging framework early during jar initialization.

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

On 13/01/2020 17:21, Chris Hegarty wrote: On 13 Jan 2020, at 17:19, Seán Coffey wrote: Thanks for the reviews. All callers of EventHelper log methods are ensuring that isLoggingSecurity() is true before proceeding. I've added an assert null check in the 4 logger methods to ensure

Re: [15] RFR: 8174270: Consolidate ICU sources in one location

approve -- Steven R. Loomis | @srl295 | git.io/srl295 > El ene. 10, 2020, a las 4:02 p. m., naoto.s...@oracle.com escribió: > > Hi Steven, > > On 1/10/20 2:26 PM, Steven R. Loomis wrote: >> in Norm2AllModes.java and UBiDiProps.java and UCharacterProperty.java the >> stub name (icudt64b)

Re: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage: Need to include strsafe.h after tchar.h

Thank you, pushed. -Aleksey On 1/13/20 5:41 PM, Andy Herrick wrote: > sure > > /Andy > > On 1/13/2020 11:03 AM, Aleksey Shipilev wrote: >> You good for this to go to jdk14? >> >> On 1/13/20 4:15 PM, Andy Herrick wrote: >>> I'm fine with this change. >>> >>> /Andy >>> >>> On 12/23/2019 6:52 PM,

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

> On 13 Jan 2020, at 17:19, Seán Coffey wrote: > > Thanks for the reviews. All callers of EventHelper log methods are ensuring > that isLoggingSecurity() is true before proceeding. I've added an assert null > check in the 4 logger methods to ensure expectations are in place. > >

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

Thanks for the reviews. All callers of EventHelper log methods are ensuring that isLoggingSecurity() is true before proceeding. I've added an assert null check in the 4 logger methods to ensure expectations are in place. http://cr.openjdk.java.net/~coffeys/webrev.8234466.v5/webrev/ Hope this

Re: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage: Need to include strsafe.h after tchar.h

sure /Andy On 1/13/2020 11:03 AM, Aleksey Shipilev wrote: You good for this to go to jdk14? On 1/13/20 4:15 PM, Andy Herrick wrote: I'm fine with this change. /Andy On 12/23/2019 6:52 PM, Alex Kashchenko wrote: Hi, Please review this minor change to jpackage, that is required for

Re: [15] RFR: 8174270: Consolidate ICU sources in one location

Looks fine to me also. Roger On 1/10/20 11:21 PM, Joe Wang wrote: I see. It's all good to me then. Best, Joe On 1/10/20 4:04 PM, naoto.s...@oracle.com wrote: Hi Joe, That data file seems no longer included in the ICU4J package (as of 64.2), thus I left it as it is. Naoto On 1/10/20

Re: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage: Need to include strsafe.h after tchar.h

You good for this to go to jdk14? On 1/13/20 4:15 PM, Andy Herrick wrote: > I'm fine with this change. > > /Andy > > On 12/23/2019 6:52 PM, Alex Kashchenko wrote: >> Hi, >> >> Please review this minor change to jpackage, that is required for >> successful compilation with VS2013 toolchain: >>

RFR: 8236641: Improve Set.of(...).iterator() warmup characteristics

Hi, we're doing plenty of iterations over Set.of() instances during bootstrap, which makes these operations show up prominently in startup profiles. This patch refactors a few hot methods to get a measureable startup improvement without regressing on targeted microbenchmarks. Bug:

Re: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage: Need to include strsafe.h after tchar.h

I'm fine with this change. /Andy On 12/23/2019 6:52 PM, Alex Kashchenko wrote: Hi, Please review this minor change to jpackage, that is required for successful compilation with VS2013 toolchain: Bug: https://bugs.openjdk.java.net/browse/JDK-8236125 Webrev:

Re: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

Hi, I included John's suggested salt improvement, reverted to use an EMPTY object marker rather than 'this', and removed the extraneous blank line Roger pointed out: http://cr.openjdk.java.net/~redestad/8236850/open.01/ /Claes On 2020-01-11 04:19, John Rose wrote: On Jan 10, 2020, at 6:48 PM,

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

On 13/01/2020 14:06, Chris Hegarty wrote: I’m going to ask, since I cannot find the answer myself. Why are some securityLogger::log invocations guarded with isLoggingSecurity, and others not? With this change shouldn’t all invocations be guarded, since it is isLoggingSecurity that assigns

Re: RFR 8222100: tools/jimage/JImageTest.java time out

+1 On the road. > On Jan 13, 2020, at 10:25 AM, sundararajan.athijegannat...@oracle.com wrote: > > Bumping the default timeout (other tests in the same dir have similar > timeout settings). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222100 > > Webrev:

RFR 8222100: tools/jimage/JImageTest.java time out

Bumping the default timeout (other tests in the same dir have similar timeout settings). Bug: https://bugs.openjdk.java.net/browse/JDK-8222100 Webrev: http://cr.openjdk.java.net/~sundar/8222100/webrev.00/ Thanks, -Sundar

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

> On 13 Jan 2020, at 13:14, Daniel Fuchs wrote: > > On 13/01/2020 10:28, Seán Coffey wrote: >> some off line comments suggested that I could move the jar initialization >> checks to the EventHelper class. With that in place, the EventHelper utility >> class should never initialize the

Re: RFR (14) 8235837: Memory access API refinements

> On 9 Jan 2020, at 18:36, Maurizio Cimadamore > wrote: > > New revision: > > http://cr.openjdk.java.net/~mcimadamore/8235837_v2 > > delta from previous iteration: > > http://cr.openjdk.java.net/~mcimadamore/8235837_v2_delta > > javadoc > >

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

On 13/01/2020 10:28, Seán Coffey wrote: some off line comments suggested that I could move the jar initialization checks to the EventHelper class. With that in place, the EventHelper utility class should never initialize the logging framework early during jar initialization.

Re: [14] RFR (S) 8236920: 32-bit build failures in libNativeAccess.c

Hi Alex, has this been addressed by Nick changes (JDK-8236634) ? Thanks Maurizio On 12/01/2020 11:15, Aleksey Shipilev wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8236920 Fix: https://cr.openjdk.java.net/~shade/8236920/webrev.01/ This breaks x86_32 test builds. I would like

Re: [14] RFR (S) 8236920: 32-bit build failures in libNativeAccess.c

On 1/13/20 1:22 PM, Maurizio Cimadamore wrote: > Hi Alex, > has this been addressed by Nick changes (JDK-8236634) ? Seems to be, I already closed my issue as duplicate. -- Thanks, -Aleksey

Re: [14] RFR (S) 8236920: 32-bit build failures in libNativeAccess.c

Thanks Maurizio On 13/01/2020 12:25, Aleksey Shipilev wrote: On 1/13/20 1:22 PM, Maurizio Cimadamore wrote: Hi Alex, has this been addressed by Nick changes (JDK-8236634) ? Seems to be, I already closed my issue as duplicate.

Re: RFR 7143743: (zipfs) Potential memory leak with zip provider

Hello Christoph, Setting inodes to null sounds fine to me and as you say since its usage is already guarded by ensureOpen, IMO, it should be fine. I've now updated the patch to set inodes to null in close() and the new updated webrev is at

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

some off line comments suggested that I could move the jar initialization checks to the EventHelper class. With that in place, the EventHelper utility class should never initialize the logging framework early during jar initialization.

Re: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy

Hi Bob, On Fri, 2020-01-10 at 11:50 -0500, Bob Vandette wrote: > Severin, > > The changes look ok to me. I assume you’ve run the container tests > on a cgroupv2 and cgroupv1 enabled system, right? Yes, I have. > You’re going to have to find a “R” reviewer. Indeed. > What’s the status of the