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

On 1/8/20 10:12 AM, Aleksey Shipilev wrote: > On 1/8/20 9:45 AM, Aleksey Shipilev wrote: >> On 1/7/20 7:50 AM, Aleksey Shipilev wrote: >>> On 1/6/20 1:48 PM, Alex Kashchenko wrote: [...] Bug: https://bugs.openjdk.java.net/browse/JDK-8236125 >>> Webrev: http://cr.openjdk.java.net/~akasko/j

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

On 10/01/2020 09:11, Aleksey Shipilev wrote: : No other takers? I would then push this trivial patch for Alex under my single review. I think it's okay but would be nice if one of the jpackager maintainers jumped in. I also think it would be useful to get an inventory of the Visual Studio v

Re: JDK 14 RFR of JDK-8236877: Add "record" to descriptions in java.lang.{annotation, reflect}

On 09/01/2020 19:22, Joe Darcy wrote: Hello, As noted by Werner [1], one of the discussions of the kinds of types in java.lang.annotation was not updated for records. I checked java.lang.annotation, java.lang.reflect, and java.lang.Class and found another location to update:     JDK-8236

Re: RFR 8222098: tools/jlink/plugins/IncludeLocalesPluginTest.java time out

Adding core-libs-dev. -Sundar On 10/01/20 11:33 am, sundararajan.athijegannat...@oracle.com wrote: Please review. Not really a fix - but increasing the default timeout for the test. Bug: https://bugs.openjdk.java.net/browse/JDK-8222098 Webrev: http://cr.openjdk.java.net/~sundar/8222098/webre

RFR: CSR JDK-8233385 Align some one-way conversion in MS950 charset with Windows

Hello. Could you review CSR JDK-8233385 [1] ? [1] https://bugs.openjdk.java.net/browse/JDK-8233385 Thanks, Ichiroh Takiguchi IBM Japan, Ltd.

Re: RFR 8222098: tools/jlink/plugins/IncludeLocalesPluginTest.java time out

+1 > On Jan 10, 2020, at 2:03 AM, sundararajan.athijegannat...@oracle.com wrote: > > Please review. > > Not really a fix - but increasing the default timeout for the test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222098 > > Webrev: http://cr.openjdk.java.net/~sundar/8222098/webrev.00

Re: RFR 8222098: tools/jlink/plugins/IncludeLocalesPluginTest.java time out

Hi Sundar, You might want to add the bug id in the regression test, and change the copyright year to 2020. Otherwise, looks good. Naoto On 1/10/20 5:07 AM, sundararajan.athijegannat...@oracle.com wrote: Adding core-libs-dev. -Sundar On 10/01/20 11:33 am, sundararajan.athijegannat...@oracl

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

Severin, The changes look ok to me. I assume you’ve run the container tests on a cgroupv2 and cgroupv1 enabled system, right? You’re going to have to find a “R” reviewer. What’s the status of the hotspot cgroupv2 changes. Have these been reviewed? Bob. > On Jan 9, 2020, at 2:51 PM, Severin

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

Hi, this patch ensures operations on constant (static final) single-element lists and sets created via List.of(foo) and Set.of(bar) to constant fold properly. Bug:https://bugs.openjdk.java.net/browse/JDK-8236850 Webrev: http://cr.openjdk.java.net/~redestad/8236850/open.00 On micros that are

RFR: 8236939: [TESTBUG] Incorrect initialization in java/foreign/TestArrays.java

Hi Could you please review following trivial fix which corrects type of used SequenceLayout in the java/foreign/TestArrays.java test. Really both long and double layouts are actually "MemoryLayout.ofValueBits(64L, ByteOrder.nativeOrder());" so this issue didn't cause test failure. I am going

Re: RFR: 8236939: [TESTBUG] Incorrect initialization in java/foreign/TestArrays.java

On 1/10/20 7:06 PM, Leonid Mesnik wrote: > I am going to push it in jdk/jdk only and not in jdk14. I suspect there would be some work around x86_32 before RDP2 hits, so maybe this can go into jdk/jdk14 as well? This would minimize the jdk/jdk14 -> jdk/jdk merge chore next week. > --- a/test/jdk

Re: RFR: 8236939: [TESTBUG] Incorrect initialization in java/foreign/TestArrays.java

On 1/10/20 10:16 AM, Aleksey Shipilev wrote: On 1/10/20 7:06 PM, Leonid Mesnik wrote: I am going to push it in jdk/jdk only and not in jdk14. I suspect there would be some work around x86_32 before RDP2 hits, so maybe this can go into jdk/jdk14 as well? This would minimize the jdk/jdk14 -> j

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

Hi Claes, Looks fine. ImmutableCollections.java: 418  looks like an extra blank line Thanks, Roger On 1/10/20 12:01 PM, Claes Redestad wrote: Hi, this patch ensures operations on constant (static final) single-element lists and sets created via List.of(foo) and Set.of(bar) to constant fold

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

Seem to be a JIT bug to me, the fields of Set12 are declared final not @Stable (even if the field storing the instanceof of Set&2 itself is marked @Stable) so there is no reason not not let the constant folding happen. Rémi - Mail original - > De: "Claes Redestad" > À: "core-libs-dev"

Re: [NEW BUG] Fix duplicated word in Lookup#in documentation

Pushed. See https://bugs.openjdk.java.net/browse/JDK-8236945 Mandy On 1/7/20 9:32 AM, Christoph Dreis wrote: Hi, I just noticed that a duplicated "the" slipped into the docs of Lookup.in(). The change seems to have been introduced in https://bugs.openjdk.java.net/browse/JDK-8226916. In cas

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

Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8174270 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8174270/webrev.00/ Although the number of modified files are huge, the change is simply moving the scattered ICU sources

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

in Norm2AllModes.java and UBiDiProps.java and UCharacterProperty.java the stub name (icudt64b) should be calculated from the version number. At least put “icudt64b” in one place and refer to it. OR keep the data file names unversioned, such as src/java.base/share/classes/jdk/internal/icu/impl

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

Is there a reason why uidna.spp was left out of the move? -Joe On 1/10/20 2:02 PM, naoto.s...@oracle.com wrote: Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8174270 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8174270

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

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 2:57 PM, Joe Wang wrote: Is there a reason why uidna.spp was left out of the move? -Joe On 1/10/20 2:02 PM, naoto.s...@oracle.com wrote: Hi, Please review the fix

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

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) should be calculated from the version number.  At least put “icudt64b” in one place and refer to it. Good point. Modified as suggested: http

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

On Jan 10, 2020, at 10:47 AM, Remi Forax wrote: > Seem to be a JIT bug to me, > the fields of Set12 are declared final not @Stable (even if the field storing > the instanceof of Set&2 itself is marked @Stable) so there is no reason not > not let the constant folding happen. It’s part of the co

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

Hi, On 2020-01-11 02:23, John Rose wrote: On Jan 10, 2020, at 10:47 AM, Remi Forax > wrote: Seem to be a JIT bug to me, the fields of Set12 are declared final not @Stable (even if the field storing the instanceof of Set&2 itself is marked @Stable) so there is no rea

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

On Jan 10, 2020, at 6:48 PM, Claes Redestad wrote: > > Yes. The XOR seems pointless with this approach, but some shifting > might be good. A single multiply mixes the bits of its inputs. If one input is “random” or “white” (50% 1’s irregularly spaced) then the output will probably look similar.

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

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 2:57 PM, Joe Wang wrote: Is there a reason why uidna.spp was left out of