JEP 370 - text example leads to exception

I tried to build an example on top of this code snippet (from the JEP text): VarHandle intHandle = MemoryHandles.varHandle(int.class); VarHandle intElemHandle = MemoryHandles.withStride(intHandle, 4); try (MemorySegment segment = MemorySegment.allocateNative(100)) { MemoryAddress base = segmen

Re: [15] RFR: 8234347: "Turkey" meta time zone does not generate composed localized names, 8236548: Localized time zone name inconsistency between English and other locales

Hi Naoto, I see the existing tests were changed, e.g. the abbreviation / short timezone name, the result of calling getDisplayName. Would you need a CSR to discuss/document the potential incompatibility? Best, Joe On 2/7/20 1:44 PM, naoto.s...@oracle.com wrote: Hello, Please review the fix

Re: [15] RFR (xs) 8046362 IdentityHashMap.hash comments should be clarified

Hi Martin, On 8/02/2020 3:10 am, Martin Buchholz wrote: I explored System.identityHashCode (see below). System.identityHashCode is a VM call that is potentially very expensive. In the worst-case it triggers monitor inflation. Cheers, David They appear to be high quality, pre-mixed ints (n

[15] RFR: 8234347: "Turkey" meta time zone does not generate composed localized names, 8236548: Localized time zone name inconsistency between English and other locales

Hello, Please review the fix to the following issues: https://bugs.openjdk.java.net/browse/JDK-8234347 https://bugs.openjdk.java.net/browse/JDK-8236548 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8234347.8236548/webrev.00/ This changeset includes the following chan

Re: RFR 8214245 : (regex) Case insensitive matching doesn't work correctly for some character classes

Gentle ping. I had to rebase the fix, as the code has diverged since the RFR was sent out 10 months ago. Also, the test was slightly modified to cover more cases. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8214245 WEBREV: http://cr.openjdk.java.net/~igerasim/8214245/01/webrev/ Thanks i

Re: tools/jpackage/linux - tests (from 8212780: Packaging Tool Implementation)

Hi Matthias, On 2/7/2020 12:17 AM, Baesken, Matthias wrote: Hello, I started to look a bit into the tools/jpackage/linux - tests (from 8212780). So far I noticed the following issues , maybe someone could comment on them ? rpm/rpmbuild version requirements ---

Re: [15] RFR (xs) 8046362 IdentityHashMap.hash comments should be clarified

If a "modern" textbook recommends linear probing for memory locality, it would be nice to include a reference. I think it's OK as long as we have good mixing and occupancy doesn't get too high - 2/3 threshold seems good to me.

Re: [15] RFR (xs) 8046362 IdentityHashMap.hash comments should be clarified

I explored System.identityHashCode (see below). They appear to be high quality, pre-mixed ints (not just addresses). I suggest that IdentityHashMap simply trust System.identityHashCode. I'm surprised at any attempt to defend against high bits being zero. I'm far more worried about low bits, as wou

Re: RFR: 8238684: Override getOrDefault in immutable Map implementations

+1 Paul. > On Feb 7, 2020, at 4:17 AM, Claes Redestad wrote: > > Hi, > > in our immutable map implementations, it's unnecessary for getOrDefault > to check containsKey(key) in case get(key) returns null. This follows > since null values are disallowed. > > Overriding the method with an impleme

Re: RFR: 8238684: Override getOrDefault in immutable Map implementations

Hi Rémi, On 2020-02-07 15:21, Remi Forax wrote: Hi Claes, looks good, thanks! it can be written in a less Doug Lea-ish way like this V v = get(key); return (v != null)? v: default; I believe it using the same number of bytecodes :) with a ALOAD instead of a DUP yes, but I have no s

Re: RFR: 8223260: NamingManager should cache InitialContextFactory

I've also created JDK-8238688 to track the specification clarification request. I'll start an RFR for that shortly. Regards, Sean. On 07/02/20 14:23, Seán Coffey wrote: I've introduced such a class: FactoryInitializationError Also added a new simple testcase method check for case where this n

Re: RFR: 8223260: NamingManager should cache InitialContextFactory

I've introduced such a class: FactoryInitializationError Also added a new simple testcase method check for case where this new exception would be exercised : testBadContextCall(Hashtable) http://cr.openjdk.java.net/~coffeys/webrev.8223260.v4/webrev/

Re: RFR: 8238684: Override getOrDefault in immutable Map implementations

Hi Claes, looks good, it can be written in a less Doug Lea-ish way like this V v = get(key); return (v != null)? v: default; I believe it using the same number of bytecodes :) with a ALOAD instead of a DUP Rémi - Mail original - > De: "Claes Redestad" > À: "core-libs-dev" > Envoyé

Re: [15] RFR (xs) 8046362 IdentityHashMap.hash comments should be clarified

On 2/6/20 12:31 PM, Martin Buchholz wrote: > lgtm > > Knuth didn't like linear probing, but memory locality became far more > important over time, favoring linear probing. (Or variants, like cuckoo, but they are unlikely to be improvements here.) > > I don't get what hash() is doing with the lo

RFR: 8238684: Override getOrDefault in immutable Map implementations

Hi, in our immutable map implementations, it's unnecessary for getOrDefault to check containsKey(key) in case get(key) returns null. This follows since null values are disallowed. Overriding the method with an implementation is a reasonable optimization, for example a 50% improvement on the adde

Re: RFR: 8223260: NamingManager should cache InitialContextFactory

On 07/02/2020 10:36, Peter Levart wrote: : Well, theoretically, some implementation of InitialContextFactory could, in its constructor, use a not well-behaved dynamic Proxy which could throw UndeclaredThrowableException with NoInitialContextException as a cause and such exception would get

Re: RFR: 8223260: NamingManager should cache InitialContextFactory

On 2/7/20 12:11 AM, Seán Coffey wrote: On 6 February 2020 21:13:52 GMT, Peter Levart wrote: On 2/6/20 6:54 PM, Seán Coffey wrote: the current proposal is still: http://cr.openjdk.java.net/~coffeys/webrev.8223260.v2/webrev/ But wasn't this one already better: https://cr.openjdk.java.net/

RE: RFR: JDK-8238380: java.base/unix/native/libjava/childproc.c "multiple definition" link errors with GCC10

Thank you all. Hi Thomas, please help push this: http://cr.openjdk.java.net/~qpzhang/8238380/webrev.03, I updated the reviewer list accordingly. Thanks. Regards Patrick -Original Message- From: core-libs-dev On Behalf Of Roger Riggs Sent: Thursday, February 6, 2020 10:52 PM To: core-

tools/jpackage/linux - tests (from 8212780: Packaging Tool Implementation)

Hello, I started to look a bit into the tools/jpackage/linux - tests (from 8212780). So far I noticed the following issues , maybe someone could comment on them ? rpm/rpmbuild version requirements -- We still have some older Suse Linux 11