Re: RFR JDK-8225339 Optimize HashMap.keySet()/HashMap.values()/HashSet toArray() methods

Hello! Thanks, pushed: http://hg.openjdk.java.net/jdk/jdk/rev/1afe0cb93482 On Fri, Jun 14, 2019 at 11:28 AM Stuart Marks wrote: > Hi Tagir, > > I reviewed your latest changeset and it looks fine. > > I ran the changes through our internal test system and the results look > good. > > Since the C

Re: RFR JDK-8225339 Optimize HashMap.keySet()/HashMap.values()/HashSet toArray() methods

Hi Tagir, I reviewed your latest changeset and it looks fine. I ran the changes through our internal test system and the results look good. Since the CSR was approved for JDK 14, and the mainline is now JDK 14 (after the JDK 13 RDP1 fork), you can now push this changeset. Thanks, s'marks O

Re: Kind reminder about JDK-8193031

Hello! If ArrayList is the collection which could mostly benefit from this, why not peel off this case and provide special path for ArrayList only? E.g. like this: --- src/java.base/share/classes/java/util/ArrayList.java (revision 55248:10a2778ecbbfb1a9fc33c8cfade7e2479617b096) +++ src/java.base/

Re: Kind reminder about JDK-8193031

Hi Sergey, There are some links to a few other discussion threads in the bug report [1]. I've added a link to this one. :-) It's too late for JDK 13, which entered RDP1 today. However, the JDK 14 source base is open, and we can proceed there. In one of the previous discussions, I had sugges

Re: Suggestion for a more sensible implementation of EMPTY_MAP

On 6/10/19 7:34 AM, Abraham Marín Pérez wrote: I agree that it makes sense for EMPTY_MAP to have the same logic as Map.of() or unmodifiable(new HashMap()), which means that my suggestion cannot be applied to just EMPTY_MAP... but maybe that’s ok: maybe we can change all of them? If we keep

Re: RFR: JDK-8225569: jpackage app-image layout

Hi Andy, 1) I think it is better to move mksure() to common place like IOUtils, otherwise it is duplicated in WindowsAppImageBuilder.java and LinuxAppImageBuilder.java. 2) For Alexey comment I think it is good idea to use Paths.get(), but I think it should be done as separate cleanup bug.

Re: RFR: JDK-8225569: jpackage app-image layout

Please note that it is recommended to use Path.of() [1] which was added in JDK 11 as indicated in the class doc of Paths: API Note: It is recommended to obtain a Path via the Path.of methods instead of via the get methods defined in this class as this class may be deprecated in a future release

Re: RFR: JDK-8225569: jpackage app-image layout

Andy, I was just curios why we don't use Paths. If we should then I'll use this API in my patches. I didn't mean to ask you do the clean up in all the sources :) - Alexey On 6/13/2019 3:34 PM, Andy Herrick wrote: On 6/13/19, 2:00 PM, Alexey Semenyuk wrote: Looks good. Q: any good reason

Re: RFR: JDK-8225569: jpackage app-image layout

On 6/13/19, 2:00 PM, Alexey Semenyuk wrote: Looks good. Q: any good reason we are not using Paths.get(a, b, c) instead of a + File.separator + b + File.separator + c to build paths? There are a lot of places we should be using Paths instead of String and File objects, but JPackagePath (test

Re: RFR: JDK-8225569: jpackage app-image layout

Looks good. Q: any good reason we are not using Paths.get(a, b, c) instead of a + File.separator + b + File.separator + c to build paths? - Alexey On 6/13/2019 1:21 PM, Andy Herrick wrote: Sorry - subject was missing, this is for: JDK-8225569: jpackage app-image layout /Andy On 6/13/2019

RFR: JDK-8225569: jpackage app-image layout

Sorry - subject was missing, this is for: JDK-8225569: jpackage app-image layout /Andy On 6/13/2019 12:59 PM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] https://bug

RFR:

Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] https://bugs.openjdk.java.net/browse/JDK-8225569 [2] http://cr.openjdk.java.net/~herrick/8225569/webrev.01/

Re: jpackage DMG creation trouble

DMG isn’t an installer type. The common thing would be for the Application Bundle to be wrapped in a DMG for distribution, or if a Package is needed, that would be wrapped in the DMG instead. Creating the DMG wrapper is independent of the kind of “installer” . On Mac this means no installer -

Re: [RFR] 8223727: com/sun/jndi/ldap/privconn/RunTest.java failed due to hang in LdapRequest.getReplyBer

Hi Rob, As per our offline conversation, there's indeed a race condition between the cleanup actions performed by LDAP connection (com.sun.jndi.ldap.Connection.cleanup) and reading from LdapRequest (com.sun.jndi.ldap.LdapRequest.getReplyBer). There are 3 activities of interest to us. Adding a re

Kind reminder about JDK-8193031

Hello, the issue [1] was opened almost two years ago, but even today Collections.addAll still looks like this: public static boolean addAll(Collection c, T... elements) { boolean result = false; for (T element : elements) result |= c.add(element); return result; } The most w

Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp

Hi Ioi, Thank you for your review. You've taught me another way to fix this issue. Reference.reachabilityFence seems to be widely used to handle this situation. For example, you can just grep it in the test dir like this: ~/jdk-dev/test$ gre

Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp

Thanks Alan for your review. And could you please sponsor it? Thanks a lot. Best regards, Jie On 2019/6/13 下午3:40, Alan Bateman wrote: On 12/06/2019 09:37, Jie Fu wrote: Hi all, JBS:    https://bugs.openjdk.java.net/browse/JDK-8225648 Webrev: http://cr.openjdk.java.net/~jiefu/8225648/webrev.0

Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp

Hi Jie, Instead of using an obscure call Reference.reachabilityFence(loader), how about just making "loader" a static field in the test class, so it will be kept alive until it's explicitly set to null? Thanks - Ioi On 6/12/19 1:37 AM, Jie Fu wrote: Hi all, JBS:    https://bugs.openjdk.jav

Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp

On 12/06/2019 09:37, Jie Fu wrote: Hi all, JBS:    https://bugs.openjdk.java.net/browse/JDK-8225648 Webrev: http://cr.openjdk.java.net/~jiefu/8225648/webrev.00/ The failure was caused by the lost of an OopMap item for the object "loader"[1] which was optimized out by JIT with liveness analysis