Re: RFR: 8247781: Day periods support [v3]

2020-10-30 Thread Naoto Sato
> Hi, > > Please review the changes for the subject issue. This is to enhance the > java.time package to support day periods, such as "in the morning", defined > in CLDR. It will add a new pattern character 'B' and its supporting builder > method. The motivation and its spec are in this CSR: >

Re: RFR: 8247781: Day periods support [v2]

2020-10-30 Thread Naoto Sato
On Fri, 30 Oct 2020 10:33:28 GMT, Stephen Colebourne wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addressed the following comments: >> - https://github.com/openjdk/jdk/pull/938#discussion_r515003422 >> -

Re: RFR: 8247781: Day periods support [v2]

2020-10-30 Thread Naoto Sato
> Hi, > > Please review the changes for the subject issue. This is to enhance the > java.time package to support day periods, such as "in the morning", defined > in CLDR. It will add a new pattern character 'B' and its supporting builder > method. The motivation and its spec are in this CSR: >

Re: RFR: 8212879: Make JVMTI TagMap table not hash on oop address

2020-10-30 Thread Erik Joelsson
On Fri, 30 Oct 2020 20:23:04 GMT, Coleen Phillimore wrote: > This change turns the HashTable that JVMTI uses for object tagging into a > regular Hotspot hashtable - the one in hashtable.hpp with resizing and > rehashing. Instead of pointing directly to oops so that GC has to walk the >

RFR: 8212879: Make JVMTI TagMap table not hash on oop address

2020-10-30 Thread Coleen Phillimore
This change turns the HashTable that JVMTI uses for object tagging into a regular Hotspot hashtable - the one in hashtable.hpp with resizing and rehashing. Instead of pointing directly to oops so that GC has to walk the table to follow oops and then to rehash the table, this table points to

JDK 7u Project Lead

2020-10-30 Thread Tim Bell
Hello Andrew Haley resigned as OpenJDK 7u project lead [1]. Andrew Brygin of Azul offered to take over leadership of OpenJDK 7u. [2] I have no other nominations. As leader of the build group [3], I can put forward Andrew Brygin as the new project leader. [4] As the only group leader

Re: RFR: 8255616: Disable AOT and Graal in Oracle OpenJDK

2020-10-30 Thread Ekaterina Pavlova
On Fri, 30 Oct 2020 17:52:09 GMT, Igor Ignatyev wrote: >> We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an >> experimental feature. We shipped Graal as an experimental JIT compiler in >> JDK 10. We haven't seen much use of these features, and the effort required >> to

Re: RFR: 8255616: Disable AOT and Graal in Oracle OpenJDK

2020-10-30 Thread Igor Ignatyev
On Fri, 30 Oct 2020 17:40:51 GMT, Vladimir Kozlov wrote: > We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an > experimental feature. We shipped Graal as an experimental JIT compiler in JDK > 10. We haven't seen much use of these features, and the effort required to >

RFR: 8255616: Disable AOT and Graal in Oracle OpenJDK

2020-10-30 Thread Vladimir Kozlov
We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an experimental feature. We shipped Graal as an experimental JIT compiler in JDK 10. We haven't seen much use of these features, and the effort required to support and enhance them is significant. We therefore intend to disable

Re: RFR: JDK-8255673: Wrong version in docs bundles

2020-10-30 Thread Tim Bell
On Fri, 30 Oct 2020 17:19:56 GMT, Erik Joelsson wrote: > In JDK-8206311, when I introduced a new docs build profile, I forgot to add > the version configure arguments to it. This causes the docs bundles for > CI/promoted builds to be generated with the default adhoc version information >

RFR: JDK-8255673: Wrong version in docs bundles

2020-10-30 Thread Erik Joelsson
In JDK-8206311, when I introduced a new docs build profile, I forgot to add the version configure arguments to it. This causes the docs bundles for CI/promoted builds to be generated with the default adhoc version information instead of the specific version for that build. -

Integrated: JDK-8255620: Build race between modulegraphs and exploded-image-optimize targets

2020-10-30 Thread Erik Joelsson
On Thu, 29 Oct 2020 22:00:52 GMT, Erik Joelsson wrote: > When I reorganized top level docs build targets in JDK-8206311, a race was > introduced. The docs-*-modulegraph targets use the BUILD_JDK to run a build > tool. For this to work, the BUILD_JDK needs to be ready for usage. In a > normal

Re: RFR: JDK-8255620: Build race between modulegraphs and exploded-image-optimize targets

2020-10-30 Thread Tim Bell
On Thu, 29 Oct 2020 22:00:52 GMT, Erik Joelsson wrote: > When I reorganized top level docs build targets in JDK-8206311, a race was > introduced. The docs-*-modulegraph targets use the BUILD_JDK to run a build > tool. For this to work, the BUILD_JDK needs to be ready for usage. In a > normal

Integrated: JDK-8255612: Explicitly disable dtrace for Oracle OpenJDK Linux builds

2020-10-30 Thread Erik Joelsson
On Thu, 29 Oct 2020 20:53:00 GMT, Erik Joelsson wrote: > The OpenJDK build on Linux will determine if the JVM feature "dtrace" should > be enabled based on the availability of dtrace on the build host. For Oracle > produced OpenJDK builds, we implicitly had this disabled because our build >

Re: RFR: 8247781: Day periods support

2020-10-30 Thread Stephen Colebourne
On Thu, 29 Oct 2020 15:59:51 GMT, Naoto Sato wrote: > Hi, > > Please review the changes for the subject issue. This is to enhance the > java.time package to support day periods, such as "in the morning", defined > in CLDR. It will add a new pattern character 'B' and its supporting builder >

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v19]

2020-10-30 Thread Maurizio Cimadamore
> This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation (see JEP 393 [1]). This iteration > focus on improving the usability of the API in 3 main ways: > > * first, by providing a way to obtain truly *shared* segments, which

Re: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v5]

2020-10-30 Thread Jan Lahoda
> This is an update to javac and javadoc, to introduce support for Preview > APIs, and generally improve javac and javadoc behavior to more closely adhere > to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only > preview

Re: Why do we export "JVM_handle_xxx_signal"?

2020-10-30 Thread Thomas Stüfe
Thanks for checking, Ioi. I think I'll remove the export and rename the functions. Cheers, Thomas On Fri, Oct 30, 2020 at 7:12 AM Ioi Lam wrote: > I have no idea, but this symbol has been exported since we moved the > HotSpot source code from SCCS to Mercurial in 2008. It's probably > vestige

Re: Why do we export "JVM_handle_xxx_signal"?

2020-10-30 Thread Ioi Lam
I have no idea, but this symbol has been exported since we moved the HotSpot source code from SCCS to Mercurial in 2008. It's probably vestige from the early days of Java. http://hg.openjdk.java.net/jdk7/modules/hotspot/annotate/9646293b9637/make/linux/makefiles/mapfile-vers-product#l244 I