Re: RFR: 8259886 : Improve SSL session cache performance and scalability [v2]

2021-02-09 Thread djelinski
On Thu, 4 Feb 2021 20:45:55 GMT, djelinski wrote: >> Thank you for the comment. The big picture is more clear to me now. >> >>> Example 2: >>> Old implementation will get: >>> |K=3, exp=10|K=5, exp=12|K=7, exp=14|K=9, exp=16| >>> >>> New implementation will get: >>> |K=5, exp=12|K=7,

Integrated: JDK-8259656: fixpath.sh changes broke _NT_SYMBOL_PATH in RunTests.gmk

2021-02-09 Thread Erik Joelsson
On Mon, 8 Feb 2021 18:05:20 GMT, Erik Joelsson wrote: > Adding FIXPATH_BASE in RunTestsPrebuilt.gmk as that's needed for the FixPath > make macro to work. This pull request has now been integrated. Changeset: 05c6009e Author:Erik Joelsson URL:

Re: [Draft] RFR: 8241463: Move build tools to respective modules

2021-02-09 Thread Alan Bateman
On 09/02/2021 11:18, Magnus Ihse Bursie wrote: This is a re-post of a change that was posted as webrev prior to the Github migration. It is not ready for integration as-is, since it needs to be rebased to the current HEAD, and that is bound to be a non-trivial operation after this much time.

Re: RFR: JDK-8259656: fixpath.sh changes broke _NT_SYMBOL_PATH in RunTests.gmk

2021-02-09 Thread Magnus Ihse Bursie
On Mon, 8 Feb 2021 18:05:20 GMT, Erik Joelsson wrote: > Adding FIXPATH_BASE in RunTestsPrebuilt.gmk as that's needed for the FixPath > make macro to work. Looks good. Thanks for fixing this! - Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2460

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v4]

2021-02-09 Thread Ajit Ghaisas
> **Description :** > This is the implementation of [JEP 382 : New macOS Rendering > Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) > It implements a Java 2D internal rendering pipeline for macOS using the Apple > Metal API. > The entire work on this was done under [OpenJDK Project

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]

2021-02-09 Thread Stefan Karlsson
On Fri, 5 Feb 2021 16:07:09 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the

[Draft] RFR: 8241463: Move build tools to respective modules

2021-02-09 Thread Magnus Ihse Bursie
This is a re-post of a change that was posted as webrev prior to the Github migration. It is not ready for integration as-is, since it needs to be rebased to the current HEAD, and that is bound to be a non-trivial operation after this much time. However, I think it is relevant to have this

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]

2021-02-09 Thread Ajit Ghaisas
On Mon, 8 Feb 2021 16:53:16 GMT, Gerard Ziemski wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Lanai PR#175 - 8261304 - aghaisas > > src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 113: > >>

Re: RFR: 8259886 : Improve SSL session cache performance and scalability [v2]

2021-02-09 Thread Xue-Lei Andrew Fan
On Thu, 4 Feb 2021 20:45:55 GMT, djelinski wrote: > Thanks for your review! Some comments below. > > > A full handshake or OCSP status grabbing could counteract all the > > performance gain with the cache update. > > Yes, but that's unlikely. Note that K=3 is before K=1 in the queue only >

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]

2021-02-09 Thread Jayathirth D V
On Mon, 8 Feb 2021 18:05:02 GMT, Gerard Ziemski wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Lanai PR#175 - 8261304 - aghaisas > > src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderQueue.java line 97: >

Re: RFR: 8259886 : Improve SSL session cache performance and scalability [v2]

2021-02-09 Thread Xue-Lei Andrew Fan
On Tue, 9 Feb 2021 08:44:28 GMT, djelinski wrote: > So, how do we want to proceed here? Is the proposed solution acceptable? If > not, what needs to change? if yes, what do I need to do next? For me, it is a pretty good solution, but I have some concerns. I appreciate if you would like to