From weijun.wang at oracle.com Fri Dec 1 00:31:09 2023 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Fri, 1 Dec 2023 00:31:09 +0000 Subject: CFV: New JDK Committer: Eirik Bjorsnos In-Reply-To: <9e75c0cc-5640-4758-8d73-dc9c84283091@gmail.com> References: <9e75c0cc-5640-4758-8d73-dc9c84283091@gmail.com> Message-ID: Vote: yes --Weijun > On Nov 30, 2023, at 1:05?AM, Jaikiran Pai wrote: > > I hereby nominate Eirik Bjorsnos to JDK Committer. > > GitHub userid: eirbjo (https://github.com/eirbjo) > OpenJDK census: https://openjdk.org/census#eirbjo > > Over the years, Eirik has been regularly contributing to the JDK. He currently has 31 commits in the JDK project[1], mainly in the jar/zip API area but not limited to it. Some of his contributions have also helped improve the quality of tests that we have for the zip/jar APIs. > > From Eirik: > "Java programmer for 20 years, mostly in the Norwegian financial and public sectors. Individual OpenJDK Contributor since April 2020 (Author role since March 2023) Main focus has been performance, improved test coverage and removal of deprecated APIs in the ZIP and JAR areas" > > > Votes are due by 6:30 UTC Monday 14th December 2023. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3] > > > [1] https://github.com/openjdk/jdk/commits?author=eirbjo > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote > > -Jaikiran > From tstuefe at redhat.com Fri Dec 1 17:31:53 2023 From: tstuefe at redhat.com (Thomas Stuefe) Date: Fri, 1 Dec 2023 18:31:53 +0100 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition Message-ID: Hi, community, I experimented with extending Native Memory Tracking across the whole process. I want to share my findings and propose a new JDK feature to allow us to do that. TL;DR Proposed is a "native memory interposition library" shipped with the JDK that would intercept all native memory calls from everywhere and redirect them to NMT. Motivation: NMT is very useful but limited in its coverage. It only covers Hotspot and a select few sites from the JDK. Most of the JDK, third-party native code, and system libraries are not covered. This is a large hole in our observability. I have seen people do (and done myself! eg [1]) strange and weird things to hunt memory leaks in native code. This is especially tricky in locked-down customer scenarios. But NMT is a capable tracker. We could use it for much more than just tracking Hotspot. In the past, developers have attempted to extend NMT instrumentation over parts of the JDK (e.g. [2]), which met resistance from Oracle. This is understandable: a naive extension would require libraries to link against the libjvm and instrument their coding. That introduces new dependencies nobody wants. --- I propose a different way that works without instrumenting any caller code. I hope this proposal proves less controversial than brute-force NMT instrumentation of the JDK. And it would allow introspection of non-JDK parts too. We could ship an interception library (a "libjnmt.so") within the JDK. That library, if preloaded, would redirect native memory requests to NMT. A customer who wants to analyze the native memory footprint of its apps could start the JVM with LD_PRELOAD=libjnmt and then use NMT for introspection. Oracle and we continuously improve NMT; extending its reach across the whole process would leverage that investment nicely. It also meshes well with other improvements. For example, we report NMT numbers via JFR since [4] - with interposition, we could now expose third-party native allocations via JFR. The new jcmd "System.map" would automatically show memory mappings from outside Hotspot. There is a precedent (libjsig), so shipping interposition libraries is not that strange. --- I have a Linux-based POC that works and looks promising [3]. With that prototype, I can see: - allocations from the JDK - e.g., now I finally see mapped byte buffers. - allocations from third-party user code - most allocations from system libraries, e.g., from the system zlib - allocations via the new FFI interface The prototype tracks both mmap and malloc. Technically, the tricky part was to handle the initialization window: being able to correctly handle allocations starting at the process C++ initialization while dynamically handing over allocations to the libjvm once it is loaded and NMT is initialized. Another tricky problem was to prevent circularities stemming from call intercepting. The prototype solves these problems and is already stable enough to be used. Note that the patch is not complex or large. Some small interaction with the JVM is needed, though, so this cannot be done just with an outside library. The prototype was developed and tested on Linux x64 and with glibc 2.31. It seems stable so far, but of course, the work is in an early stage, and bugs may exist. If you want to play with the prototype, build it [3] and then call: LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so ${JDK_DIR}/bin/java -XX:NativeMemoryTracking=detail Example: quarkus with "third-party code" injected that leaks periodically [5]: LEAK_MALLOC=1 LEAK_MMAP=1 LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so ${JDK_DIR}/bin/java -agentpath:/shared/projects/jvmti-leak/leaker.so -XX:NativeMemoryTracking=detail -jar ./quarkus-profiling-workshop/ target/quarkus-app/quarkus-run.jar In Summary mode, we see the slowly growing leaks: -External (via interposition) (reserved=82216KB, committed=82216KB) (malloc=81588KB #585) (at peak) (mmap: reserved=628KB, committed=628KB, at peak) and in Detail mode, their call stacks: [0x00007ff067ee7000 - 0x00007ff067ee8000] reserved and committed 4KB for External (via interposition) from [0x00007ff067ef5056]the_mmap(void*, unsigned long, int, int, int, long)+0x66 in libjnmt.so [0x00007ff067ef5781]mmap+0x71 in libjnmt.so [0x00007ff067ee955a]leak_mmap+0x3f in leaker.so [0x00007ff067ee95b1]leakleak+0x1c in leaker.so [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so [0x00007ff067ee95db]leakabit+0x12 in leaker.so [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so [0x00007ff067ef5166]the_malloc(unsigned long)+0x106 in libjnmt.so [0x00007ff067ee94ae]do_malloc+0xb8 in leaker.so [0x00007ff067ee9518]leak_malloc+0x20 in leaker.so [0x00007ff067ee95a7]leakleak+0x12 in leaker.so [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so [0x00007ff067ee95db]leakabit+0x12 in leaker.so [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so (malloc=17679KB type=External (via interposition) #34) (at peak) --- What about MEMFLAGS? The prototype does not extend MEMFLAGS apart from introducing a new "External" category that tracks allocations done via interposition. The question of MEMFLAGS - in particular, opening it up to outside extension - has been contentious. It is orthogonal to this proposal - nice but not required. This proposal makes external allocations visible under the new "External" tag: - in NMT summary mode, we only have the "External" total, which is already useful even as a lump sum: it shows the footprint non-hotspot libraries contribute to RSS. An RSS increase that is reflected neither by hotspot allocations nor by "External" can only stem from a select few places, e.g. from libc malloc retention. - In NMT detail mode, this proposal shows us the call stacks to foreign call sites, pinpointing at least the libraries involved. -- What do you think, does this make sense? Thanks, Thomas [1] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer [2] https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html [3] https://github.com/tstuefe/jdk/tree/libjnmt [4] https://bugs.openjdk.org/browse/JDK-8157023 [5] https://github.com/tstuefe/jvmti_leak -------------- next part -------------- An HTML attachment was scrubbed... URL: From huizhe.wang at oracle.com Fri Dec 1 17:38:33 2023 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 1 Dec 2023 09:38:33 -0800 Subject: CFV: New JDK Committer: Eirik Bjorsnos In-Reply-To: <9e75c0cc-5640-4758-8d73-dc9c84283091@gmail.com> References: <9e75c0cc-5640-4758-8d73-dc9c84283091@gmail.com> Message-ID: Vote: yes Joe (joehw) On 11/29/23 10:05 PM, Jaikiran Pai wrote: > I hereby nominate Eirik Bjorsnos to JDK Committer. From mark.reinhold at oracle.com Fri Dec 1 21:08:02 2023 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Fri, 1 Dec 2023 21:08:02 +0000 Subject: JEP proposed to target JDK 22: 462: Structured Concurrency (Second Preview) In-Reply-To: <20231122172750.B4F8B64F0E5@eggemoggin.niobe.net> References: <20231122172750.B4F8B64F0E5@eggemoggin.niobe.net> Message-ID: <20231201160800.583584156@eggemoggin.niobe.net> 2023/11/22 12:27:51 -0500, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 22: > > 462: Structured Concurrency (Second Preview) > https://openjdk.org/jeps/462 > > Summary: Simplify concurrent programming by introducing an API for > structured concurrency. Structured concurrency treats groups of > related tasks running in different threads as a single unit of work, > thereby streamlining error handling and cancellation, improving > reliability, and enhancing observability. This is a preview API. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 20:00 UTC on Friday, 1 December, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target this JEP to JDK 22. Hearing no objections, I?ve targeted this JEP to JDK 22. - Mark From mark.reinhold at oracle.com Fri Dec 1 21:08:04 2023 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Fri, 1 Dec 2023 21:08:04 +0000 Subject: JEP proposed to target JDK 22: 458: Launch Multi-File Source-Code Programs In-Reply-To: <20231122183427.1F1AF64F10A@eggemoggin.niobe.net> References: <20231122183427.1F1AF64F10A@eggemoggin.niobe.net> Message-ID: <20231201160803.170315819@eggemoggin.niobe.net> 2023/11/22 13:38:26 -0500, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 22: > > 458: Launch Multi-File Source-Code Programs > https://openjdk.org/jeps/458 > > Summary: Enhance the java application launcher to be able to run a > program supplied as multiple files of Java source code. This will > make the transition from small programs to larger ones more gradual, > enabling developers to choose whether and when to go to the trouble of > configuring a build tool. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 20:00 UTC on Friday, 1 December, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target this JEP to JDK 22. Hearing no objections, I?ve targeted this JEP to JDK 22. - Mark From christoph.langer at sap.com Sat Dec 2 20:34:38 2023 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 2 Dec 2023 20:34:38 +0000 Subject: CFV: New JDK Committer: Eirik Bjorsnos In-Reply-To: <9e75c0cc-5640-4758-8d73-dc9c84283091@gmail.com> References: <9e75c0cc-5640-4758-8d73-dc9c84283091@gmail.com> Message-ID: Vote: yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Jaikiran Pai > Sent: Donnerstag, 30. November 2023 07:05 > To: jdk-dev at openjdk.org > Subject: CFV: New JDK Committer: Eirik Bjorsnos > > I hereby nominate Eirik Bjorsnos to JDK Committer. > > GitHub userid: eirbjo (https://github.com/eirbjo) OpenJDK census: > https://openjdk.org/census#eirbjo > > Over the years, Eirik has been regularly contributing to the JDK. He currently > has 31 commits in the JDK project[1], mainly in the jar/zip API area but not > limited to it. Some of his contributions have also helped improve the quality of > tests that we have for the zip/jar APIs. > > From Eirik: > ?? ?"Java programmer for 20 years, mostly in the Norwegian financial and public > sectors. Individual OpenJDK Contributor since April 2020 (Author role since > March 2023) Main focus has been performance, improved test coverage and > removal of deprecated APIs in the ZIP and JAR areas" > > > Votes are due by 6:30 UTC Monday 14th December 2023. > > Only current JDK Committers [2] are eligible to vote on this nomination.? Votes > must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3] > > > [1] https://github.com/openjdk/jdk/commits?author=eirbjo > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote > > -Jaikiran From johan.sjolen at oracle.com Mon Dec 4 10:49:12 2023 From: johan.sjolen at oracle.com (=?UTF-8?B?Sm9oYW4gU2rDtmzDqW4=?=) Date: Mon, 4 Dec 2023 11:49:12 +0100 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: References: Message-ID: <521ae235-c03a-4b16-ae11-2bf298120d8a@oracle.com> Hi Thomas, If a user would like to switch out the malloc which a JVM is using, would they be able to do that while simultaneously using your interception library? Thank you, Johan > Hi, community, > > I experimented with extending Native Memory Tracking across the whole > process. I want to share my findings and propose a new JDK feature to > allow us to do that. > > TL;DR > > Proposed is a "native memory interposition library" shipped with the > JDK that would intercept all native memory calls from everywhere and > redirect them to NMT. > > Motivation: > > NMT is very useful but limited in its coverage. It only covers Hotspot > and a select few sites from the JDK. Most of the JDK, third-party > native code, and system libraries are not covered. This is a large > hole in our observability. I have seen people do (and done myself! eg > [1]) strange and weird things to hunt memory leaks in native code. > This is especially tricky in locked-down customer scenarios. > > But NMT is a capable tracker. We could use it for much more than just > tracking Hotspot. > > In the past, developers have attempted to extend NMT instrumentation > over parts of the JDK (e.g. [2]), which met resistance from Oracle. > This is understandable: a naive extension would require libraries to > link against the libjvm and instrument their coding. That introduces > new dependencies nobody wants. > > --- > > I propose a different way that works without instrumenting any caller > code. I hope this proposal proves less controversial than brute-force > NMT instrumentation of the JDK. And it would allow introspection of > non-JDK parts too. > > We could ship an interception library (a "libjnmt.so") within the JDK. > That library, if preloaded, would redirect native memory requests to > NMT. A customer who wants to analyze the native memory footprint of > its apps could start the JVM with LD_PRELOAD=libjnmt and then use NMT > for introspection. > > Oracle and we continuously improve NMT; extending its reach across the > whole process would leverage that investment nicely. > > It also meshes well with other improvements. For example, we report > NMT numbers via JFR since [4] - with interposition, we could now > expose third-party native allocations via JFR. The new jcmd > "System.map" would automatically show memory mappings from outside > Hotspot. There is a precedent (libjsig), so shipping interposition > libraries is not that strange. > > --- > > I have a Linux-based POC that works and looks promising [3]. With that > prototype, I can see: > > - allocations from the JDK - e.g., now I finally see mapped byte buffers. > - allocations from third-party user code > - most allocations from system libraries, e.g., from the system zlib > - allocations via the new FFI interface > > The prototype tracks both mmap and malloc. Technically, the tricky > part was to handle the initialization window: being able to correctly > handle allocations starting at the process C++ initialization while > dynamically handing over allocations to the libjvm once it is loaded > and NMT is initialized. Another tricky problem was to prevent > circularities stemming from call intercepting. The prototype solves > these problems and is already stable enough to be used. > > Note that the patch is not complex or large. Some small interaction > with the JVM is needed, though, so this cannot be done just with an > outside library. > > The prototype was developed and tested on Linux x64 and with glibc > 2.31. It seems stable so far, but of course, the work is in an early > stage, and bugs may exist. If you want to play with the prototype, > build it [3] and then call: > > LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so ${JDK_DIR}/bin/java > -XX:NativeMemoryTracking=detail > > Example: quarkus with "third-party code" injected that leaks > periodically [5]: > > LEAK_MALLOC=1 LEAK_MMAP=1 LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so > ${JDK_DIR}/bin/java -agentpath:/shared/projects/jvmti-leak/leaker.so > -XX:NativeMemoryTracking=detail -jar > ./quarkus-profiling-workshop/target/quarkus-app/quarkus-run.jar > > In Summary mode, we see the slowly growing leaks: > > -External (via interposition) (reserved=82216KB, committed=82216KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (malloc=81588KB #585) (at peak) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (mmap: reserved=628KB, committed=628KB, at > peak) > > > and in Detail mode, their call stacks: > > [0x00007ff067ee7000 - 0x00007ff067ee8000] reserved and committed 4KB > for External (via interposition) from > [0x00007ff067ef5056]the_mmap(void*, unsigned long, int, int, int, > long)+0x66 in libjnmt.so > [0x00007ff067ef5781]mmap+0x71 in libjnmt.so > ? ? [0x00007ff067ee955a]leak_mmap+0x3f in leaker.so > ? ? [0x00007ff067ee95b1]leakleak+0x1c in leaker.so > ? ? [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so > ? ? [0x00007ff067ee95db]leakabit+0x12 in leaker.so > ? ? [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so > > > [0x00007ff067ef5166]the_malloc(unsigned long)+0x106 in libjnmt.so > [0x00007ff067ee94ae]do_malloc+0xb8 in leaker.so > [0x00007ff067ee9518]leak_malloc+0x20 in leaker.so > [0x00007ff067ee95a7]leakleak+0x12 in leaker.so > [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so > [0x00007ff067ee95db]leakabit+0x12 in leaker.so > [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(malloc=17679KB type=External (via > interposition) #34) (at peak) > > --- > > What about MEMFLAGS? > > The prototype does not extend MEMFLAGS apart from introducing a new > "External" category that tracks allocations done via interposition. > The question of MEMFLAGS - in particular, opening it up to outside > extension - has been contentious. It is orthogonal to this proposal - > nice but not required. > > This proposal makes external allocations visible under the new > "External" tag: > - in NMT summary mode, we only have the "External" total, which is > already useful even as a lump sum: it shows the footprint non-hotspot > libraries contribute to RSS. An RSS increase that is reflected neither > by hotspot allocations nor by "External" can only stem from a select > few places, e.g. from libc malloc retention. > - In NMT detail mode, this proposal shows us the call stacks to > foreign call sites, pinpointing at least the libraries involved. > > -- > > What do you think, does this make sense? > > Thanks, Thomas > > > [1] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer > [2] > https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html > [3] https://github.com/tstuefe/jdk/tree/libjnmt > [4] https://bugs.openjdk.org/browse/JDK-8157023 > [5] https://github.com/tstuefe/jvmti_leak -------------- next part -------------- An HTML attachment was scrubbed... URL: From brice.dutheil at gmail.com Mon Dec 4 23:48:50 2023 From: brice.dutheil at gmail.com (Brice Dutheil) Date: Tue, 5 Dec 2023 00:48:50 +0100 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: <521ae235-c03a-4b16-ae11-2bf298120d8a@oracle.com> References: <521ae235-c03a-4b16-ae11-2bf298120d8a@oracle.com> Message-ID: Hi Joha, Thomas will correct me as he is proposed the idea and much more experienced, also I'm a mere reader of this ML. So, I have not toyed with the code, but I believe this should work, at least on linux if linker has no restrictions. Typically interception happens because there is a function with the right signature preloaded (via `LD_PRELOAD`) that linker will look up. The magic can work because in order to do real work and invoke the right methods down the line using `dlsym(RTLD_NEXT, name)`. And that should be the next library on the path or the system as the linker should process from left to right this `LD_PRELOAD`. ``` void *malloc(size_t size) { void *(*p_malloc)(size_t) = dlsym(RTLD_NEXT, "malloc"); // report back mem operation return p_malloc(size); } ``` https://man7.org/linux/man-pages/man8/ld.so.8.html https://www.man7.org/linux/man-pages/man3/dlsym.3.html That said this might be tricky to avoid loops, if one function calls `malloc`. Also I suppose this could work on macos via `DYLD_PRELOAD` but unsure since macos has some restrictions. -- Brice On Mon, Dec 4, 2023 at 13:14 Johan Sj?l?n wrote: > Hi Thomas, > > If a user would like to switch out the malloc which a JVM is using, would > they be able to do that while simultaneously using your interception > library? > > Thank you, > Johan > > Hi, community, > > I experimented with extending Native Memory Tracking across the whole > process. I want to share my findings and propose a new JDK feature to allow > us to do that. > > TL;DR > > Proposed is a "native memory interposition library" shipped with the JDK > that would intercept all native memory calls from everywhere and redirect > them to NMT. > > Motivation: > > NMT is very useful but limited in its coverage. It only covers Hotspot and > a select few sites from the JDK. Most of the JDK, third-party native code, > and system libraries are not covered. This is a large hole in our > observability. I have seen people do (and done myself! eg [1]) strange and > weird things to hunt memory leaks in native code. This is especially tricky > in locked-down customer scenarios. > > But NMT is a capable tracker. We could use it for much more than just > tracking Hotspot. > > In the past, developers have attempted to extend NMT instrumentation over > parts of the JDK (e.g. [2]), which met resistance from Oracle. This is > understandable: a naive extension would require libraries to link against > the libjvm and instrument their coding. That introduces new dependencies > nobody wants. > > --- > > I propose a different way that works without instrumenting any caller > code. I hope this proposal proves less controversial than brute-force NMT > instrumentation of the JDK. And it would allow introspection of non-JDK > parts too. > > We could ship an interception library (a "libjnmt.so") within the JDK. > That library, if preloaded, would redirect native memory requests to NMT. A > customer who wants to analyze the native memory footprint of its apps could > start the JVM with LD_PRELOAD=libjnmt and then use NMT for introspection. > > Oracle and we continuously improve NMT; extending its reach across the > whole process would leverage that investment nicely. > > It also meshes well with other improvements. For example, we report NMT > numbers via JFR since [4] - with interposition, we could now expose > third-party native allocations via JFR. The new jcmd "System.map" would > automatically show memory mappings from outside Hotspot. There is a > precedent (libjsig), so shipping interposition libraries is not that > strange. > > --- > > I have a Linux-based POC that works and looks promising [3]. With that > prototype, I can see: > > - allocations from the JDK - e.g., now I finally see mapped byte buffers. > - allocations from third-party user code > - most allocations from system libraries, e.g., from the system zlib > - allocations via the new FFI interface > > The prototype tracks both mmap and malloc. Technically, the tricky part > was to handle the initialization window: being able to correctly handle > allocations starting at the process C++ initialization while dynamically > handing over allocations to the libjvm once it is loaded and NMT is > initialized. Another tricky problem was to prevent circularities stemming > from call intercepting. The prototype solves these problems and is already > stable enough to be used. > > Note that the patch is not complex or large. Some small interaction with > the JVM is needed, though, so this cannot be done just with an outside > library. > > The prototype was developed and tested on Linux x64 and with glibc 2.31. > It seems stable so far, but of course, the work is in an early stage, and > bugs may exist. If you want to play with the prototype, build it [3] and > then call: > > LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so ${JDK_DIR}/bin/java > -XX:NativeMemoryTracking=detail > > Example: quarkus with "third-party code" injected that leaks periodically > [5]: > > LEAK_MALLOC=1 LEAK_MMAP=1 LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so > ${JDK_DIR}/bin/java -agentpath:/shared/projects/jvmti-leak/leaker.so > -XX:NativeMemoryTracking=detail -jar ./quarkus-profiling-workshop/ > target/quarkus-app/quarkus-run.jar > > In Summary mode, we see the slowly growing leaks: > > -External (via interposition) (reserved=82216KB, committed=82216KB) > (malloc=81588KB #585) (at peak) > (mmap: reserved=628KB, committed=628KB, at > peak) > > > and in Detail mode, their call stacks: > > [0x00007ff067ee7000 - 0x00007ff067ee8000] reserved and committed 4KB for > External (via interposition) from > [0x00007ff067ef5056]the_mmap(void*, unsigned long, int, int, int, > long)+0x66 in libjnmt.so > [0x00007ff067ef5781]mmap+0x71 in libjnmt.so > [0x00007ff067ee955a]leak_mmap+0x3f in leaker.so > [0x00007ff067ee95b1]leakleak+0x1c in leaker.so > [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so > [0x00007ff067ee95db]leakabit+0x12 in leaker.so > [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so > > > [0x00007ff067ef5166]the_malloc(unsigned long)+0x106 in libjnmt.so > [0x00007ff067ee94ae]do_malloc+0xb8 in leaker.so > [0x00007ff067ee9518]leak_malloc+0x20 in leaker.so > [0x00007ff067ee95a7]leakleak+0x12 in leaker.so > [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so > [0x00007ff067ee95db]leakabit+0x12 in leaker.so > [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so > (malloc=17679KB type=External (via > interposition) #34) (at peak) > > --- > > What about MEMFLAGS? > > The prototype does not extend MEMFLAGS apart from introducing a new > "External" category that tracks allocations done via interposition. The > question of MEMFLAGS - in particular, opening it up to outside extension - > has been contentious. It is orthogonal to this proposal - nice but not > required. > > This proposal makes external allocations visible under the new "External" > tag: > - in NMT summary mode, we only have the "External" total, which is already > useful even as a lump sum: it shows the footprint non-hotspot libraries > contribute to RSS. An RSS increase that is reflected neither by hotspot > allocations nor by "External" can only stem from a select few places, e.g. > from libc malloc retention. > - In NMT detail mode, this proposal shows us the call stacks to foreign > call sites, pinpointing at least the libraries involved. > > -- > > What do you think, does this make sense? > > Thanks, Thomas > > > [1] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer > [2] > https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html > [3] https://github.com/tstuefe/jdk/tree/libjnmt > [4] https://bugs.openjdk.org/browse/JDK-8157023 > [5] https://github.com/tstuefe/jvmti_leak > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Tue Dec 5 10:55:12 2023 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2023 11:55:12 +0100 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? Message-ID: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> I just built windows-x86, and noticed that the build is broken: src\hotspot\share\prims\downcallLinker.cpp(36): error C2373: 'DowncallLinker::capture_state': redefinition; different type modifiers I think this is most likely caused by JDK-8254693, which was integrated three weeks ago. If no-one has discovered this, or bothered to fix it, maybe that is the signal we need to decide to actually stop pretending that windows-x86 is something we can build for, and just remove any remaining windows-x86 code? /Magnus From goetz.lindenmaier at sap.com Tue Dec 5 11:00:48 2023 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 5 Dec 2023 11:00:48 +0000 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: <2A961D30-BD87-43CE-99F7-BFA33E98D040@sap.com> Hi Magnus, There is https://openjdk.org/jeps/449 Deprecate the Windows 32-bit x86 Port for Removal I guess we need another JEP to remove it. (SAP does not need the port.) Best regards, Goetz. On 5. Dec 2023, at 11:55, Magnus Ihse Bursie wrote: I just built windows-x86, and noticed that the build is broken: src\hotspot\share\prims\downcallLinker.cpp(36): error C2373: 'DowncallLinker::capture_state': redefinition; different type modifiers I think this is most likely caused by JDK-8254693, which was integrated three weeks ago. If no-one has discovered this, or bothered to fix it, maybe that is the signal we need to decide to actually stop pretending that windows-x86 is something we can build for, and just remove any remaining windows-x86 code? /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From tstuefe at redhat.com Tue Dec 5 12:47:01 2023 From: tstuefe at redhat.com (Thomas Stuefe) Date: Tue, 5 Dec 2023 13:47:01 +0100 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: <521ae235-c03a-4b16-ae11-2bf298120d8a@oracle.com> References: <521ae235-c03a-4b16-ae11-2bf298120d8a@oracle.com> Message-ID: Hi Johan, That is unlikely to work, though not impossible. One could make it work I guess, if needed, by making the libjnmt.so use another than allocator than the libc. However, I'm not sure how compelling the use case is. Cheers, Thomas On Mon, Dec 4, 2023 at 11:49?AM Johan Sj?l?n wrote: > Hi Thomas, > > If a user would like to switch out the malloc which a JVM is using, would > they be able to do that while simultaneously using your interception > library?Thank you, > Johan > Hi, community, > > I experimented with extending Native Memory Tracking across the whole > process. I want to share my findings and propose a new JDK feature to allow > us to do that. > > TL;DR > > Proposed is a "native memory interposition library" shipped with the JDK > that would intercept all native memory calls from everywhere and redirect > them to NMT. > > Motivation: > > NMT is very useful but limited in its coverage. It only covers Hotspot and > a select few sites from the JDK. Most of the JDK, third-party native code, > and system libraries are not covered. This is a large hole in our > observability. I have seen people do (and done myself! eg [1]) strange and > weird things to hunt memory leaks in native code. This is especially tricky > in locked-down customer scenarios. > > But NMT is a capable tracker. We could use it for much more than just > tracking Hotspot. > > In the past, developers have attempted to extend NMT instrumentation over > parts of the JDK (e.g. [2]), which met resistance from Oracle. This is > understandable: a naive extension would require libraries to link against > the libjvm and instrument their coding. That introduces new dependencies > nobody wants. > > --- > > I propose a different way that works without instrumenting any caller > code. I hope this proposal proves less controversial than brute-force NMT > instrumentation of the JDK. And it would allow introspection of non-JDK > parts too. > > We could ship an interception library (a "libjnmt.so") within the JDK. > That library, if preloaded, would redirect native memory requests to NMT. A > customer who wants to analyze the native memory footprint of its apps could > start the JVM with LD_PRELOAD=libjnmt and then use NMT for introspection. > > Oracle and we continuously improve NMT; extending its reach across the > whole process would leverage that investment nicely. > > It also meshes well with other improvements. For example, we report NMT > numbers via JFR since [4] - with interposition, we could now expose > third-party native allocations via JFR. The new jcmd "System.map" would > automatically show memory mappings from outside Hotspot. There is a > precedent (libjsig), so shipping interposition libraries is not that > strange. > > --- > > I have a Linux-based POC that works and looks promising [3]. With that > prototype, I can see: > > - allocations from the JDK - e.g., now I finally see mapped byte buffers. > - allocations from third-party user code > - most allocations from system libraries, e.g., from the system zlib > - allocations via the new FFI interface > > The prototype tracks both mmap and malloc. Technically, the tricky part > was to handle the initialization window: being able to correctly handle > allocations starting at the process C++ initialization while dynamically > handing over allocations to the libjvm once it is loaded and NMT is > initialized. Another tricky problem was to prevent circularities stemming > from call intercepting. The prototype solves these problems and is already > stable enough to be used. > > Note that the patch is not complex or large. Some small interaction with > the JVM is needed, though, so this cannot be done just with an outside > library. > > The prototype was developed and tested on Linux x64 and with glibc 2.31. > It seems stable so far, but of course, the work is in an early stage, and > bugs may exist. If you want to play with the prototype, build it [3] and > then call: > > LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so ${JDK_DIR}/bin/java > -XX:NativeMemoryTracking=detail > > Example: quarkus with "third-party code" injected that leaks periodically > [5]: > > LEAK_MALLOC=1 LEAK_MMAP=1 LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so > ${JDK_DIR}/bin/java -agentpath:/shared/projects/jvmti-leak/leaker.so > -XX:NativeMemoryTracking=detail -jar ./quarkus-profiling-workshop/ > target/quarkus-app/quarkus-run.jar > > In Summary mode, we see the slowly growing leaks: > > -External (via interposition) (reserved=82216KB, committed=82216KB) > (malloc=81588KB #585) (at peak) > (mmap: reserved=628KB, committed=628KB, at > peak) > > > and in Detail mode, their call stacks: > > [0x00007ff067ee7000 - 0x00007ff067ee8000] reserved and committed 4KB for > External (via interposition) from > [0x00007ff067ef5056]the_mmap(void*, unsigned long, int, int, int, > long)+0x66 in libjnmt.so > [0x00007ff067ef5781]mmap+0x71 in libjnmt.so > [0x00007ff067ee955a]leak_mmap+0x3f in leaker.so > [0x00007ff067ee95b1]leakleak+0x1c in leaker.so > [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so > [0x00007ff067ee95db]leakabit+0x12 in leaker.so > [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so > > > [0x00007ff067ef5166]the_malloc(unsigned long)+0x106 in libjnmt.so > [0x00007ff067ee94ae]do_malloc+0xb8 in leaker.so > [0x00007ff067ee9518]leak_malloc+0x20 in leaker.so > [0x00007ff067ee95a7]leakleak+0x12 in leaker.so > [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so > [0x00007ff067ee95db]leakabit+0x12 in leaker.so > [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so > (malloc=17679KB type=External (via > interposition) #34) (at peak) > > --- > > What about MEMFLAGS? > > The prototype does not extend MEMFLAGS apart from introducing a new > "External" category that tracks allocations done via interposition. The > question of MEMFLAGS - in particular, opening it up to outside extension - > has been contentious. It is orthogonal to this proposal - nice but not > required. > > This proposal makes external allocations visible under the new "External" > tag: > - in NMT summary mode, we only have the "External" total, which is already > useful even as a lump sum: it shows the footprint non-hotspot libraries > contribute to RSS. An RSS increase that is reflected neither by hotspot > allocations nor by "External" can only stem from a select few places, e.g. > from libc malloc retention. > - In NMT detail mode, this proposal shows us the call stacks to foreign > call sites, pinpointing at least the libraries involved. > > -- > > What do you think, does this make sense? > > Thanks, Thomas > > > [1] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer > [2] > https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html > [3] https://github.com/tstuefe/jdk/tree/libjnmt > [4] https://bugs.openjdk.org/browse/JDK-8157023 > [5] https://github.com/tstuefe/jvmti_leak > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tstuefe at redhat.com Tue Dec 5 12:50:13 2023 From: tstuefe at redhat.com (Thomas Stuefe) Date: Tue, 5 Dec 2023 13:50:13 +0100 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: References: <521ae235-c03a-4b16-ae11-2bf298120d8a@oracle.com> Message-ID: Hi Brice, On Tue, Dec 5, 2023 at 12:49?AM Brice Dutheil wrote: > Hi Joha, > > Thomas will correct me as he is proposed the idea and much more > experienced, also I'm a mere reader of this ML. > > So, I have not toyed with the code, but I believe this should work, at > least on linux if linker has no restrictions. > > Typically interception happens because there is a function with the right > signature preloaded (via `LD_PRELOAD`) that linker will look up. The > magic can work because in order to do real work and invoke the right > methods down the line using `dlsym(RTLD_NEXT, name)`. And that should be > the next library on the path or the system as the linker should process > from left to right this `LD_PRELOAD`. > > ``` > void *malloc(size_t size) { > void *(*p_malloc)(size_t) = dlsym(RTLD_NEXT, "malloc"); > > // report back mem operation > > return p_malloc(size); > } > ``` > > https://man7.org/linux/man-pages/man8/ld.so.8.html > https://www.man7.org/linux/man-pages/man3/dlsym.3.html > > That said this might be tricky to avoid loops, if one function calls > `malloc`. > I think a simpler way would be to just add a way for libjnmt.so to use custom allocators. If it is just about using a standard replacement like jemalloc, a custom-tailored solution for that would be a lot simpler. But, again, not sure about the use case. Cheers, Thomas > > Also I suppose this could work on macos via `DYLD_PRELOAD` but unsure > since macos has some restrictions. > > -- > Brice > > > On Mon, Dec 4, 2023 at 13:14 Johan Sj?l?n wrote: > >> Hi Thomas, >> >> If a user would like to switch out the malloc which a JVM is using, would >> they be able to do that while simultaneously using your interception >> library? >> >> Thank you, >> Johan >> >> Hi, community, >> >> I experimented with extending Native Memory Tracking across the whole >> process. I want to share my findings and propose a new JDK feature to allow >> us to do that. >> >> TL;DR >> >> Proposed is a "native memory interposition library" shipped with the JDK >> that would intercept all native memory calls from everywhere and redirect >> them to NMT. >> >> Motivation: >> >> NMT is very useful but limited in its coverage. It only covers Hotspot >> and a select few sites from the JDK. Most of the JDK, third-party native >> code, and system libraries are not covered. This is a large hole in our >> observability. I have seen people do (and done myself! eg [1]) strange and >> weird things to hunt memory leaks in native code. This is especially tricky >> in locked-down customer scenarios. >> >> But NMT is a capable tracker. We could use it for much more than just >> tracking Hotspot. >> >> In the past, developers have attempted to extend NMT instrumentation over >> parts of the JDK (e.g. [2]), which met resistance from Oracle. This is >> understandable: a naive extension would require libraries to link against >> the libjvm and instrument their coding. That introduces new dependencies >> nobody wants. >> >> --- >> >> I propose a different way that works without instrumenting any caller >> code. I hope this proposal proves less controversial than brute-force NMT >> instrumentation of the JDK. And it would allow introspection of non-JDK >> parts too. >> >> We could ship an interception library (a "libjnmt.so") within the JDK. >> That library, if preloaded, would redirect native memory requests to NMT. A >> customer who wants to analyze the native memory footprint of its apps could >> start the JVM with LD_PRELOAD=libjnmt and then use NMT for introspection. >> >> Oracle and we continuously improve NMT; extending its reach across the >> whole process would leverage that investment nicely. >> >> It also meshes well with other improvements. For example, we report NMT >> numbers via JFR since [4] - with interposition, we could now expose >> third-party native allocations via JFR. The new jcmd "System.map" would >> automatically show memory mappings from outside Hotspot. There is a >> precedent (libjsig), so shipping interposition libraries is not that >> strange. >> >> --- >> >> I have a Linux-based POC that works and looks promising [3]. With that >> prototype, I can see: >> >> - allocations from the JDK - e.g., now I finally see mapped byte buffers. >> - allocations from third-party user code >> - most allocations from system libraries, e.g., from the system zlib >> - allocations via the new FFI interface >> >> The prototype tracks both mmap and malloc. Technically, the tricky part >> was to handle the initialization window: being able to correctly handle >> allocations starting at the process C++ initialization while dynamically >> handing over allocations to the libjvm once it is loaded and NMT is >> initialized. Another tricky problem was to prevent circularities stemming >> from call intercepting. The prototype solves these problems and is already >> stable enough to be used. >> >> Note that the patch is not complex or large. Some small interaction with >> the JVM is needed, though, so this cannot be done just with an outside >> library. >> >> The prototype was developed and tested on Linux x64 and with glibc 2.31. >> It seems stable so far, but of course, the work is in an early stage, and >> bugs may exist. If you want to play with the prototype, build it [3] and >> then call: >> >> LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so ${JDK_DIR}/bin/java >> -XX:NativeMemoryTracking=detail >> >> Example: quarkus with "third-party code" injected that leaks periodically >> [5]: >> >> LEAK_MALLOC=1 LEAK_MMAP=1 LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so >> ${JDK_DIR}/bin/java -agentpath:/shared/projects/jvmti-leak/leaker.so >> -XX:NativeMemoryTracking=detail -jar ./quarkus-profiling-workshop/ >> target/quarkus-app/quarkus-run.jar >> >> In Summary mode, we see the slowly growing leaks: >> >> -External (via interposition) (reserved=82216KB, committed=82216KB) >> (malloc=81588KB #585) (at peak) >> (mmap: reserved=628KB, committed=628KB, at >> peak) >> >> >> and in Detail mode, their call stacks: >> >> [0x00007ff067ee7000 - 0x00007ff067ee8000] reserved and committed 4KB for >> External (via interposition) from >> [0x00007ff067ef5056]the_mmap(void*, unsigned long, int, int, int, >> long)+0x66 in libjnmt.so >> [0x00007ff067ef5781]mmap+0x71 in libjnmt.so >> [0x00007ff067ee955a]leak_mmap+0x3f in leaker.so >> [0x00007ff067ee95b1]leakleak+0x1c in leaker.so >> [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so >> [0x00007ff067ee95db]leakabit+0x12 in leaker.so >> [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so >> >> >> [0x00007ff067ef5166]the_malloc(unsigned long)+0x106 in libjnmt.so >> [0x00007ff067ee94ae]do_malloc+0xb8 in leaker.so >> [0x00007ff067ee9518]leak_malloc+0x20 in leaker.so >> [0x00007ff067ee95a7]leakleak+0x12 in leaker.so >> [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so >> [0x00007ff067ee95db]leakabit+0x12 in leaker.so >> [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so >> (malloc=17679KB type=External (via >> interposition) #34) (at peak) >> >> --- >> >> What about MEMFLAGS? >> >> The prototype does not extend MEMFLAGS apart from introducing a new >> "External" category that tracks allocations done via interposition. The >> question of MEMFLAGS - in particular, opening it up to outside extension - >> has been contentious. It is orthogonal to this proposal - nice but not >> required. >> >> This proposal makes external allocations visible under the new "External" >> tag: >> - in NMT summary mode, we only have the "External" total, which is >> already useful even as a lump sum: it shows the footprint non-hotspot >> libraries contribute to RSS. An RSS increase that is reflected neither by >> hotspot allocations nor by "External" can only stem from a select few >> places, e.g. from libc malloc retention. >> - In NMT detail mode, this proposal shows us the call stacks to foreign >> call sites, pinpointing at least the libraries involved. >> >> -- >> >> What do you think, does this make sense? >> >> Thanks, Thomas >> >> >> [1] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer >> [2] >> https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html >> [3] https://github.com/tstuefe/jdk/tree/libjnmt >> [4] https://bugs.openjdk.org/browse/JDK-8157023 >> [5] https://github.com/tstuefe/jvmti_leak >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorn.vernee at oracle.com Tue Dec 5 13:14:50 2023 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Tue, 5 Dec 2023 14:14:50 +0100 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: I've tried to build the windows 32-bit port here and there over the last year, and always found the build to be broken for one reason or another. If it actually worked before JDK-8254693 then someone must have fixed it in the interim. Looks like there's at least one recent-ish PR targeting Windows 32-bit: https://github.com/openjdk/jdk/pull/16628 but it looks like the primary intent was to backport the fix to JDK 17 Jorn On 05/12/2023 11:55, Magnus Ihse Bursie wrote: > I just built windows-x86, and noticed that the build is broken: > > src\hotspot\share\prims\downcallLinker.cpp(36): error C2373: > 'DowncallLinker::capture_state': redefinition; different type modifiers > > I think this is most likely caused by JDK-8254693, which was > integrated three weeks ago. If no-one has discovered this, or bothered > to fix it, maybe that is the signal we need to decide to actually stop > pretending that windows-x86 is something we can build for, and just > remove any remaining windows-x86 code? > > /Magnus > > From thomas.stuefe at gmail.com Tue Dec 5 13:55:04 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 5 Dec 2023 14:55:04 +0100 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: This would be a welcome change. It also means we eliminate the only platform with multiple calling conventions, which may simplify macros like JNI_EXPORT. On Tue, Dec 5, 2023 at 12:22?PM Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > I just built windows-x86, and noticed that the build is broken: > > src\hotspot\share\prims\downcallLinker.cpp(36): error C2373: > 'DowncallLinker::capture_state': redefinition; different type modifiers > > I think this is most likely caused by JDK-8254693, which was integrated > three weeks ago. If no-one has discovered this, or bothered to fix it, > maybe that is the signal we need to decide to actually stop pretending > that windows-x86 is something we can build for, and just remove any > remaining windows-x86 code? > > /Magnus > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brice.dutheil at gmail.com Tue Dec 5 14:35:29 2023 From: brice.dutheil at gmail.com (Brice Dutheil) Date: Tue, 5 Dec 2023 15:35:29 +0100 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: References: <521ae235-c03a-4b16-ae11-2bf298120d8a@oracle.com> Message-ID: > If it is just about using a standard replacement like jemalloc. >From my experience, and what I believe Johan was asking as well, is indeed that. Deployment of workloads that need that, usually rely on "installing" an allocator library that is configured via `LD_PRELOAD`. This usually gives the option to change the allocator depending on multiple criteria : the workload itself, the CPU architecture. Sometimes jemalloc is better, sometimes tcmalloc is better, (not tried minimalloc), so the flexibility to tweak that is important. _All are better than glibc's malloc (arena "recycling" is quite bad in containerized envs and with multiple threads, leading to many dirty pages and higher RSS)._ So that's why I was envisioning a "standard" use of the preload ability of the linker, e.g. `LD_PROLOAD=path/to/jdk/lib/libjnmt.so /path/to/tcmalloc.so`. ...assuming it can work. -- Brice On Tue, Dec 5, 2023 at 1:50?PM Thomas Stuefe wrote: > Hi Brice, > > On Tue, Dec 5, 2023 at 12:49?AM Brice Dutheil > wrote: > >> Hi Joha, >> >> Thomas will correct me as he is proposed the idea and much more >> experienced, also I'm a mere reader of this ML. >> >> So, I have not toyed with the code, but I believe this should work, at >> least on linux if linker has no restrictions. >> >> Typically interception happens because there is a function with the right >> signature preloaded (via `LD_PRELOAD`) that linker will look up. The >> magic can work because in order to do real work and invoke the right >> methods down the line using `dlsym(RTLD_NEXT, name)`. And that should be >> the next library on the path or the system as the linker should process >> from left to right this `LD_PRELOAD`. >> >> ``` >> void *malloc(size_t size) { >> void *(*p_malloc)(size_t) = dlsym(RTLD_NEXT, "malloc"); >> >> // report back mem operation >> >> return p_malloc(size); >> } >> ``` >> >> https://man7.org/linux/man-pages/man8/ld.so.8.html >> https://www.man7.org/linux/man-pages/man3/dlsym.3.html >> >> That said this might be tricky to avoid loops, if one function calls >> `malloc`. >> > > I think a simpler way would be to just add a way for libjnmt.so to use > custom allocators. If it is just about using a standard replacement like > jemalloc, a custom-tailored solution for that would be a lot simpler. But, > again, not sure about the use case. > > Cheers, Thomas > > >> >> Also I suppose this could work on macos via `DYLD_PRELOAD` but unsure >> since macos has some restrictions. >> >> -- >> Brice >> >> >> On Mon, Dec 4, 2023 at 13:14 Johan Sj?l?n >> wrote: >> >>> Hi Thomas, >>> >>> If a user would like to switch out the malloc which a JVM is using, >>> would they be able to do that while simultaneously using your interception >>> library? >>> >>> Thank you, >>> Johan >>> >>> Hi, community, >>> >>> I experimented with extending Native Memory Tracking across the whole >>> process. I want to share my findings and propose a new JDK feature to allow >>> us to do that. >>> >>> TL;DR >>> >>> Proposed is a "native memory interposition library" shipped with the JDK >>> that would intercept all native memory calls from everywhere and redirect >>> them to NMT. >>> >>> Motivation: >>> >>> NMT is very useful but limited in its coverage. It only covers Hotspot >>> and a select few sites from the JDK. Most of the JDK, third-party native >>> code, and system libraries are not covered. This is a large hole in our >>> observability. I have seen people do (and done myself! eg [1]) strange and >>> weird things to hunt memory leaks in native code. This is especially tricky >>> in locked-down customer scenarios. >>> >>> But NMT is a capable tracker. We could use it for much more than just >>> tracking Hotspot. >>> >>> In the past, developers have attempted to extend NMT instrumentation >>> over parts of the JDK (e.g. [2]), which met resistance from Oracle. This is >>> understandable: a naive extension would require libraries to link against >>> the libjvm and instrument their coding. That introduces new dependencies >>> nobody wants. >>> >>> --- >>> >>> I propose a different way that works without instrumenting any caller >>> code. I hope this proposal proves less controversial than brute-force NMT >>> instrumentation of the JDK. And it would allow introspection of non-JDK >>> parts too. >>> >>> We could ship an interception library (a "libjnmt.so") within the JDK. >>> That library, if preloaded, would redirect native memory requests to NMT. A >>> customer who wants to analyze the native memory footprint of its apps could >>> start the JVM with LD_PRELOAD=libjnmt and then use NMT for >>> introspection. >>> >>> Oracle and we continuously improve NMT; extending its reach across the >>> whole process would leverage that investment nicely. >>> >>> It also meshes well with other improvements. For example, we report NMT >>> numbers via JFR since [4] - with interposition, we could now expose >>> third-party native allocations via JFR. The new jcmd "System.map" would >>> automatically show memory mappings from outside Hotspot. There is a >>> precedent (libjsig), so shipping interposition libraries is not that >>> strange. >>> >>> --- >>> >>> I have a Linux-based POC that works and looks promising [3]. With that >>> prototype, I can see: >>> >>> - allocations from the JDK - e.g., now I finally see mapped byte buffers. >>> - allocations from third-party user code >>> - most allocations from system libraries, e.g., from the system zlib >>> - allocations via the new FFI interface >>> >>> The prototype tracks both mmap and malloc. Technically, the tricky part >>> was to handle the initialization window: being able to correctly handle >>> allocations starting at the process C++ initialization while dynamically >>> handing over allocations to the libjvm once it is loaded and NMT is >>> initialized. Another tricky problem was to prevent circularities stemming >>> from call intercepting. The prototype solves these problems and is already >>> stable enough to be used. >>> >>> Note that the patch is not complex or large. Some small interaction with >>> the JVM is needed, though, so this cannot be done just with an outside >>> library. >>> >>> The prototype was developed and tested on Linux x64 and with glibc 2.31. >>> It seems stable so far, but of course, the work is in an early stage, and >>> bugs may exist. If you want to play with the prototype, build it [3] and >>> then call: >>> >>> LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so ${JDK_DIR}/bin/java >>> -XX:NativeMemoryTracking=detail >>> >>> Example: quarkus with "third-party code" injected that leaks >>> periodically [5]: >>> >>> LEAK_MALLOC=1 LEAK_MMAP=1 LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so >>> ${JDK_DIR}/bin/java -agentpath:/shared/projects/jvmti-leak/leaker.so >>> -XX:NativeMemoryTracking=detail -jar ./quarkus-profiling-workshop/ >>> target/quarkus-app/quarkus-run.jar >>> >>> In Summary mode, we see the slowly growing leaks: >>> >>> -External (via interposition) (reserved=82216KB, committed=82216KB) >>> (malloc=81588KB #585) (at peak) >>> (mmap: reserved=628KB, committed=628KB, at >>> peak) >>> >>> >>> and in Detail mode, their call stacks: >>> >>> [0x00007ff067ee7000 - 0x00007ff067ee8000] reserved and committed 4KB for >>> External (via interposition) from >>> [0x00007ff067ef5056]the_mmap(void*, unsigned long, int, int, int, >>> long)+0x66 in libjnmt.so >>> [0x00007ff067ef5781]mmap+0x71 in libjnmt.so >>> [0x00007ff067ee955a]leak_mmap+0x3f in leaker.so >>> [0x00007ff067ee95b1]leakleak+0x1c in leaker.so >>> [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so >>> [0x00007ff067ee95db]leakabit+0x12 in leaker.so >>> [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so >>> >>> >>> [0x00007ff067ef5166]the_malloc(unsigned long)+0x106 in libjnmt.so >>> [0x00007ff067ee94ae]do_malloc+0xb8 in leaker.so >>> [0x00007ff067ee9518]leak_malloc+0x20 in leaker.so >>> [0x00007ff067ee95a7]leakleak+0x12 in leaker.so >>> [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so >>> [0x00007ff067ee95db]leakabit+0x12 in leaker.so >>> [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so >>> (malloc=17679KB type=External (via >>> interposition) #34) (at peak) >>> >>> --- >>> >>> What about MEMFLAGS? >>> >>> The prototype does not extend MEMFLAGS apart from introducing a new >>> "External" category that tracks allocations done via interposition. The >>> question of MEMFLAGS - in particular, opening it up to outside extension - >>> has been contentious. It is orthogonal to this proposal - nice but not >>> required. >>> >>> This proposal makes external allocations visible under the new >>> "External" tag: >>> - in NMT summary mode, we only have the "External" total, which is >>> already useful even as a lump sum: it shows the footprint non-hotspot >>> libraries contribute to RSS. An RSS increase that is reflected neither by >>> hotspot allocations nor by "External" can only stem from a select few >>> places, e.g. from libc malloc retention. >>> - In NMT detail mode, this proposal shows us the call stacks to foreign >>> call sites, pinpointing at least the libraries involved. >>> >>> -- >>> >>> What do you think, does this make sense? >>> >>> Thanks, Thomas >>> >>> >>> [1] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer >>> [2] >>> https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html >>> [3] https://github.com/tstuefe/jdk/tree/libjnmt >>> [4] https://bugs.openjdk.org/browse/JDK-8157023 >>> [5] https://github.com/tstuefe/jvmti_leak >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Tue Dec 5 15:12:24 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 5 Dec 2023 16:12:24 +0100 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: References: <521ae235-c03a-4b16-ae11-2bf298120d8a@oracle.com> Message-ID: On Tue, Dec 5, 2023 at 3:36?PM Brice Dutheil wrote: > > If it is just about using a standard replacement like jemalloc. > > From my experience, and what I believe Johan was asking as well, is indeed > that. > > Deployment of workloads that need that, usually rely on "installing" an > allocator library that is configured via `LD_PRELOAD`. This usually gives > the option to change the allocator depending on multiple criteria : the > workload itself, the CPU architecture. Sometimes jemalloc is better, > sometimes tcmalloc is better, (not tried minimalloc), so the flexibility to > tweak that is important. > _All are better than glibc's malloc (arena "recycling" is quite bad in > containerized envs and with multiple threads, leading to many dirty pages > and higher RSS)._ > > I always wondered how much of that is urban legend. I measured myself a while ago (maybe I can dig up the results somewhere), and IIRC, I could produce artificial scenarios with way more overhead for the glibc case, but in the practical cases, it seemed not to matter. I even saw cases where glibc was better. In any case, let us not derail this discussion. If jemalloc compatibility is required, I don't think it would be a show-stopper. > So that's why I was envisioning a "standard" use of the preload ability of > the linker, e.g. `LD_PROLOAD=path/to/jdk/lib/libjnmt.so > /path/to/tcmalloc.so`. > ...assuming it can work. > > > > -- Brice > > > On Tue, Dec 5, 2023 at 1:50?PM Thomas Stuefe wrote: > >> Hi Brice, >> >> On Tue, Dec 5, 2023 at 12:49?AM Brice Dutheil >> wrote: >> >>> Hi Joha, >>> >>> Thomas will correct me as he is proposed the idea and much more >>> experienced, also I'm a mere reader of this ML. >>> >>> So, I have not toyed with the code, but I believe this should work, at >>> least on linux if linker has no restrictions. >>> >>> Typically interception happens because there is a function with the >>> right signature preloaded (via `LD_PRELOAD`) that linker will look up. >>> The magic can work because in order to do real work and invoke the right >>> methods down the line using `dlsym(RTLD_NEXT, name)`. And that should be >>> the next library on the path or the system as the linker should process >>> from left to right this `LD_PRELOAD`. >>> >>> ``` >>> void *malloc(size_t size) { >>> void *(*p_malloc)(size_t) = dlsym(RTLD_NEXT, "malloc"); >>> >>> // report back mem operation >>> >>> return p_malloc(size); >>> } >>> ``` >>> >>> https://man7.org/linux/man-pages/man8/ld.so.8.html >>> https://www.man7.org/linux/man-pages/man3/dlsym.3.html >>> >>> That said this might be tricky to avoid loops, if one function calls >>> `malloc`. >>> >> >> I think a simpler way would be to just add a way for libjnmt.so to use >> custom allocators. If it is just about using a standard replacement like >> jemalloc, a custom-tailored solution for that would be a lot simpler. But, >> again, not sure about the use case. >> >> Cheers, Thomas >> >> >>> >>> Also I suppose this could work on macos via `DYLD_PRELOAD` but unsure >>> since macos has some restrictions. >>> >>> -- >>> Brice >>> >>> >>> On Mon, Dec 4, 2023 at 13:14 Johan Sj?l?n >>> wrote: >>> >>>> Hi Thomas, >>>> >>>> If a user would like to switch out the malloc which a JVM is using, >>>> would they be able to do that while simultaneously using your interception >>>> library? >>>> >>>> Thank you, >>>> Johan >>>> >>>> Hi, community, >>>> >>>> I experimented with extending Native Memory Tracking across the whole >>>> process. I want to share my findings and propose a new JDK feature to allow >>>> us to do that. >>>> >>>> TL;DR >>>> >>>> Proposed is a "native memory interposition library" shipped with the >>>> JDK that would intercept all native memory calls from everywhere and >>>> redirect them to NMT. >>>> >>>> Motivation: >>>> >>>> NMT is very useful but limited in its coverage. It only covers Hotspot >>>> and a select few sites from the JDK. Most of the JDK, third-party native >>>> code, and system libraries are not covered. This is a large hole in our >>>> observability. I have seen people do (and done myself! eg [1]) strange and >>>> weird things to hunt memory leaks in native code. This is especially tricky >>>> in locked-down customer scenarios. >>>> >>>> But NMT is a capable tracker. We could use it for much more than just >>>> tracking Hotspot. >>>> >>>> In the past, developers have attempted to extend NMT instrumentation >>>> over parts of the JDK (e.g. [2]), which met resistance from Oracle. This is >>>> understandable: a naive extension would require libraries to link against >>>> the libjvm and instrument their coding. That introduces new dependencies >>>> nobody wants. >>>> >>>> --- >>>> >>>> I propose a different way that works without instrumenting any caller >>>> code. I hope this proposal proves less controversial than brute-force NMT >>>> instrumentation of the JDK. And it would allow introspection of non-JDK >>>> parts too. >>>> >>>> We could ship an interception library (a "libjnmt.so") within the JDK. >>>> That library, if preloaded, would redirect native memory requests to NMT. A >>>> customer who wants to analyze the native memory footprint of its apps could >>>> start the JVM with LD_PRELOAD=libjnmt and then use NMT for >>>> introspection. >>>> >>>> Oracle and we continuously improve NMT; extending its reach across the >>>> whole process would leverage that investment nicely. >>>> >>>> It also meshes well with other improvements. For example, we report NMT >>>> numbers via JFR since [4] - with interposition, we could now expose >>>> third-party native allocations via JFR. The new jcmd "System.map" would >>>> automatically show memory mappings from outside Hotspot. There is a >>>> precedent (libjsig), so shipping interposition libraries is not that >>>> strange. >>>> >>>> --- >>>> >>>> I have a Linux-based POC that works and looks promising [3]. With that >>>> prototype, I can see: >>>> >>>> - allocations from the JDK - e.g., now I finally see mapped byte >>>> buffers. >>>> - allocations from third-party user code >>>> - most allocations from system libraries, e.g., from the system zlib >>>> - allocations via the new FFI interface >>>> >>>> The prototype tracks both mmap and malloc. Technically, the tricky part >>>> was to handle the initialization window: being able to correctly handle >>>> allocations starting at the process C++ initialization while dynamically >>>> handing over allocations to the libjvm once it is loaded and NMT is >>>> initialized. Another tricky problem was to prevent circularities stemming >>>> from call intercepting. The prototype solves these problems and is already >>>> stable enough to be used. >>>> >>>> Note that the patch is not complex or large. Some small interaction >>>> with the JVM is needed, though, so this cannot be done just with an outside >>>> library. >>>> >>>> The prototype was developed and tested on Linux x64 and with glibc >>>> 2.31. It seems stable so far, but of course, the work is in an early stage, >>>> and bugs may exist. If you want to play with the prototype, build it [3] >>>> and then call: >>>> >>>> LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so ${JDK_DIR}/bin/java >>>> -XX:NativeMemoryTracking=detail >>>> >>>> Example: quarkus with "third-party code" injected that leaks >>>> periodically [5]: >>>> >>>> LEAK_MALLOC=1 LEAK_MMAP=1 LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so >>>> ${JDK_DIR}/bin/java -agentpath:/shared/projects/jvmti-leak/leaker.so >>>> -XX:NativeMemoryTracking=detail -jar ./quarkus-profiling-workshop/ >>>> target/quarkus-app/quarkus-run.jar >>>> >>>> In Summary mode, we see the slowly growing leaks: >>>> >>>> -External (via interposition) (reserved=82216KB, committed=82216KB) >>>> (malloc=81588KB #585) (at peak) >>>> (mmap: reserved=628KB, committed=628KB, at >>>> peak) >>>> >>>> >>>> and in Detail mode, their call stacks: >>>> >>>> [0x00007ff067ee7000 - 0x00007ff067ee8000] reserved and committed 4KB >>>> for External (via interposition) from >>>> [0x00007ff067ef5056]the_mmap(void*, unsigned long, int, int, int, >>>> long)+0x66 in libjnmt.so >>>> [0x00007ff067ef5781]mmap+0x71 in libjnmt.so >>>> [0x00007ff067ee955a]leak_mmap+0x3f in leaker.so >>>> [0x00007ff067ee95b1]leakleak+0x1c in leaker.so >>>> [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so >>>> [0x00007ff067ee95db]leakabit+0x12 in leaker.so >>>> [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so >>>> >>>> >>>> [0x00007ff067ef5166]the_malloc(unsigned long)+0x106 in libjnmt.so >>>> [0x00007ff067ee94ae]do_malloc+0xb8 in leaker.so >>>> [0x00007ff067ee9518]leak_malloc+0x20 in leaker.so >>>> [0x00007ff067ee95a7]leakleak+0x12 in leaker.so >>>> [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so >>>> [0x00007ff067ee95db]leakabit+0x12 in leaker.so >>>> [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so >>>> (malloc=17679KB type=External (via >>>> interposition) #34) (at peak) >>>> >>>> --- >>>> >>>> What about MEMFLAGS? >>>> >>>> The prototype does not extend MEMFLAGS apart from introducing a new >>>> "External" category that tracks allocations done via interposition. The >>>> question of MEMFLAGS - in particular, opening it up to outside extension - >>>> has been contentious. It is orthogonal to this proposal - nice but not >>>> required. >>>> >>>> This proposal makes external allocations visible under the new >>>> "External" tag: >>>> - in NMT summary mode, we only have the "External" total, which is >>>> already useful even as a lump sum: it shows the footprint non-hotspot >>>> libraries contribute to RSS. An RSS increase that is reflected neither by >>>> hotspot allocations nor by "External" can only stem from a select few >>>> places, e.g. from libc malloc retention. >>>> - In NMT detail mode, this proposal shows us the call stacks to foreign >>>> call sites, pinpointing at least the libraries involved. >>>> >>>> -- >>>> >>>> What do you think, does this make sense? >>>> >>>> Thanks, Thomas >>>> >>>> >>>> [1] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer >>>> [2] >>>> https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html >>>> [3] https://github.com/tstuefe/jdk/tree/libjnmt >>>> [4] https://bugs.openjdk.org/browse/JDK-8157023 >>>> [5] https://github.com/tstuefe/jvmti_leak >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From brice.dutheil at gmail.com Tue Dec 5 15:39:03 2023 From: brice.dutheil at gmail.com (Brice Dutheil) Date: Tue, 5 Dec 2023 16:39:03 +0100 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: References: <521ae235-c03a-4b16-ae11-2bf298120d8a@oracle.com> Message-ID: > let us not derail this discussion. Last comment from me on the topic. I have seen this on workload from my previous employer using ~4Gig, I was able to reduce native memory from ~1200 MiB to ~400 MiB, likely due to the arena and fragmentation. And the worst is that native memory was increasing at a very slow pace but steadily ; I don't think it was a leak but I cannot guarantee that either. That said, changing the native allocator removed this bad behavior. My current job is not anymore about production so I don't follow everything, but I've seen that colleagues have similar issues and when they tried another allocator their problem was gone. I have not dived into what other language runtime experiences, but I regularly saw advice to change the default allocator. -- Brice On Tue, Dec 5, 2023 at 4:12?PM Thomas St?fe wrote: > > > On Tue, Dec 5, 2023 at 3:36?PM Brice Dutheil > wrote: > >> > If it is just about using a standard replacement like jemalloc. >> >> From my experience, and what I believe Johan was asking as well, is >> indeed that. >> >> Deployment of workloads that need that, usually rely on "installing" an >> allocator library that is configured via `LD_PRELOAD`. This usually gives >> the option to change the allocator depending on multiple criteria : the >> workload itself, the CPU architecture. Sometimes jemalloc is better, >> sometimes tcmalloc is better, (not tried minimalloc), so the flexibility to >> tweak that is important. >> _All are better than glibc's malloc (arena "recycling" is quite bad in >> containerized envs and with multiple threads, leading to many dirty pages >> and higher RSS)._ >> >> > I always wondered how much of that is urban legend. I measured myself a > while ago (maybe I can dig up the results somewhere), and IIRC, I could > produce artificial scenarios with way more overhead for the glibc case, but > in the practical cases, it seemed not to matter. I even saw cases where > glibc was better. > > In any case, let us not derail this discussion. If jemalloc compatibility > is required, I don't think it would be a show-stopper. > > > >> So that's why I was envisioning a "standard" use of the preload ability >> of the linker, e.g. `LD_PROLOAD=path/to/jdk/lib/libjnmt.so >> /path/to/tcmalloc.so`. >> ...assuming it can work. >> >> >> >> -- Brice >> >> >> On Tue, Dec 5, 2023 at 1:50?PM Thomas Stuefe wrote: >> >>> Hi Brice, >>> >>> On Tue, Dec 5, 2023 at 12:49?AM Brice Dutheil >>> wrote: >>> >>>> Hi Joha, >>>> >>>> Thomas will correct me as he is proposed the idea and much more >>>> experienced, also I'm a mere reader of this ML. >>>> >>>> So, I have not toyed with the code, but I believe this should work, at >>>> least on linux if linker has no restrictions. >>>> >>>> Typically interception happens because there is a function with the >>>> right signature preloaded (via `LD_PRELOAD`) that linker will look up. >>>> The magic can work because in order to do real work and invoke the right >>>> methods down the line using `dlsym(RTLD_NEXT, name)`. And that should be >>>> the next library on the path or the system as the linker should process >>>> from left to right this `LD_PRELOAD`. >>>> >>>> ``` >>>> void *malloc(size_t size) { >>>> void *(*p_malloc)(size_t) = dlsym(RTLD_NEXT, "malloc"); >>>> >>>> // report back mem operation >>>> >>>> return p_malloc(size); >>>> } >>>> ``` >>>> >>>> https://man7.org/linux/man-pages/man8/ld.so.8.html >>>> https://www.man7.org/linux/man-pages/man3/dlsym.3.html >>>> >>>> That said this might be tricky to avoid loops, if one function calls >>>> `malloc`. >>>> >>> >>> I think a simpler way would be to just add a way for libjnmt.so to use >>> custom allocators. If it is just about using a standard replacement like >>> jemalloc, a custom-tailored solution for that would be a lot simpler. But, >>> again, not sure about the use case. >>> >>> Cheers, Thomas >>> >>> >>>> >>>> Also I suppose this could work on macos via `DYLD_PRELOAD` but unsure >>>> since macos has some restrictions. >>>> >>>> -- >>>> Brice >>>> >>>> >>>> On Mon, Dec 4, 2023 at 13:14 Johan Sj?l?n >>>> wrote: >>>> >>>>> Hi Thomas, >>>>> >>>>> If a user would like to switch out the malloc which a JVM is using, >>>>> would they be able to do that while simultaneously using your interception >>>>> library? >>>>> >>>>> Thank you, >>>>> Johan >>>>> >>>>> Hi, community, >>>>> >>>>> I experimented with extending Native Memory Tracking across the whole >>>>> process. I want to share my findings and propose a new JDK feature to allow >>>>> us to do that. >>>>> >>>>> TL;DR >>>>> >>>>> Proposed is a "native memory interposition library" shipped with the >>>>> JDK that would intercept all native memory calls from everywhere and >>>>> redirect them to NMT. >>>>> >>>>> Motivation: >>>>> >>>>> NMT is very useful but limited in its coverage. It only covers Hotspot >>>>> and a select few sites from the JDK. Most of the JDK, third-party native >>>>> code, and system libraries are not covered. This is a large hole in our >>>>> observability. I have seen people do (and done myself! eg [1]) strange and >>>>> weird things to hunt memory leaks in native code. This is especially tricky >>>>> in locked-down customer scenarios. >>>>> >>>>> But NMT is a capable tracker. We could use it for much more than just >>>>> tracking Hotspot. >>>>> >>>>> In the past, developers have attempted to extend NMT instrumentation >>>>> over parts of the JDK (e.g. [2]), which met resistance from Oracle. This is >>>>> understandable: a naive extension would require libraries to link against >>>>> the libjvm and instrument their coding. That introduces new dependencies >>>>> nobody wants. >>>>> >>>>> --- >>>>> >>>>> I propose a different way that works without instrumenting any caller >>>>> code. I hope this proposal proves less controversial than brute-force NMT >>>>> instrumentation of the JDK. And it would allow introspection of non-JDK >>>>> parts too. >>>>> >>>>> We could ship an interception library (a "libjnmt.so") within the JDK. >>>>> That library, if preloaded, would redirect native memory requests to NMT. A >>>>> customer who wants to analyze the native memory footprint of its apps could >>>>> start the JVM with LD_PRELOAD=libjnmt and then use NMT for >>>>> introspection. >>>>> >>>>> Oracle and we continuously improve NMT; extending its reach across the >>>>> whole process would leverage that investment nicely. >>>>> >>>>> It also meshes well with other improvements. For example, we report >>>>> NMT numbers via JFR since [4] - with interposition, we could now expose >>>>> third-party native allocations via JFR. The new jcmd "System.map" would >>>>> automatically show memory mappings from outside Hotspot. There is a >>>>> precedent (libjsig), so shipping interposition libraries is not that >>>>> strange. >>>>> >>>>> --- >>>>> >>>>> I have a Linux-based POC that works and looks promising [3]. With that >>>>> prototype, I can see: >>>>> >>>>> - allocations from the JDK - e.g., now I finally see mapped byte >>>>> buffers. >>>>> - allocations from third-party user code >>>>> - most allocations from system libraries, e.g., from the system zlib >>>>> - allocations via the new FFI interface >>>>> >>>>> The prototype tracks both mmap and malloc. Technically, the tricky >>>>> part was to handle the initialization window: being able to correctly >>>>> handle allocations starting at the process C++ initialization while >>>>> dynamically handing over allocations to the libjvm once it is loaded and >>>>> NMT is initialized. Another tricky problem was to prevent circularities >>>>> stemming from call intercepting. The prototype solves these problems and is >>>>> already stable enough to be used. >>>>> >>>>> Note that the patch is not complex or large. Some small interaction >>>>> with the JVM is needed, though, so this cannot be done just with an outside >>>>> library. >>>>> >>>>> The prototype was developed and tested on Linux x64 and with glibc >>>>> 2.31. It seems stable so far, but of course, the work is in an early stage, >>>>> and bugs may exist. If you want to play with the prototype, build it [3] >>>>> and then call: >>>>> >>>>> LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so ${JDK_DIR}/bin/java >>>>> -XX:NativeMemoryTracking=detail >>>>> >>>>> Example: quarkus with "third-party code" injected that leaks >>>>> periodically [5]: >>>>> >>>>> LEAK_MALLOC=1 LEAK_MMAP=1 LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so >>>>> ${JDK_DIR}/bin/java -agentpath:/shared/projects/jvmti-leak/leaker.so >>>>> -XX:NativeMemoryTracking=detail -jar ./quarkus-profiling-workshop/ >>>>> target/quarkus-app/quarkus-run.jar >>>>> >>>>> In Summary mode, we see the slowly growing leaks: >>>>> >>>>> -External (via interposition) (reserved=82216KB, committed=82216KB) >>>>> (malloc=81588KB #585) (at peak) >>>>> (mmap: reserved=628KB, committed=628KB, at >>>>> peak) >>>>> >>>>> >>>>> and in Detail mode, their call stacks: >>>>> >>>>> [0x00007ff067ee7000 - 0x00007ff067ee8000] reserved and committed 4KB >>>>> for External (via interposition) from >>>>> [0x00007ff067ef5056]the_mmap(void*, unsigned long, int, int, int, >>>>> long)+0x66 in libjnmt.so >>>>> [0x00007ff067ef5781]mmap+0x71 in libjnmt.so >>>>> [0x00007ff067ee955a]leak_mmap+0x3f in leaker.so >>>>> [0x00007ff067ee95b1]leakleak+0x1c in leaker.so >>>>> [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so >>>>> [0x00007ff067ee95db]leakabit+0x12 in leaker.so >>>>> [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so >>>>> >>>>> >>>>> [0x00007ff067ef5166]the_malloc(unsigned long)+0x106 in libjnmt.so >>>>> [0x00007ff067ee94ae]do_malloc+0xb8 in leaker.so >>>>> [0x00007ff067ee9518]leak_malloc+0x20 in leaker.so >>>>> [0x00007ff067ee95a7]leakleak+0x12 in leaker.so >>>>> [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so >>>>> [0x00007ff067ee95db]leakabit+0x12 in leaker.so >>>>> [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so >>>>> (malloc=17679KB type=External (via >>>>> interposition) #34) (at peak) >>>>> >>>>> --- >>>>> >>>>> What about MEMFLAGS? >>>>> >>>>> The prototype does not extend MEMFLAGS apart from introducing a new >>>>> "External" category that tracks allocations done via interposition. The >>>>> question of MEMFLAGS - in particular, opening it up to outside extension - >>>>> has been contentious. It is orthogonal to this proposal - nice but not >>>>> required. >>>>> >>>>> This proposal makes external allocations visible under the new >>>>> "External" tag: >>>>> - in NMT summary mode, we only have the "External" total, which is >>>>> already useful even as a lump sum: it shows the footprint non-hotspot >>>>> libraries contribute to RSS. An RSS increase that is reflected neither by >>>>> hotspot allocations nor by "External" can only stem from a select few >>>>> places, e.g. from libc malloc retention. >>>>> - In NMT detail mode, this proposal shows us the call stacks to >>>>> foreign call sites, pinpointing at least the libraries involved. >>>>> >>>>> -- >>>>> >>>>> What do you think, does this make sense? >>>>> >>>>> Thanks, Thomas >>>>> >>>>> >>>>> [1] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer >>>>> [2] >>>>> https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html >>>>> [3] https://github.com/tstuefe/jdk/tree/libjnmt >>>>> [4] https://bugs.openjdk.org/browse/JDK-8157023 >>>>> [5] https://github.com/tstuefe/jvmti_leak >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From numeralnathan at gmail.com Tue Dec 5 17:35:45 2023 From: numeralnathan at gmail.com (Nathan Reynolds) Date: Tue, 5 Dec 2023 09:35:45 -0800 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: References: <521ae235-c03a-4b16-ae11-2bf298120d8a@oracle.com> Message-ID: Fragmentation is a problem that all memory allocators have to deal with. Each allocator deals with fragmentation in a different way. Java's heap (not to be confused with the native memory allocator) relocates objects to deal with fragmentation. I am not surprised that changing allocators will fix memory growth problems. A different allocator will be able to handle the allocation pattern differently and prevent fragmentation. I've had to replace the default C allocator many times due to fragmentation and lock contention. On Tue, Dec 5, 2023 at 9:23?AM Brice Dutheil wrote: > > let us not derail this discussion. > > Last comment from me on the topic. > > I have seen this on workload from my previous employer using ~4Gig, I was > able to reduce native memory from ~1200 MiB to ~400 MiB, likely due to the > arena and fragmentation. And the worst is that native memory was increasing > at a very slow pace but steadily ; I don't think it was a leak but I cannot > guarantee that either. That said, changing the native allocator removed > this bad behavior. > > My current job is not anymore about production so I don't follow > everything, but I've seen that colleagues have similar issues and when they > tried another allocator their problem was gone. > > I have not dived into what other language runtime experiences, but I > regularly saw advice to change the default allocator. > > -- Brice > > > On Tue, Dec 5, 2023 at 4:12?PM Thomas St?fe > wrote: > >> >> >> On Tue, Dec 5, 2023 at 3:36?PM Brice Dutheil >> wrote: >> >>> > If it is just about using a standard replacement like jemalloc. >>> >>> From my experience, and what I believe Johan was asking as well, is >>> indeed that. >>> >>> Deployment of workloads that need that, usually rely on "installing" an >>> allocator library that is configured via `LD_PRELOAD`. This usually gives >>> the option to change the allocator depending on multiple criteria : the >>> workload itself, the CPU architecture. Sometimes jemalloc is better, >>> sometimes tcmalloc is better, (not tried minimalloc), so the flexibility to >>> tweak that is important. >>> _All are better than glibc's malloc (arena "recycling" is quite bad in >>> containerized envs and with multiple threads, leading to many dirty pages >>> and higher RSS)._ >>> >>> >> I always wondered how much of that is urban legend. I measured myself a >> while ago (maybe I can dig up the results somewhere), and IIRC, I could >> produce artificial scenarios with way more overhead for the glibc case, but >> in the practical cases, it seemed not to matter. I even saw cases where >> glibc was better. >> >> In any case, let us not derail this discussion. If jemalloc compatibility >> is required, I don't think it would be a show-stopper. >> >> >> >>> So that's why I was envisioning a "standard" use of the preload ability >>> of the linker, e.g. `LD_PROLOAD=path/to/jdk/lib/libjnmt.so >>> /path/to/tcmalloc.so`. >>> ...assuming it can work. >>> >>> >>> >>> -- Brice >>> >>> >>> On Tue, Dec 5, 2023 at 1:50?PM Thomas Stuefe wrote: >>> >>>> Hi Brice, >>>> >>>> On Tue, Dec 5, 2023 at 12:49?AM Brice Dutheil >>>> wrote: >>>> >>>>> Hi Joha, >>>>> >>>>> Thomas will correct me as he is proposed the idea and much more >>>>> experienced, also I'm a mere reader of this ML. >>>>> >>>>> So, I have not toyed with the code, but I believe this should work, at >>>>> least on linux if linker has no restrictions. >>>>> >>>>> Typically interception happens because there is a function with the >>>>> right signature preloaded (via `LD_PRELOAD`) that linker will look >>>>> up. The magic can work because in order to do real work and invoke the >>>>> right methods down the line using `dlsym(RTLD_NEXT, name)`. And that should >>>>> be the next library on the path or the system as the linker should process >>>>> from left to right this `LD_PRELOAD`. >>>>> >>>>> ``` >>>>> void *malloc(size_t size) { >>>>> void *(*p_malloc)(size_t) = dlsym(RTLD_NEXT, "malloc"); >>>>> >>>>> // report back mem operation >>>>> >>>>> return p_malloc(size); >>>>> } >>>>> ``` >>>>> >>>>> https://man7.org/linux/man-pages/man8/ld.so.8.html >>>>> https://www.man7.org/linux/man-pages/man3/dlsym.3.html >>>>> >>>>> That said this might be tricky to avoid loops, if one function calls >>>>> `malloc`. >>>>> >>>> >>>> I think a simpler way would be to just add a way for libjnmt.so to use >>>> custom allocators. If it is just about using a standard replacement like >>>> jemalloc, a custom-tailored solution for that would be a lot simpler. But, >>>> again, not sure about the use case. >>>> >>>> Cheers, Thomas >>>> >>>> >>>>> >>>>> Also I suppose this could work on macos via `DYLD_PRELOAD` but unsure >>>>> since macos has some restrictions. >>>>> >>>>> -- >>>>> Brice >>>>> >>>>> >>>>> On Mon, Dec 4, 2023 at 13:14 Johan Sj?l?n >>>>> wrote: >>>>> >>>>>> Hi Thomas, >>>>>> >>>>>> If a user would like to switch out the malloc which a JVM is using, >>>>>> would they be able to do that while simultaneously using your interception >>>>>> library? >>>>>> >>>>>> Thank you, >>>>>> Johan >>>>>> >>>>>> Hi, community, >>>>>> >>>>>> I experimented with extending Native Memory Tracking across the whole >>>>>> process. I want to share my findings and propose a new JDK feature to allow >>>>>> us to do that. >>>>>> >>>>>> TL;DR >>>>>> >>>>>> Proposed is a "native memory interposition library" shipped with the >>>>>> JDK that would intercept all native memory calls from everywhere and >>>>>> redirect them to NMT. >>>>>> >>>>>> Motivation: >>>>>> >>>>>> NMT is very useful but limited in its coverage. It only covers >>>>>> Hotspot and a select few sites from the JDK. Most of the JDK, third-party >>>>>> native code, and system libraries are not covered. This is a large hole in >>>>>> our observability. I have seen people do (and done myself! eg [1]) strange >>>>>> and weird things to hunt memory leaks in native code. This is especially >>>>>> tricky in locked-down customer scenarios. >>>>>> >>>>>> But NMT is a capable tracker. We could use it for much more than just >>>>>> tracking Hotspot. >>>>>> >>>>>> In the past, developers have attempted to extend NMT instrumentation >>>>>> over parts of the JDK (e.g. [2]), which met resistance from Oracle. This is >>>>>> understandable: a naive extension would require libraries to link against >>>>>> the libjvm and instrument their coding. That introduces new dependencies >>>>>> nobody wants. >>>>>> >>>>>> --- >>>>>> >>>>>> I propose a different way that works without instrumenting any caller >>>>>> code. I hope this proposal proves less controversial than brute-force NMT >>>>>> instrumentation of the JDK. And it would allow introspection of non-JDK >>>>>> parts too. >>>>>> >>>>>> We could ship an interception library (a "libjnmt.so") within the >>>>>> JDK. That library, if preloaded, would redirect native memory requests to >>>>>> NMT. A customer who wants to analyze the native memory footprint of its >>>>>> apps could start the JVM with LD_PRELOAD=libjnmt and then use NMT >>>>>> for introspection. >>>>>> >>>>>> Oracle and we continuously improve NMT; extending its reach across >>>>>> the whole process would leverage that investment nicely. >>>>>> >>>>>> It also meshes well with other improvements. For example, we report >>>>>> NMT numbers via JFR since [4] - with interposition, we could now expose >>>>>> third-party native allocations via JFR. The new jcmd "System.map" would >>>>>> automatically show memory mappings from outside Hotspot. There is a >>>>>> precedent (libjsig), so shipping interposition libraries is not that >>>>>> strange. >>>>>> >>>>>> --- >>>>>> >>>>>> I have a Linux-based POC that works and looks promising [3]. With >>>>>> that prototype, I can see: >>>>>> >>>>>> - allocations from the JDK - e.g., now I finally see mapped byte >>>>>> buffers. >>>>>> - allocations from third-party user code >>>>>> - most allocations from system libraries, e.g., from the system zlib >>>>>> - allocations via the new FFI interface >>>>>> >>>>>> The prototype tracks both mmap and malloc. Technically, the tricky >>>>>> part was to handle the initialization window: being able to correctly >>>>>> handle allocations starting at the process C++ initialization while >>>>>> dynamically handing over allocations to the libjvm once it is loaded and >>>>>> NMT is initialized. Another tricky problem was to prevent circularities >>>>>> stemming from call intercepting. The prototype solves these problems and is >>>>>> already stable enough to be used. >>>>>> >>>>>> Note that the patch is not complex or large. Some small interaction >>>>>> with the JVM is needed, though, so this cannot be done just with an outside >>>>>> library. >>>>>> >>>>>> The prototype was developed and tested on Linux x64 and with glibc >>>>>> 2.31. It seems stable so far, but of course, the work is in an early stage, >>>>>> and bugs may exist. If you want to play with the prototype, build it [3] >>>>>> and then call: >>>>>> >>>>>> LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so ${JDK_DIR}/bin/java >>>>>> -XX:NativeMemoryTracking=detail >>>>>> >>>>>> Example: quarkus with "third-party code" injected that leaks >>>>>> periodically [5]: >>>>>> >>>>>> LEAK_MALLOC=1 LEAK_MMAP=1 LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so >>>>>> ${JDK_DIR}/bin/java -agentpath:/shared/projects/jvmti-leak/leaker.so >>>>>> -XX:NativeMemoryTracking=detail -jar ./quarkus-profiling-workshop/ >>>>>> target/quarkus-app/quarkus-run.jar >>>>>> >>>>>> In Summary mode, we see the slowly growing leaks: >>>>>> >>>>>> -External (via interposition) (reserved=82216KB, committed=82216KB) >>>>>> (malloc=81588KB #585) (at peak) >>>>>> (mmap: reserved=628KB, committed=628KB, >>>>>> at peak) >>>>>> >>>>>> >>>>>> and in Detail mode, their call stacks: >>>>>> >>>>>> [0x00007ff067ee7000 - 0x00007ff067ee8000] reserved and committed 4KB >>>>>> for External (via interposition) from >>>>>> [0x00007ff067ef5056]the_mmap(void*, unsigned long, int, int, int, >>>>>> long)+0x66 in libjnmt.so >>>>>> [0x00007ff067ef5781]mmap+0x71 in libjnmt.so >>>>>> [0x00007ff067ee955a]leak_mmap+0x3f in leaker.so >>>>>> [0x00007ff067ee95b1]leakleak+0x1c in leaker.so >>>>>> [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so >>>>>> [0x00007ff067ee95db]leakabit+0x12 in leaker.so >>>>>> [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so >>>>>> >>>>>> >>>>>> [0x00007ff067ef5166]the_malloc(unsigned long)+0x106 in libjnmt.so >>>>>> [0x00007ff067ee94ae]do_malloc+0xb8 in leaker.so >>>>>> [0x00007ff067ee9518]leak_malloc+0x20 in leaker.so >>>>>> [0x00007ff067ee95a7]leakleak+0x12 in leaker.so >>>>>> [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so >>>>>> [0x00007ff067ee95db]leakabit+0x12 in leaker.so >>>>>> [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so >>>>>> (malloc=17679KB type=External (via >>>>>> interposition) #34) (at peak) >>>>>> >>>>>> --- >>>>>> >>>>>> What about MEMFLAGS? >>>>>> >>>>>> The prototype does not extend MEMFLAGS apart from introducing a new >>>>>> "External" category that tracks allocations done via interposition. The >>>>>> question of MEMFLAGS - in particular, opening it up to outside extension - >>>>>> has been contentious. It is orthogonal to this proposal - nice but not >>>>>> required. >>>>>> >>>>>> This proposal makes external allocations visible under the new >>>>>> "External" tag: >>>>>> - in NMT summary mode, we only have the "External" total, which is >>>>>> already useful even as a lump sum: it shows the footprint non-hotspot >>>>>> libraries contribute to RSS. An RSS increase that is reflected neither by >>>>>> hotspot allocations nor by "External" can only stem from a select few >>>>>> places, e.g. from libc malloc retention. >>>>>> - In NMT detail mode, this proposal shows us the call stacks to >>>>>> foreign call sites, pinpointing at least the libraries involved. >>>>>> >>>>>> -- >>>>>> >>>>>> What do you think, does this make sense? >>>>>> >>>>>> Thanks, Thomas >>>>>> >>>>>> >>>>>> [1] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer >>>>>> [2] >>>>>> https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html >>>>>> [3] https://github.com/tstuefe/jdk/tree/libjnmt >>>>>> [4] https://bugs.openjdk.org/browse/JDK-8157023 >>>>>> [5] https://github.com/tstuefe/jvmti_leak >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From numeralnathan at gmail.com Tue Dec 5 18:04:08 2023 From: numeralnathan at gmail.com (Nathan Reynolds) Date: Tue, 5 Dec 2023 10:04:08 -0800 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: References: <521ae235-c03a-4b16-ae11-2bf298120d8a@oracle.com> Message-ID: Can we have the native memory allocations push JFR events? This would only happen when enabled. This would make native memory allocation analysis very easy to do in Mission Control. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Dec 6 05:44:53 2023 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Dec 2023 15:44:53 +1000 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: <2A961D30-BD87-43CE-99F7-BFA33E98D040@sap.com> References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> <2A961D30-BD87-43CE-99F7-BFA33E98D040@sap.com> Message-ID: <67627a65-5509-4900-ad55-ebc2021c790f@oracle.com> On 5/12/2023 9:00 pm, Lindenmaier, Goetz wrote: > Hi Magnus, > > There is > https://openjdk.org/jeps/449 > > > Deprecate the Windows 32-bit x86 Port for Removal > > > I guess we need another JEP to remove it. I don't think the removal needs a JEP. But it does need someone prepared to do the actual work to remove it. Something we could consider for JDK 23 for sure though. David ----- > (SAP does not need the port.) > > Best regards, > ? Goetz. > > > >> On 5. Dec 2023, at 11:55, Magnus Ihse Bursie >> wrote: >> >> I just built windows-x86, and noticed that the build is broken: >> >> src\hotspot\share\prims\downcallLinker.cpp(36): error C2373: >> 'DowncallLinker::capture_state': redefinition; different type modifiers >> >> I think this is most likely caused by JDK-8254693, which was >> integrated three weeks ago. If no-one has discovered this, or bothered >> to fix it, maybe that is the signal we need to decide to actually stop >> pretending that windows-x86 is something we can build for, and just >> remove any remaining windows-x86 code? >> >> /Magnus >> >> > From thomas.stuefe at gmail.com Wed Dec 6 08:43:58 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 6 Dec 2023 09:43:58 +0100 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: References: <521ae235-c03a-4b16-ae11-2bf298120d8a@oracle.com> Message-ID: On Tue, Dec 5, 2023 at 7:04?PM Nathan Reynolds wrote: > Can we have the native memory allocations push JFR events? This would > only happen when enabled. This would make native memory allocation > analysis very easy to do in Mission Control. > Technically, nothing is preventing us from doing so; I'd be worried about the overhead though when doing this for every malloc. mmap is probably less of a problem. At the moment, NMT events are send periodically; one could add a threshold-based approach (whenever we reach +1M in any category), but that would give you only sporadic call stacks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tstuefe at redhat.com Wed Dec 6 08:53:36 2023 From: tstuefe at redhat.com (Thomas Stuefe) Date: Wed, 6 Dec 2023 09:53:36 +0100 Subject: Status 2023-12-06 Message-ID: - Continued work on Changes for Lilliput in Metaspace - Posted NMT interposition library proposal [1], following discussion - Implemented RssLimit, a way to forestall and analyze OOM killer situations [2] - Fosdem preparation [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008491.html [2] https://github.com/openjdk/jdk/pull/16938 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tstuefe at redhat.com Wed Dec 6 09:03:10 2023 From: tstuefe at redhat.com (Thomas Stuefe) Date: Wed, 6 Dec 2023 10:03:10 +0100 Subject: Status 2023-12-06 In-Reply-To: References: Message-ID: Please ignore. Thank you. On Wed, Dec 6, 2023 at 9:53?AM Thomas Stuefe wrote: > > - Continued work on Changes for Lilliput in Metaspace > > - Posted NMT interposition library proposal [1], following discussion > > - Implemented RssLimit, a way to forestall and analyze OOM killer > situations [2] > > - Fosdem preparation > > [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008491.html > [2] https://github.com/openjdk/jdk/pull/16938 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rehn at rivosinc.com Wed Dec 6 10:01:49 2023 From: rehn at rivosinc.com (Robbin Ehn) Date: Wed, 6 Dec 2023 11:01:49 +0100 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: References: Message-ID: Hi Thomas, cool! Yea, this solves many problems folks have in the wild. I'd like the entire NMT to move out of libjvm.so and be a launcher + separate lib thingy :) That would make classifying a bit of hassle. Anyways, maybe I'm reading things wrong, but it seems like with this, even free() is serialized in the entire process? (the_free() + CriticalSection) It seems like we need to avoid serializing as much as possible to not be the bottleneck? Have you done any benchmarking? Or do you consider this just a functionally POC? Also doing the callbacks outside of the CriticalSection is less-error prone, so I would suggest that. Thanks, Robbin On Fri, Dec 1, 2023 at 6:32?PM Thomas Stuefe wrote: > > Hi, community, > > I experimented with extending Native Memory Tracking across the whole process. I want to share my findings and propose a new JDK feature to allow us to do that. > > TL;DR > > Proposed is a "native memory interposition library" shipped with the JDK that would intercept all native memory calls from everywhere and redirect them to NMT. > > Motivation: > > NMT is very useful but limited in its coverage. It only covers Hotspot and a select few sites from the JDK. Most of the JDK, third-party native code, and system libraries are not covered. This is a large hole in our observability. I have seen people do (and done myself! eg [1]) strange and weird things to hunt memory leaks in native code. This is especially tricky in locked-down customer scenarios. > > But NMT is a capable tracker. We could use it for much more than just tracking Hotspot. > > In the past, developers have attempted to extend NMT instrumentation over parts of the JDK (e.g. [2]), which met resistance from Oracle. This is understandable: a naive extension would require libraries to link against the libjvm and instrument their coding. That introduces new dependencies nobody wants. > > --- > > I propose a different way that works without instrumenting any caller code. I hope this proposal proves less controversial than brute-force NMT instrumentation of the JDK. And it would allow introspection of non-JDK parts too. > > We could ship an interception library (a "libjnmt.so") within the JDK. That library, if preloaded, would redirect native memory requests to NMT. A customer who wants to analyze the native memory footprint of its apps could start the JVM with LD_PRELOAD=libjnmt and then use NMT for introspection. > > Oracle and we continuously improve NMT; extending its reach across the whole process would leverage that investment nicely. > > It also meshes well with other improvements. For example, we report NMT numbers via JFR since [4] - with interposition, we could now expose third-party native allocations via JFR. The new jcmd "System.map" would automatically show memory mappings from outside Hotspot. There is a precedent (libjsig), so shipping interposition libraries is not that strange. > > --- > > I have a Linux-based POC that works and looks promising [3]. With that prototype, I can see: > > - allocations from the JDK - e.g., now I finally see mapped byte buffers. > - allocations from third-party user code > - most allocations from system libraries, e.g., from the system zlib > - allocations via the new FFI interface > > The prototype tracks both mmap and malloc. Technically, the tricky part was to handle the initialization window: being able to correctly handle allocations starting at the process C++ initialization while dynamically handing over allocations to the libjvm once it is loaded and NMT is initialized. Another tricky problem was to prevent circularities stemming from call intercepting. The prototype solves these problems and is already stable enough to be used. > > Note that the patch is not complex or large. Some small interaction with the JVM is needed, though, so this cannot be done just with an outside library. > > The prototype was developed and tested on Linux x64 and with glibc 2.31. It seems stable so far, but of course, the work is in an early stage, and bugs may exist. If you want to play with the prototype, build it [3] and then call: > > LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so ${JDK_DIR}/bin/java -XX:NativeMemoryTracking=detail > > Example: quarkus with "third-party code" injected that leaks periodically [5]: > > LEAK_MALLOC=1 LEAK_MMAP=1 LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so ${JDK_DIR}/bin/java -agentpath:/shared/projects/jvmti-leak/leaker.so -XX:NativeMemoryTracking=detail -jar ./quarkus-profiling-workshop/target/quarkus-app/quarkus-run.jar > > In Summary mode, we see the slowly growing leaks: > > -External (via interposition) (reserved=82216KB, committed=82216KB) > (malloc=81588KB #585) (at peak) > (mmap: reserved=628KB, committed=628KB, at peak) > > > and in Detail mode, their call stacks: > > [0x00007ff067ee7000 - 0x00007ff067ee8000] reserved and committed 4KB for External (via interposition) from > [0x00007ff067ef5056]the_mmap(void*, unsigned long, int, int, int, long)+0x66 in libjnmt.so > [0x00007ff067ef5781]mmap+0x71 in libjnmt.so > [0x00007ff067ee955a]leak_mmap+0x3f in leaker.so > [0x00007ff067ee95b1]leakleak+0x1c in leaker.so > [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so > [0x00007ff067ee95db]leakabit+0x12 in leaker.so > [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so > > > [0x00007ff067ef5166]the_malloc(unsigned long)+0x106 in libjnmt.so > [0x00007ff067ee94ae]do_malloc+0xb8 in leaker.so > [0x00007ff067ee9518]leak_malloc+0x20 in leaker.so > [0x00007ff067ee95a7]leakleak+0x12 in leaker.so > [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so > [0x00007ff067ee95db]leakabit+0x12 in leaker.so > [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so > (malloc=17679KB type=External (via interposition) #34) (at peak) > > --- > > What about MEMFLAGS? > > The prototype does not extend MEMFLAGS apart from introducing a new "External" category that tracks allocations done via interposition. The question of MEMFLAGS - in particular, opening it up to outside extension - has been contentious. It is orthogonal to this proposal - nice but not required. > > This proposal makes external allocations visible under the new "External" tag: > - in NMT summary mode, we only have the "External" total, which is already useful even as a lump sum: it shows the footprint non-hotspot libraries contribute to RSS. An RSS increase that is reflected neither by hotspot allocations nor by "External" can only stem from a select few places, e.g. from libc malloc retention. > - In NMT detail mode, this proposal shows us the call stacks to foreign call sites, pinpointing at least the libraries involved. > > -- > > What do you think, does this make sense? > > Thanks, Thomas > > > [1] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer > [2] https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html > [3] https://github.com/tstuefe/jdk/tree/libjnmt > [4] https://bugs.openjdk.org/browse/JDK-8157023 > [5] https://github.com/tstuefe/jvmti_leak From sxa at redhat.com Wed Dec 6 10:22:31 2023 From: sxa at redhat.com (Stewart Addison) Date: Wed, 6 Dec 2023 10:22:31 +0000 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: Hi Magnus, I put in a fix for another Win32 build break recently but hadn't realised it was broken again - ref https://bugs.openjdk.org/browse/JDK-8319958. Since the Win32 port is currently only deprecated I was already wondering if we should go for the simple solution of having some github PR checks added for Win32 along with the other platforms (Obviously it would need the parameter to enable deprecated ports) as I feel this would help prevent things being merged and subsequently backported that break things. In the case of the one I fixed the PR that caused the build failure also got backported to the JDK17 codebase - for which there are no plans to deprecate - so potentially trapping things earlier would prevent such problems seeping through to earlier versions requiring subsequent remedial patches. I think there's a discussion to be had here regarding 32-bit support in general going forward - I have a specific question about arm32 and whether anyone is actively maintaining that one but perhaps that's a matter for another thread unless anyone wants to jump in and say they'll be keeping arm32 alive in the codebase. Regards, Stewart... On Tue, 5 Dec 2023 at 10:56, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > I just built windows-x86, and noticed that the build is broken: > > src\hotspot\share\prims\downcallLinker.cpp(36): error C2373: > 'DowncallLinker::capture_state': redefinition; different type modifiers > > I think this is most likely caused by JDK-8254693, which was integrated > three weeks ago. If no-one has discovered this, or bothered to fix it, > maybe that is the signal we need to decide to actually stop pretending > that windows-x86 is something we can build for, and just remove any > remaining windows-x86 code? > > /Magnus > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Dec 6 11:54:03 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Dec 2023 11:54:03 +0000 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: On 06/12/2023 10:22, Stewart Addison wrote: > Hi Magnus, > > I put in a fix for another Win32 build break recently but hadn't > realised it was broken again - ref > https://bugs.openjdk.org/browse/JDK-8319958. Since the Win32 port is > currently only deprecated I was already wondering if we should go for > the simple solution of having some github PR checks added for Win32 > along with the other platforms (Obviously it would need the parameter > to enable deprecated ports) as I feel this would help prevent things > being merged and subsequently backported that break things. I assume this would put a tax on everyone, the testing in GHA is already a bit noisy. Seems like it would be better to remove the port, I think it would be useful to hear from George Adams and Bruno Borges to know if they plan to follow-up JEP 449 and do the next step. -Alan From goetz.lindenmaier at sap.com Wed Dec 6 12:13:48 2023 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 6 Dec 2023 12:13:48 +0000 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: +1 > -----Original Message----- > From: jdk-dev On Behalf Of Alan Bateman > Sent: Wednesday, December 6, 2023 12:54 PM > To: Stewart Addison ; Magnus Ihse Bursie > > Cc: jdk-dev at openjdk.org > Subject: Re: Windows-x86 (32-bit) build is broken. Time to retire it? > > On 06/12/2023 10:22, Stewart Addison wrote: > > Hi Magnus, > > > > I put in a fix for another Win32 build break recently but hadn't > > realised it was broken again - ref > > https://bugs.openjdk.org/browse/JDK-8319958. Since the Win32 port is > > currently only deprecated I was already wondering if we should go for > > the simple solution of having some github PR checks added for Win32 > > along with the other platforms (Obviously it would need the parameter > > to enable deprecated ports) as I feel this would help prevent things > > being merged and subsequently backported that break things. > > I assume this would put a tax on everyone, the testing in GHA is already > a bit noisy. Seems like it would be better to remove the port, I think > it would be useful to hear from George Adams and Bruno Borges to know if > they plan to follow-up JEP 449 and do the next step. > > -Alan From thomas.stuefe at gmail.com Wed Dec 6 13:21:08 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 6 Dec 2023 14:21:08 +0100 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: References: Message-ID: Hi Robbin, On Wed, Dec 6, 2023 at 12:29?PM Robbin Ehn wrote: > Hi Thomas, cool! > > Yea, this solves many problems folks have in the wild. > > I'd like the entire NMT to move out of libjvm.so and be a launcher + > separate lib thingy :) > That would make classifying a bit of hassle. > > Anyways, maybe I'm reading things wrong, but it seems like with this, > even free() is serialized in the entire process? (the_free() + > CriticalSection) > It seems like we need to avoid serializing as much as possible to not > be the bottleneck? > Have you done any benchmarking? Or do you consider this just a > functionally POC? > > Yes, this was just for a functional POC. I first wanted to see if I get it running. We probably should be able to get rid of the mutex and make the logic lock free. > Also doing the callbacks outside of the CriticalSection is less-error > prone, so I would suggest that. > > Sure thing. And thanks for the positive feedback! > Thanks, Robbin > > Cheers, Thomas > > On Fri, Dec 1, 2023 at 6:32?PM Thomas Stuefe wrote: > > > > Hi, community, > > > > I experimented with extending Native Memory Tracking across the whole > process. I want to share my findings and propose a new JDK feature to allow > us to do that. > > > > TL;DR > > > > Proposed is a "native memory interposition library" shipped with the JDK > that would intercept all native memory calls from everywhere and redirect > them to NMT. > > > > Motivation: > > > > NMT is very useful but limited in its coverage. It only covers Hotspot > and a select few sites from the JDK. Most of the JDK, third-party native > code, and system libraries are not covered. This is a large hole in our > observability. I have seen people do (and done myself! eg [1]) strange and > weird things to hunt memory leaks in native code. This is especially tricky > in locked-down customer scenarios. > > > > But NMT is a capable tracker. We could use it for much more than just > tracking Hotspot. > > > > In the past, developers have attempted to extend NMT instrumentation > over parts of the JDK (e.g. [2]), which met resistance from Oracle. This is > understandable: a naive extension would require libraries to link against > the libjvm and instrument their coding. That introduces new dependencies > nobody wants. > > > > --- > > > > I propose a different way that works without instrumenting any caller > code. I hope this proposal proves less controversial than brute-force NMT > instrumentation of the JDK. And it would allow introspection of non-JDK > parts too. > > > > We could ship an interception library (a "libjnmt.so") within the JDK. > That library, if preloaded, would redirect native memory requests to NMT. A > customer who wants to analyze the native memory footprint of its apps could > start the JVM with LD_PRELOAD=libjnmt and then use NMT for introspection. > > > > Oracle and we continuously improve NMT; extending its reach across the > whole process would leverage that investment nicely. > > > > It also meshes well with other improvements. For example, we report NMT > numbers via JFR since [4] - with interposition, we could now expose > third-party native allocations via JFR. The new jcmd "System.map" would > automatically show memory mappings from outside Hotspot. There is a > precedent (libjsig), so shipping interposition libraries is not that > strange. > > > > --- > > > > I have a Linux-based POC that works and looks promising [3]. With that > prototype, I can see: > > > > - allocations from the JDK - e.g., now I finally see mapped byte buffers. > > - allocations from third-party user code > > - most allocations from system libraries, e.g., from the system zlib > > - allocations via the new FFI interface > > > > The prototype tracks both mmap and malloc. Technically, the tricky part > was to handle the initialization window: being able to correctly handle > allocations starting at the process C++ initialization while dynamically > handing over allocations to the libjvm once it is loaded and NMT is > initialized. Another tricky problem was to prevent circularities stemming > from call intercepting. The prototype solves these problems and is already > stable enough to be used. > > > > Note that the patch is not complex or large. Some small interaction with > the JVM is needed, though, so this cannot be done just with an outside > library. > > > > The prototype was developed and tested on Linux x64 and with glibc 2.31. > It seems stable so far, but of course, the work is in an early stage, and > bugs may exist. If you want to play with the prototype, build it [3] and > then call: > > > > LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so ${JDK_DIR}/bin/java > -XX:NativeMemoryTracking=detail > > > > Example: quarkus with "third-party code" injected that leaks > periodically [5]: > > > > LEAK_MALLOC=1 LEAK_MMAP=1 LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so > ${JDK_DIR}/bin/java -agentpath:/shared/projects/jvmti-leak/leaker.so > -XX:NativeMemoryTracking=detail -jar > ./quarkus-profiling-workshop/target/quarkus-app/quarkus-run.jar > > > > In Summary mode, we see the slowly growing leaks: > > > > -External (via interposition) (reserved=82216KB, committed=82216KB) > > (malloc=81588KB #585) (at peak) > > (mmap: reserved=628KB, committed=628KB, at > peak) > > > > > > and in Detail mode, their call stacks: > > > > [0x00007ff067ee7000 - 0x00007ff067ee8000] reserved and committed 4KB for > External (via interposition) from > > [0x00007ff067ef5056]the_mmap(void*, unsigned long, int, int, int, > long)+0x66 in libjnmt.so > > [0x00007ff067ef5781]mmap+0x71 in libjnmt.so > > [0x00007ff067ee955a]leak_mmap+0x3f in leaker.so > > [0x00007ff067ee95b1]leakleak+0x1c in leaker.so > > [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so > > [0x00007ff067ee95db]leakabit+0x12 in leaker.so > > [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so > > > > > > [0x00007ff067ef5166]the_malloc(unsigned long)+0x106 in libjnmt.so > > [0x00007ff067ee94ae]do_malloc+0xb8 in leaker.so > > [0x00007ff067ee9518]leak_malloc+0x20 in leaker.so > > [0x00007ff067ee95a7]leakleak+0x12 in leaker.so > > [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so > > [0x00007ff067ee95db]leakabit+0x12 in leaker.so > > [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so > > (malloc=17679KB type=External (via > interposition) #34) (at peak) > > > > --- > > > > What about MEMFLAGS? > > > > The prototype does not extend MEMFLAGS apart from introducing a new > "External" category that tracks allocations done via interposition. The > question of MEMFLAGS - in particular, opening it up to outside extension - > has been contentious. It is orthogonal to this proposal - nice but not > required. > > > > This proposal makes external allocations visible under the new > "External" tag: > > - in NMT summary mode, we only have the "External" total, which is > already useful even as a lump sum: it shows the footprint non-hotspot > libraries contribute to RSS. An RSS increase that is reflected neither by > hotspot allocations nor by "External" can only stem from a select few > places, e.g. from libc malloc retention. > > - In NMT detail mode, this proposal shows us the call stacks to foreign > call sites, pinpointing at least the libraries involved. > > > > -- > > > > What do you think, does this make sense? > > > > Thanks, Thomas > > > > > > [1] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer > > [2] > https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html > > [3] https://github.com/tstuefe/jdk/tree/libjnmt > > [4] https://bugs.openjdk.org/browse/JDK-8157023 > > [5] https://github.com/tstuefe/jvmti_leak > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sxa at redhat.com Wed Dec 6 13:22:56 2023 From: sxa at redhat.com (Stewart Addison) Date: Wed, 6 Dec 2023 13:22:56 +0000 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: > I assume this would put a tax on everyone, the testing in GHA is already > a bit noisy. Seems like it would be better to remove the port I can understand that, however we should bear in mind that with JDK<=17 being supported regardless, if it gets removed in a later version there is almost certainly a much higher risk of backports "breaking" the LTS streams (as it did recently) compared to other platforms without it being caught prior to integration, so it might be good to catch it earlier in the backport cycle (or maybe as a middle ground just add such checks to JDK<=17) regardless of whether it gets removed in >=21. Regards, Stewart... -- On Wed, 6 Dec 2023 at 11:54, Alan Bateman wrote: > On 06/12/2023 10:22, Stewart Addison wrote: > > Hi Magnus, > > > > I put in a fix for another Win32 build break recently but hadn't > > realised it was broken again - ref > > https://bugs.openjdk.org/browse/JDK-8319958. Since the Win32 port is > > currently only deprecated I was already wondering if we should go for > > the simple solution of having some github PR checks added for Win32 > > along with the other platforms (Obviously it would need the parameter > > to enable deprecated ports) as I feel this would help prevent things > > being merged and subsequently backported that break things. > > I assume this would put a tax on everyone, the testing in GHA is already > a bit noisy. Seems like it would be better to remove the port, I think > it would be useful to hear from George Adams and Bruno Borges to know if > they plan to follow-up JEP 449 and do the next step. > > -Alan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Wed Dec 6 13:40:35 2023 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 6 Dec 2023 13:40:35 +0000 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: <67627a65-5509-4900-ad55-ebc2021c790f@oracle.com> References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> <2A961D30-BD87-43CE-99F7-BFA33E98D040@sap.com> <67627a65-5509-4900-ad55-ebc2021c790f@oracle.com> Message-ID: <20231206084033.683793079@eggemoggin.niobe.net> 2023/12/6 0:44:53 -0500, david.holmes at oracle.com: > On 5/12/2023 9:00 pm, Lindenmaier, Goetz wrote: >> There is >> https://openjdk.org/jeps/449 >> >> Deprecate the Windows 32-bit x86 Port for Removal >> >> I guess we need another JEP to remove it. > > I don't think the removal needs a JEP. But it does need someone prepared > to do the actual work to remove it. Something we could consider for JDK > 23 for sure though. Ports come and go over time. They are introduced via JEPs, and so they should be deprecated-for-removal via JEPs and then removed via JEPs. Fortunately, a JEP to remove the Windows/x86 port will be trivial. - Mark From goetz.lindenmaier at sap.com Wed Dec 6 13:44:33 2023 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 6 Dec 2023 13:44:33 +0000 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: Hi, Fixing issues on a non-standard platform is the task of the maintainers of that platform. Others cannot be expected to have a build environment around to assure correctness. If an issue pops up in the GHA tests, it needs to be fixed adhoc, else all other work is hindered. If the maintainers of a platform are not able to assure that that happens, the platform should not be tested in GHA. And there are obviously very few people looking at the 32-bit windows platform, else it would not break in head all the time. Best regards, Goetz. From: jdk-dev On Behalf Of Stewart Addison Sent: Wednesday, December 6, 2023 2:23 PM To: Alan Bateman Cc: Magnus Ihse Bursie ; jdk-dev at openjdk.org Subject: Re: Windows-x86 (32-bit) build is broken. Time to retire it? Some people who received this message don't often get email from sxa at redhat.com. Learn why this is important > I assume this would put a tax on everyone, the testing in GHA is already > a bit noisy. Seems like it would be better to remove the port I can understand that, however we should bear in mind that with JDK<=17 being supported regardless, if it gets removed in a later version there is almost certainly a much higher risk of backports "breaking" the LTS streams (as it did recently) compared to other platforms without it being caught prior to integration, so it might be good to catch it earlier in the backport cycle (or maybe as a middle ground just add such checks to JDK<=17) regardless of whether it gets removed in >=21. Regards, Stewart... -- On Wed, 6 Dec 2023 at 11:54, Alan Bateman > wrote: On 06/12/2023 10:22, Stewart Addison wrote: > Hi Magnus, > > I put in a fix for another Win32 build break recently but hadn't > realised it was broken again - ref > https://bugs.openjdk.org/browse/JDK-8319958. Since the Win32 port is > currently only deprecated I was already wondering if we should go for > the simple solution of having some github PR checks added for Win32 > along with the other platforms (Obviously it would need the parameter > to enable deprecated ports) as I feel this would help prevent things > being merged and subsequently backported that break things. I assume this would put a tax on everyone, the testing in GHA is already a bit noisy. Seems like it would be better to remove the port, I think it would be useful to hear from George Adams and Bruno Borges to know if they plan to follow-up JEP 449 and do the next step. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sxa at redhat.com Wed Dec 6 17:13:53 2023 From: sxa at redhat.com (Stewart Addison) Date: Wed, 6 Dec 2023 17:13:53 +0000 Subject: Is 32-bit Arm support being actively maintained in JDK21 and head? Message-ID: Hi everyone, This is a bit of a follow up to the discussion on Windows 32-bit builds in the jdk-dev thread from yesterday, but is anyone currently actively maintaining the 32-bit Arm code for the JDK21 and HEAD streams? Noting that unlike Win32, there are GitHub PR tests for Arm32 so failures are more likely to get noticed than for Win32. Eclipse Temurin has not yet released a version of JDK21 but we have had a user ask about whether we will do so (issue link ), since we have done so for previous LTS releases. As input to making a decision on this it would be helpful to understand if the platform has a strong support story upstream for the latest release streams which would be important to us to be able to maintain such a release, or if it is likely to go the same way as Win32 i.e. that it will suffer failures over time which would make it harder to support it along with the other platform ports. The wiki at https://wiki.openjdk.org/display/hotspot/ports lists Boris Ulasevich and Sergey Nazarkin as maintainers, so I've explicitly copied both on this email but I'm looking to see if there is still active maintenance going on with the Arm32 port from any members of the openjdk community for the newer codebases, or whether there is any possibility of it being deprecated at some point like Win32. Thanks in advance, Stewart... -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksei.voitylov at bell-sw.com Wed Dec 6 18:54:01 2023 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Wed, 6 Dec 2023 21:54:01 +0300 Subject: Is 32-bit Arm support being actively maintained in JDK21 and head? In-Reply-To: References: Message-ID: The definition of "actively maintained" may vary, depending on who you ask. I'd rather say we are keeping the lights on in head. I recently fixed a couple of issues related to ARM32, namely 8315940, 8316879. There is more in the pipeline following 8301997/8320278 (the full fix is being tested now, will post it soon). It's hard to answer on behalf of all maintainers, but the intent from BellSoft end is to continue to keep the lights on for now. Will there be time when we abandon this port? Definitely. But I don't think it has come just yet. If you are willing to help with this effort, you are warmly welcome. -Aleksei On Wed, 6 Dec 2023 at 20:14, Stewart Addison wrote: > Hi everyone, > > This is a bit of a follow up to the discussion on Windows 32-bit builds in > the jdk-dev thread from yesterday, but is anyone currently actively > maintaining the 32-bit Arm code for the JDK21 and HEAD streams? Noting that > unlike Win32, there are GitHub PR tests for Arm32 so failures are more > likely to get noticed than for Win32. > > Eclipse Temurin has not yet released a version of JDK21 but we have had a > user ask about whether we will do so (issue link > ), since we have > done so for previous LTS releases. As input to making a decision on this it > would be helpful to understand if the platform has a strong support story > upstream for the latest release streams which would be important to us to > be able to maintain such a release, or if it is likely to go the same way > as Win32 i.e. that it will suffer failures over time which would make it > harder to support it along with the other platform ports. > > The wiki at https://wiki.openjdk.org/display/hotspot/ports lists Boris > Ulasevich and Sergey Nazarkin as maintainers, so I've explicitly copied > both on this email but I'm looking to see if there is still active > maintenance going on with the Arm32 port from any members of the openjdk > community for the newer codebases, or whether there is any possibility of > it being deprecated at some point like Win32. > > Thanks in advance, > > Stewart... > -- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjx001202 at gmail.com Wed Dec 6 19:04:25 2023 From: zjx001202 at gmail.com (Glavo) Date: Thu, 7 Dec 2023 03:04:25 +0800 Subject: A new JPMS-friendly Java program packaging format Message-ID: Hey everyone, Recently, I have been busy developing a new JPMS-friendly Java program packaging format: JApp (https://github.com/Glavo/japp). JApp is intended as a better alternative to shadow jar (fat jar). Users need to specify the module path and classpath when creating a JApp file. Resources in all module path/classpath entries (JAR or directory) are packaged into a single japp file, but unlike shadow jars, japp isolates resources from different module path/classpath entries. For example, we can create a japp file with the following command: japp create -o myapp.japp \ --module-path commons-lang3-3.14.0.jar:commons-io-2.15.1.jar \ --classpath guava-32.1.3-jre.jar:gson-2.10.1.jar This will create a japp file named `myjapp.japp` that contains resources from four jar files. At runtime, the URIs for the resources from the four JAR files each look like this: japp:/modules/org.apache.commons.lang3/org/apache/commons/lang3/ObjectUtils.class japp:/modules/org.apache.commons.io/org/apache/commons/io/IOUtils.class japp:/classpath/guava-32.1.3-jre.jar/com/google/common/collect/Multimap.class japp:/classpath/gson-2.10.1.jar/com/google/gson/Gson.class At runtime, each entry in the module path and classpath is independent, just like passing the `--classpath`/`--module-path` option directly to the `java` command. By sharing the class constant pool, using zstd as the compression method, and compressing the file metadata, japp files are generally smaller than shadow jars. JApp files also support specifying some conditions, such as requirements for the Java version. JApp selects the Java runtime to use to run the program based on these conditions. Here is its GitHub repository, for more features and detailed instructions please refer to the README: https://github.com/Glavo/japp Now that the basic features of JApp are complete, I'm sharing it here in the hope that more people will try it and give feedback. Thank you to everyone who is willing to read this email! Glavo -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjx001202 at gmail.com Wed Dec 6 19:12:55 2023 From: zjx001202 at gmail.com (Glavo) Date: Thu, 7 Dec 2023 03:12:55 +0800 Subject: A new JPMS-friendly Java program packaging format In-Reply-To: References: Message-ID: Sorry, there were some formatting errors during pasting, please excuse me. Glavo On Thu, Dec 7, 2023 at 3:04?AM Glavo wrote: > Hey everyone, > > Recently, I have been busy developing a new JPMS-friendly Java program > packaging format: JApp (https://github.com/Glavo/japp). > > JApp is intended as a better alternative to shadow jar (fat jar). > Users need to specify the module path and classpath when creating a JApp > file. > Resources in all module path/classpath entries (JAR or directory) are > packaged into a single japp file, > but unlike shadow jars, japp isolates resources from different module > path/classpath entries. > > For example, we can create a japp file with the following command: > > japp create -o myapp.japp \ > --module-path commons-lang3-3.14.0.jar:commons-io-2.15.1.jar \ > --classpath guava-32.1.3-jre.jar:gson-2.10.1.jar > > > This will create a japp file named `myjapp.japp` that contains resources > from four jar files. > At runtime, the URIs for the resources from the four JAR files each look > like this: > > > japp:/modules/org.apache.commons.lang3/org/apache/commons/lang3/ObjectUtils.class > japp:/modules/org.apache.commons.io/org/apache/commons/io/IOUtils.class > > japp:/classpath/guava-32.1.3-jre.jar/com/google/common/collect/Multimap.class > japp:/classpath/gson-2.10.1.jar/com/google/gson/Gson.class > At runtime, each entry in the module path and classpath is independent, > just like passing the `--classpath`/`--module-path` option directly to the > `java` command. > > By sharing the class constant pool, using zstd as the compression method, > and > compressing the file metadata, japp files are generally smaller than > shadow jars. > > JApp files also support specifying some conditions, such as requirements > for the Java version. > JApp selects the Java runtime to use to run the program based on these > conditions. > > Here is its GitHub repository, for more features and detailed instructions > please refer to the README: > > https://github.com/Glavo/japp > > Now that the basic features of JApp are complete, I'm sharing it here in > the hope > that more people will try it and give feedback. > > Thank you to everyone who is willing to read this email! > > Glavo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From numeralnathan at gmail.com Wed Dec 6 20:06:27 2023 From: numeralnathan at gmail.com (Nathan Reynolds) Date: Wed, 6 Dec 2023 12:06:27 -0800 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: References: <521ae235-c03a-4b16-ae11-2bf298120d8a@oracle.com> Message-ID: JFR has some settings to enable allocation tracking in the Java heap. This isn't enabled by default because it can have some performance impact. I am not sure how it is done without killing performance. Perhaps, we can do something similar for native memory allocations. Also, I suspect that allocations to native memory is much slower than to allocations to Java heap. So, the overhead of tracking native memory allocations should be less than tracking Java allocations. On Wed, Dec 6, 2023 at 12:44?AM Thomas St?fe wrote: > > On Tue, Dec 5, 2023 at 7:04?PM Nathan Reynolds > wrote: > >> Can we have the native memory allocations push JFR events? This would >> only happen when enabled. This would make native memory allocation >> analysis very easy to do in Mission Control. >> > > Technically, nothing is preventing us from doing so; I'd be worried about > the overhead though when doing this for every malloc. mmap is probably less > of a problem. > > At the moment, NMT events are send periodically; one could add a > threshold-based approach (whenever we reach +1M in any category), but that > would give you only sporadic call stacks. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brice.dutheil at gmail.com Wed Dec 6 22:11:57 2023 From: brice.dutheil at gmail.com (Brice Dutheil) Date: Wed, 6 Dec 2023 23:11:57 +0100 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: References: <521ae235-c03a-4b16-ae11-2bf298120d8a@oracle.com> Message-ID: I would like to see JFR events with a stack as well, but it is maybe too much for an initial implementation? Also there are alternatives for that using async-profiler. -- Brice On Wed, Dec 6, 2023 at 9:06?PM Nathan Reynolds wrote: > JFR has some settings to enable allocation tracking in the Java heap. > This isn't enabled by default because it can have some performance impact. > I am not sure how it is done without killing performance. Perhaps, we can > do something similar for native memory allocations. Also, I suspect that > allocations to native memory is much slower than to allocations to Java > heap. So, the overhead of tracking native memory allocations should be > less than tracking Java allocations. > > On Wed, Dec 6, 2023 at 12:44?AM Thomas St?fe > wrote: > >> >> On Tue, Dec 5, 2023 at 7:04?PM Nathan Reynolds >> wrote: >> >>> Can we have the native memory allocations push JFR events? This would >>> only happen when enabled. This would make native memory allocation >>> analysis very easy to do in Mission Control. >>> >> >> Technically, nothing is preventing us from doing so; I'd be worried about >> the overhead though when doing this for every malloc. mmap is probably less >> of a problem. >> >> At the moment, NMT events are send periodically; one could add a >> threshold-based approach (whenever we reach +1M in any category), but that >> would give you only sporadic call stacks. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brice.dutheil at gmail.com Wed Dec 6 22:15:47 2023 From: brice.dutheil at gmail.com (Brice Dutheil) Date: Wed, 6 Dec 2023 23:15:47 +0100 Subject: Proposal: Extend Native Memory Tracking across the whole process via interposition In-Reply-To: References: Message-ID: Among the intercepted calls did you consider `mprotect`s, which are used to resize a segment. -- Brice On Fri, Dec 1, 2023 at 8:34?PM Thomas Stuefe wrote: > Hi, community, > > I experimented with extending Native Memory Tracking across the whole > process. I want to share my findings and propose a new JDK feature to allow > us to do that. > > TL;DR > > Proposed is a "native memory interposition library" shipped with the JDK > that would intercept all native memory calls from everywhere and redirect > them to NMT. > > Motivation: > > NMT is very useful but limited in its coverage. It only covers Hotspot and > a select few sites from the JDK. Most of the JDK, third-party native code, > and system libraries are not covered. This is a large hole in our > observability. I have seen people do (and done myself! eg [1]) strange and > weird things to hunt memory leaks in native code. This is especially tricky > in locked-down customer scenarios. > > But NMT is a capable tracker. We could use it for much more than just > tracking Hotspot. > > In the past, developers have attempted to extend NMT instrumentation over > parts of the JDK (e.g. [2]), which met resistance from Oracle. This is > understandable: a naive extension would require libraries to link against > the libjvm and instrument their coding. That introduces new dependencies > nobody wants. > > --- > > I propose a different way that works without instrumenting any caller > code. I hope this proposal proves less controversial than brute-force NMT > instrumentation of the JDK. And it would allow introspection of non-JDK > parts too. > > We could ship an interception library (a "libjnmt.so") within the JDK. > That library, if preloaded, would redirect native memory requests to NMT. A > customer who wants to analyze the native memory footprint of its apps could > start the JVM with LD_PRELOAD=libjnmt and then use NMT for introspection. > > Oracle and we continuously improve NMT; extending its reach across the > whole process would leverage that investment nicely. > > It also meshes well with other improvements. For example, we report NMT > numbers via JFR since [4] - with interposition, we could now expose > third-party native allocations via JFR. The new jcmd "System.map" would > automatically show memory mappings from outside Hotspot. There is a > precedent (libjsig), so shipping interposition libraries is not that > strange. > > --- > > I have a Linux-based POC that works and looks promising [3]. With that > prototype, I can see: > > - allocations from the JDK - e.g., now I finally see mapped byte buffers. > - allocations from third-party user code > - most allocations from system libraries, e.g., from the system zlib > - allocations via the new FFI interface > > The prototype tracks both mmap and malloc. Technically, the tricky part > was to handle the initialization window: being able to correctly handle > allocations starting at the process C++ initialization while dynamically > handing over allocations to the libjvm once it is loaded and NMT is > initialized. Another tricky problem was to prevent circularities stemming > from call intercepting. The prototype solves these problems and is already > stable enough to be used. > > Note that the patch is not complex or large. Some small interaction with > the JVM is needed, though, so this cannot be done just with an outside > library. > > The prototype was developed and tested on Linux x64 and with glibc 2.31. > It seems stable so far, but of course, the work is in an early stage, and > bugs may exist. If you want to play with the prototype, build it [3] and > then call: > > LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so ${JDK_DIR}/bin/java > -XX:NativeMemoryTracking=detail > > Example: quarkus with "third-party code" injected that leaks periodically > [5]: > > LEAK_MALLOC=1 LEAK_MMAP=1 LD_PRELOAD=${JDK_DIR}/lib/server/libjnmt.so > ${JDK_DIR}/bin/java -agentpath:/shared/projects/jvmti-leak/leaker.so > -XX:NativeMemoryTracking=detail -jar ./quarkus-profiling-workshop/ > target/quarkus-app/quarkus-run.jar > > In Summary mode, we see the slowly growing leaks: > > -External (via interposition) (reserved=82216KB, committed=82216KB) > (malloc=81588KB #585) (at peak) > (mmap: reserved=628KB, committed=628KB, at > peak) > > > and in Detail mode, their call stacks: > > [0x00007ff067ee7000 - 0x00007ff067ee8000] reserved and committed 4KB for > External (via interposition) from > [0x00007ff067ef5056]the_mmap(void*, unsigned long, int, int, int, > long)+0x66 in libjnmt.so > [0x00007ff067ef5781]mmap+0x71 in libjnmt.so > [0x00007ff067ee955a]leak_mmap+0x3f in leaker.so > [0x00007ff067ee95b1]leakleak+0x1c in leaker.so > [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so > [0x00007ff067ee95db]leakabit+0x12 in leaker.so > [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so > > > [0x00007ff067ef5166]the_malloc(unsigned long)+0x106 in libjnmt.so > [0x00007ff067ee94ae]do_malloc+0xb8 in leaker.so > [0x00007ff067ee9518]leak_malloc+0x20 in leaker.so > [0x00007ff067ee95a7]leakleak+0x12 in leaker.so > [0x00007ff067ee95c6]leakleakleak+0x12 in leaker.so > [0x00007ff067ee95db]leakabit+0x12 in leaker.so > [0x00007ff067ee95f8]leaky_thread+0x1a in leaker.so > (malloc=17679KB type=External (via > interposition) #34) (at peak) > > --- > > What about MEMFLAGS? > > The prototype does not extend MEMFLAGS apart from introducing a new > "External" category that tracks allocations done via interposition. The > question of MEMFLAGS - in particular, opening it up to outside extension - > has been contentious. It is orthogonal to this proposal - nice but not > required. > > This proposal makes external allocations visible under the new "External" > tag: > - in NMT summary mode, we only have the "External" total, which is already > useful even as a lump sum: it shows the footprint non-hotspot libraries > contribute to RSS. An RSS increase that is reflected neither by hotspot > allocations nor by "External" can only stem from a select few places, e.g. > from libc malloc retention. > - In NMT detail mode, this proposal shows us the call stacks to foreign > call sites, pinpointing at least the libraries involved. > > -- > > What do you think, does this make sense? > > Thanks, Thomas > > > [1] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer > [2] > https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html > [3] https://github.com/tstuefe/jdk/tree/libjnmt > [4] https://bugs.openjdk.org/browse/JDK-8157023 > [5] https://github.com/tstuefe/jvmti_leak > -------------- next part -------------- An HTML attachment was scrubbed... URL: From numeralnathan at gmail.com Wed Dec 6 23:29:05 2023 From: numeralnathan at gmail.com (Nathan Reynolds) Date: Wed, 6 Dec 2023 15:29:05 -0800 Subject: A new JPMS-friendly Java program packaging format In-Reply-To: References: Message-ID: Please provide a way to exclude files or packages from a particular Jar. For example, I may not want Multimap.class in the Guava Jar. Is this compatible with Proguard's and Graal VM's to trim fat Jars? Both of these will eliminate unused classes, methods, and fields to reduce the size of the fat Jar. On Wed, Dec 6, 2023 at 3:17?PM Glavo wrote: > Hey everyone, > > Recently, I have been busy developing a new JPMS-friendly Java program > packaging format: JApp (https://github.com/Glavo/japp). > > JApp is intended as a better alternative to shadow jar (fat jar). > Users need to specify the module path and classpath when creating a JApp > file. > Resources in all module path/classpath entries (JAR or directory) are > packaged into a single japp file, > but unlike shadow jars, japp isolates resources from different module > path/classpath entries. > > For example, we can create a japp file with the following command: > > japp create -o myapp.japp \ > --module-path commons-lang3-3.14.0.jar:commons-io-2.15.1.jar \ > --classpath guava-32.1.3-jre.jar:gson-2.10.1.jar > > > This will create a japp file named `myjapp.japp` that contains resources > from four jar files. > At runtime, the URIs for the resources from the four JAR files each look > like this: > > > japp:/modules/org.apache.commons.lang3/org/apache/commons/lang3/ObjectUtils.class > japp:/modules/org.apache.commons.io/org/apache/commons/io/IOUtils.class > > japp:/classpath/guava-32.1.3-jre.jar/com/google/common/collect/Multimap.class > japp:/classpath/gson-2.10.1.jar/com/google/gson/Gson.class > At runtime, each entry in the module path and classpath is independent, > just like passing the `--classpath`/`--module-path` option directly to the > `java` command. > > By sharing the class constant pool, using zstd as the compression method, > and > compressing the file metadata, japp files are generally smaller than > shadow jars. > > JApp files also support specifying some conditions, such as requirements > for the Java version. > JApp selects the Java runtime to use to run the program based on these > conditions. > > Here is its GitHub repository, for more features and detailed instructions > please refer to the README: > > https://github.com/Glavo/japp > > Now that the basic features of JApp are complete, I'm sharing it here in > the hope > that more people will try it and give feedback. > > Thank you to everyone who is willing to read this email! > > Glavo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Thu Dec 7 06:51:48 2023 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Dec 2023 06:51:48 +0000 Subject: Is 32-bit Arm support being actively maintained in JDK21 and head? In-Reply-To: References: Message-ID: Hi, I can not remember arm32 GHA failures in 17 or 11. But without checking I think there were backports dedicated to that platform. So the maintenance fits the needs. It's probably also a platform that just compiles if other linux platforms do so. Win32 might be more fragile there. Another example is Solaris and Sparc in 11. They have only very sporadic developer attention, and there are no GHA tests. Best regards, Goetz. From: jdk-dev On Behalf Of Aleksei Voitylov Sent: Wednesday, December 6, 2023 7:54 PM To: Stewart Addison Cc: jdk-dev at openjdk.org; porters-dev at openjdk.org; boris.ulasevich at bell-sw.com; snazarkin at azul.com Subject: Re: Is 32-bit Arm support being actively maintained in JDK21 and head? The definition of "actively maintained" may vary, depending on who you ask. I'd rather say we are keeping the lights on in head. I recently fixed a couple of issues related to ARM32, namely 8315940, 8316879. There is more in the pipeline following 8301997/8320278 (the full fix is being tested now, will post it soon). It's hard to answer on behalf of all maintainers, but the intent from BellSoft end is to continue to keep the lights on for now. Will there be time when we abandon this port? Definitely. But I don't think it has come just yet. If you are willing to help with this effort, you are warmly welcome. -Aleksei On Wed, 6 Dec 2023 at 20:14, Stewart Addison > wrote: Hi everyone, This is a bit of a follow up to the discussion on Windows 32-bit builds in the jdk-dev thread from yesterday, but is anyone currently actively maintaining the 32-bit Arm code for the JDK21 and HEAD streams? Noting that unlike Win32, there are GitHub PR tests for Arm32 so failures are more likely to get noticed than for Win32. Eclipse Temurin has not yet released a version of JDK21 but we have had a user ask about whether we will do so (issue link), since we have done so for previous LTS releases. As input to making a decision on this it would be helpful to understand if the platform has a strong support story upstream for the latest release streams which would be important to us to be able to maintain such a release, or if it is likely to go the same way as Win32 i.e. that it will suffer failures over time which would make it harder to support it along with the other platform ports. The wiki at https://wiki.openjdk.org/display/hotspot/ports lists Boris Ulasevich and Sergey Nazarkin as maintainers, so I've explicitly copied both on this email but I'm looking to see if there is still active maintenance going on with the Arm32 port from any members of the openjdk community for the newer codebases, or whether there is any possibility of it being deprecated at some point like Win32. Thanks in advance, Stewart... -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjx001202 at gmail.com Thu Dec 7 08:10:11 2023 From: zjx001202 at gmail.com (Glavo) Date: Thu, 7 Dec 2023 16:10:11 +0800 Subject: A new JPMS-friendly Java program packaging format In-Reply-To: References: Message-ID: > Please provide a way to exclude files or packages from a particular Jar. For example, I may not want Multimap.class in the Guava Jar. This feature is very useful. I'll put this on my TODO list. > Is this compatible with Proguard's and Graal VM's to trim fat Jars? Both of these will eliminate unused classes, methods, and fields to reduce the size of the fat Jar. I have some interest in Proguard and will look into it at a later date. As for GraalVM, I have no plans to support it yet. I think japp and native-image are parallel. If users need it, they should probably build native-image directly through the build script instead of creating a japp file first and then build native-image based on the japp file. Moreover, I don?t seem to be able to provide support for native-image in a non-intrusive way, I can only modify the source code of GraalVM itself. Therefore, I won't consider it for now. Glavo On Thu, Dec 7, 2023 at 7:29?AM Nathan Reynolds wrote: > Please provide a way to exclude files or packages from a particular Jar. > For example, I may not want Multimap.class in the Guava Jar. > > Is this compatible with Proguard's and Graal VM's to trim fat Jars? Both > of these will eliminate unused classes, methods, and fields to reduce the > size of the fat Jar. > > On Wed, Dec 6, 2023 at 3:17?PM Glavo wrote: > >> Hey everyone, >> >> Recently, I have been busy developing a new JPMS-friendly Java program >> packaging format: JApp (https://github.com/Glavo/japp). >> >> JApp is intended as a better alternative to shadow jar (fat jar). >> Users need to specify the module path and classpath when creating a JApp >> file. >> Resources in all module path/classpath entries (JAR or directory) are >> packaged into a single japp file, >> but unlike shadow jars, japp isolates resources from different module >> path/classpath entries. >> >> For example, we can create a japp file with the following command: >> >> japp create -o myapp.japp \ >> --module-path commons-lang3-3.14.0.jar:commons-io-2.15.1.jar \ >> --classpath guava-32.1.3-jre.jar:gson-2.10.1.jar >> >> >> This will create a japp file named `myjapp.japp` that contains resources >> from four jar files. >> At runtime, the URIs for the resources from the four JAR files each look >> like this: >> >> >> japp:/modules/org.apache.commons.lang3/org/apache/commons/lang3/ObjectUtils.class >> japp:/modules/org.apache.commons.io/org/apache/commons/io/IOUtils.class >> >> japp:/classpath/guava-32.1.3-jre.jar/com/google/common/collect/Multimap.class >> japp:/classpath/gson-2.10.1.jar/com/google/gson/Gson.class >> At runtime, each entry in the module path and classpath is independent, >> just like passing the `--classpath`/`--module-path` option directly to >> the `java` command. >> >> By sharing the class constant pool, using zstd as the compression method, >> and >> compressing the file metadata, japp files are generally smaller than >> shadow jars. >> >> JApp files also support specifying some conditions, such as requirements >> for the Java version. >> JApp selects the Java runtime to use to run the program based on these >> conditions. >> >> Here is its GitHub repository, for more features and detailed >> instructions please refer to the README: >> >> https://github.com/Glavo/japp >> >> Now that the basic features of JApp are complete, I'm sharing it here in >> the hope >> that more people will try it and give feedback. >> >> Thank you to everyone who is willing to read this email! >> >> Glavo >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Thu Dec 7 11:25:54 2023 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 7 Dec 2023 12:25:54 +0100 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: <5df74639-05a3-434a-97a8-01f0aa89bc86@oracle.com> On 2023-12-06 14:22, Stewart Addison wrote: > I can understand that, however we should bear in mind that with > JDK<=17 being supported regardless, if it gets removed in a later > version there is almost certainly a much higher risk of backports > "breaking" the LTS streams (as it did recently) compared to other > platforms without it being caught prior to integration, so it might be > good to catch it earlier in the backport cycle (or maybe as a middle > ground just add such checks to JDK<=17) regardless of whether it gets > removed in >=21. That's just a specific case of the general cost of doing backports: stuff change in mainline, so you can never know how much effort it will be to make the corresponding change in an older release. That can not be, and have never been, a valid argument for blocking changes in mainline. The current policy of the update project seem to be a very much "open arms", accepting a lot of issues for backport, even if they are not critical for the stability or the security of the platform. Such a policy is of course more likely to run into problems the more the mainline diverges from the version the update release is based on. But once again, that weight is on the update maintainers. If it becomes too much risk of breakage when backporting changes from mainline, then they might need to lower their acceptance rate. Once again, it should not affect what decisions we make for the mainline going forward. /Magnus > > Regards, > > Stewart... > -- > > > > On Wed, 6 Dec 2023 at 11:54, Alan Bateman wrote: > > On 06/12/2023 10:22, Stewart Addison wrote: > > Hi Magnus, > > > > I put in a fix for another Win32 build break recently but hadn't > > realised it was broken again - ref > > https://bugs.openjdk.org/browse/JDK-8319958. Since the Win32 > port is > > currently only deprecated I was already wondering if we should > go for > > the simple solution of having some github PR checks added for Win32 > > along with the other platforms (Obviously it would need the > parameter > > to enable deprecated ports) as I feel this would help prevent > things > > being merged and subsequently backported that break things. > > I assume this would put a tax on everyone, the testing in GHA is > already > a bit noisy. Seems like it would be better to remove the port, I > think > it would be useful to hear from George Adams and Bruno Borges to > know if > they plan to follow-up JEP 449 and do the next step. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Thu Dec 7 11:31:35 2023 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 7 Dec 2023 12:31:35 +0100 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: <20231206084033.683793079@eggemoggin.niobe.net> References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> <2A961D30-BD87-43CE-99F7-BFA33E98D040@sap.com> <67627a65-5509-4900-ad55-ebc2021c790f@oracle.com> <20231206084033.683793079@eggemoggin.niobe.net> Message-ID: <9dd24344-c7ad-41d2-bfd5-ba8d8dac01b3@oracle.com> On 2023-12-06 14:40, Mark Reinhold wrote: > Ports come and go over time. They are introduced via JEPs, and so they > should be deprecated-for-removal via JEPs and then removed via JEPs. > > Fortunately, a JEP to remove the Windows/x86 port will be trivial. Writing the JEP itself is definitely trivial. To actually remove all code that will not be needed anymore can be more of a challenge. Deleting some windows_x86 files is easy and all, but there are likely a lot of interspersed hacks, if-clauses, ifdefs and workarounds that are no longer needed; theoretically all windows-specific source code files will need to be checked. My guess is that if we do remove it, and even if we try to do a thorough job, we will continue to find win32-ism's here and there for years to come. But then at least we can just remove them when we find them, if the platform support has actually been removed. Just to be clear: I do think it is worth it, even if it is a lot of job. The win32 api is substandard and quirky, and our code base will be better if we can get rid of it. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Thu Dec 7 11:36:07 2023 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 7 Dec 2023 12:36:07 +0100 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: On 2023-12-06 11:22, Stewart Addison wrote: > > I think there's a discussion to be had here regarding 32-bit support > in general going forward - I have a specific question about arm32 and > whether anyone is actively maintaining that one but perhaps that's a > matter for another thread unless anyone wants to jump in and say > they'll be keeping arm32 alive in the codebase. Obviously the glory days of 32-bit support are over. But I'm guessing it will be some more time before all 32-bit code can be dropped. So I think it is important not to conflate dropping general 32-bit support with the more specific case of dropping win32. The former is more about cpu support, the latter more about os support. Arm32 in specific has never had any really active backers; it seems to be slowly dying but is apparently still on life-support. Let's keep that out of the win32 discussion. /Magnus From mark.reinhold at oracle.com Thu Dec 7 15:03:26 2023 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 7 Dec 2023 15:03:26 +0000 Subject: JEP proposed to target JDK 22: 464: Scoped Values (Second Preview) In-Reply-To: <20231130141116.187DE64FF14@eggemoggin.niobe.net> References: <20231130141116.187DE64FF14@eggemoggin.niobe.net> Message-ID: <20231207100324.618171835@eggemoggin.niobe.net> 2023/11/30 9:11:16 -0500, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 22: > > 464: Scoped Values (Second Preview) > https://openjdk.org/jeps/464 > > Summary: Introduce scoped values, which enable the safe and efficient > sharing of immutable data within and across threads. They are > preferred to thread-local variables, especially when using large > numbers of virtual threads. This is a preview API. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 15:00 UTC on Thursday, 7 December, or if they?re raised > and then satisfactorily answered, then per the JEP 2.0 process proposal > [2] I?ll target this JEP to JDK 22. Hearing no objections, I?ve targeted this JEP to JDK 22. - Mark From mark.reinhold at oracle.com Thu Dec 7 18:54:22 2023 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 7 Dec 2023 18:54:22 +0000 Subject: JDK 22 is now in Rampdown Phase One Message-ID: <20231207185420.1D253650C22@eggemoggin.niobe.net> Per the JDK 22 schedule [1], we are now in Rampdown Phase One. The overall feature set [2] is frozen. No further JEPs will be targeted to this release. We?ve forked the main-line source repository to the jdk22 stabilization repository (https://github.com/openjdk/jdk22). Any changes pushed to the main line are now bound for JDK 23, as noted previously [3]. The stabilization repository is open for select bug fixes and, with approval, late enhancements per JEP 3, the JDK Release Process [4]. If you?re responsible for any of the bugs on the RDP 1 candidate-bug list [5] then please see JEP 3 for guidance on how to handle them. We will integrate most stabilization changes via backports, as we did for JDK 21 [6]: - Most fixes and enhancements intended for the stabilization repository will also be applicable to the main-line repository. Integrate such a change into the main-line repository first. Then, after you have obtained any required approvals, backport it to the stabilization repository using the Skara `/backport` command [7] or, if necessary, by manually opening a backport PR with the title `Backport $HASH`, where `$HASH` is the original commit hash. (The Developers? Guide contains more information on working with backports [8].) - Some fixes will be specific to the stabilization repository and not applicable to the main-line repository. Integrate such a change directly into the stabilization repository. In order to make sure that no backports are missed, prior to the RDP 2 and RC phases JDK Contributors will be reminded to review changes that have been integrated into the main-line repository but not backported to the stabilization repository. These JBS queries can be useful: - Changes not backported from the main line https://bugs.openjdk.org/issues/?filter=44264 - My changes not backported from the main line https://bugs.openjdk.org/issues/?filter=44268 - Mark [1] https://openjdk.org/projects/jdk/22/#Schedule [2] https://openjdk.org/projects/jdk/22/#Features [3] https://mail.openjdk.org/pipermail/jdk-dev/2023-November/008483.html [4] https://openjdk.org/jeps/3 [5] https://j.mp/jdk-rdp-1 [6] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements [7] https://wiki.openjdk.org/display/SKARA/Backports [8] https://openjdk.org/guide/#working-with-backports-in-jbs From ebresie at gmail.com Thu Dec 7 20:37:26 2023 From: ebresie at gmail.com (Eric Bresie) Date: Thu, 7 Dec 2023 14:37:26 -0600 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: Just curious if anyone has any visibility as to how widely 32-bit windows may still be in use? I?d imagine there could still be a lot of older systems (and maybe some embedded case) with 32bit windows still in use which the removal risks some possible bad vibes for that user base. Although I guess if they?re not updating to newer Windows (and hardware), they may not be upgrading Java without 32bit Windows support either. On Thu, Dec 7, 2023 at 5:38?AM Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2023-12-06 11:22, Stewart Addison wrote: > > > > > I think there's a discussion to be had here regarding 32-bit support > > in general going forward - I have a specific question about arm32 and > > whether anyone is actively maintaining that one but perhaps that's a > > matter for another thread unless anyone wants to jump in and say > > they'll be keeping arm32 alive in the codebase. > > Obviously the glory days of 32-bit support are over. But I'm guessing it > will be some more time before all 32-bit code can be dropped. So I think > it is important not to conflate dropping general 32-bit support with the > more specific case of dropping win32. The former is more about cpu > support, the latter more about os support. > > Arm32 in specific has never had any really active backers; it seems to > be slowly dying but is apparently still on life-support. Let's keep that > out of the win32 discussion. > > /Magnus > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dalibor.topic at oracle.com Thu Dec 7 21:54:11 2023 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 7 Dec 2023 21:54:11 +0000 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: The last supported 32-bit Windows goes out of support in October 2025, if I'm not mistaken. So between now and the next LTS, the removal of the port would be in order, as it wouldn't really be worth still having the port in the next LTS when at that point, given a six-monthly release cycle, 32-bit Windows would only have a remaining support span that would be measured in weeks. So there are only two viable options for that port: either a removal in JDK 23 or a removal in JDK 24. I think given that it appears to be unmaintained, sooner might be better than later, but in any case filing a JEP for removal of the port would signal to those who want to continue to maintain it themselves for another 6 months to step up to the plate. cheers, dalibor topic -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann ________________________________________ From: jdk-dev on behalf of Eric Bresie Sent: Thursday, December 7, 2023 9:37 PM To: Magnus Ihse Bursie Cc: Stewart Addison; jdk-dev at openjdk.org Subject: Re: Windows-x86 (32-bit) build is broken. Time to retire it? Just curious if anyone has any visibility as to how widely 32-bit windows may still be in use? I?d imagine there could still be a lot of older systems (and maybe some embedded case) with 32bit windows still in use which the removal risks some possible bad vibes for that user base. Although I guess if they?re not updating to newer Windows (and hardware), they may not be upgrading Java without 32bit Windows support either. On Thu, Dec 7, 2023 at 5:38?AM Magnus Ihse Bursie > wrote: On 2023-12-06 11:22, Stewart Addison wrote: > > I think there's a discussion to be had here regarding 32-bit support > in general going forward - I have a specific question about arm32 and > whether anyone is actively maintaining that one but perhaps that's a > matter for another thread unless anyone wants to jump in and say > they'll be keeping arm32 alive in the codebase. Obviously the glory days of 32-bit support are over. But I'm guessing it will be some more time before all 32-bit code can be dropped. So I think it is important not to conflate dropping general 32-bit support with the more specific case of dropping win32. The former is more about cpu support, the latter more about os support. Arm32 in specific has never had any really active backers; it seems to be slowly dying but is apparently still on life-support. Let's keep that out of the win32 discussion. /Magnus From Bruno.Borges at microsoft.com Fri Dec 8 01:47:02 2023 From: Bruno.Borges at microsoft.com (Bruno Borges) Date: Fri, 8 Dec 2023 01:47:02 +0000 Subject: [EXTERNAL] Re: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: > Although I guess if they?re not updating to newer Windows (and hardware), they may not be upgrading Java without 32bit Windows support either. This thinking was part of the logic behind JEP 449. ---> "Legacy systems are unlikely to migrate to versions of the JDK following the release of Java 21." If there is a Java system still running on an old version of Windows 32-bit -- that will by the way soon be EOL -- it is unlikely that the team will move said system to a newer version of Java. More often than not, there are cases of users not even running the latest minor version of older major versions of Java (7, 8, 11). ________________________________ From: jdk-dev on behalf of Eric Bresie Sent: December 7, 2023 12:37 PM To: Magnus Ihse Bursie Cc: Stewart Addison ; jdk-dev at openjdk.org Subject: [EXTERNAL] Re: Windows-x86 (32-bit) build is broken. Time to retire it? Some people who received this message don't often get email from ebresie at gmail.com. Learn why this is important Just curious if anyone has any visibility as to how widely 32-bit windows may still be in use? I?d imagine there could still be a lot of older systems (and maybe some embedded case) with 32bit windows still in use which the removal risks some possible bad vibes for that user base. Although I guess if they?re not updating to newer Windows (and hardware), they may not be upgrading Java without 32bit Windows support either. On Thu, Dec 7, 2023 at 5:38?AM Magnus Ihse Bursie > wrote: On 2023-12-06 11:22, Stewart Addison wrote: > > I think there's a discussion to be had here regarding 32-bit support > in general going forward - I have a specific question about arm32 and > whether anyone is actively maintaining that one but perhaps that's a > matter for another thread unless anyone wants to jump in and say > they'll be keeping arm32 alive in the codebase. Obviously the glory days of 32-bit support are over. But I'm guessing it will be some more time before all 32-bit code can be dropped. So I think it is important not to conflate dropping general 32-bit support with the more specific case of dropping win32. The former is more about cpu support, the latter more about os support. Arm32 in specific has never had any really active backers; it seems to be slowly dying but is apparently still on life-support. Let's keep that out of the win32 discussion. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From sxa at redhat.com Fri Dec 8 16:58:53 2023 From: sxa at redhat.com (Stewart Addison) Date: Fri, 8 Dec 2023 16:58:53 +0000 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: > I?d imagine there could still be a lot of older systems (and maybe some embedded case) with 32bit windows still in use which the removal risks some possible bad vibes for that user base. > Although I guess if they?re not updating to newer Windows (and hardware), they may not be upgrading Java without 32bit Windows support either. The other argument I've heard in the past is that if someone is using a proprietary application that contains 32-bit JNI libraries then they wouldn't be able to migrate over to 64-bit. In that situation users may well be using a newer 64-bit windows/hardware, but still legitimately running the 32-bit JVM. But, of course, anyone with such a legacy application that is not yet available as 64-bit is unlikely to have a strong requirement to push up to a newer major version of OpenJDK any time soon ... However much we as a community might like them to. It would certainly be good to know for certain what people's use cases are for that. I can't comment specifically on how many 32-bit windows OSs are out there but looking at the latest download numbers for that last JDK17 release of Eclipse Temurin, it's roughly ten times fewer 32-bit downloads than 64-bit ones, but that means a surprising (at least to me) number of people seem to still be actively seeking out and selecting that one in preference for some reason. Although I don't recall seeing anyone pushing back on us (Temurin) for builds on that platform for JDK21 yet. > The last supported 32-bit Windows goes out of support in October 2025, if I'm not mistaken. Yeah that's my understanding too for Windows 10. On the server OS side 2008 was the last version available in 32-bit I believe and that's already out of support. Regards, Stewart... -- On Thu, 7 Dec 2023 at 20:37, Eric Bresie wrote: > Just curious if anyone has any visibility as to how widely 32-bit windows > may still be in use? > I?d imagine there could still be a lot of older systems (and maybe some > embedded case) with 32bit windows still in use which the removal risks some > possible bad vibes for that user base. > > Although I guess if they?re not updating to newer Windows (and hardware), > they may not be upgrading Java without 32bit Windows support either. > > On Thu, Dec 7, 2023 at 5:38?AM Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> On 2023-12-06 11:22, Stewart Addison wrote: >> >> > >> > I think there's a discussion to be had here regarding 32-bit support >> > in general going forward - I have a specific question about arm32 and >> > whether anyone is actively maintaining that one but perhaps that's a >> > matter for another thread unless anyone wants to jump in and say >> > they'll be keeping arm32 alive in the codebase. >> >> Obviously the glory days of 32-bit support are over. But I'm guessing it >> will be some more time before all 32-bit code can be dropped. So I think >> it is important not to conflate dropping general 32-bit support with the >> more specific case of dropping win32. The former is more about cpu >> support, the latter more about os support. >> >> Arm32 in specific has never had any really active backers; it seems to >> be slowly dying but is apparently still on life-support. Let's keep that >> out of the win32 discussion. >> >> /Magnus >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Dec 9 08:26:19 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 9 Dec 2023 08:26:19 +0000 Subject: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> Message-ID: <6611bbc3-f5bb-42da-8e32-5bff0c8f78f4@oracle.com> On 08/12/2023 01:47, Bruno Borges wrote: > > Although I guess if they?re not updating to newer Windows (and > hardware), they may not be upgrading Java without 32bit Windows > support either. > > This thinking was part of the logic behind JEP 449. > Are you, or someone else from Microsoft, planning to propose the removal of the port as a follow on from JEP 449 ? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruno.Borges at microsoft.com Sat Dec 9 18:14:00 2023 From: Bruno.Borges at microsoft.com (Bruno Borges) Date: Sat, 9 Dec 2023 18:14:00 +0000 Subject: [EXTERNAL] Re: Windows-x86 (32-bit) build is broken. Time to retire it? In-Reply-To: <6611bbc3-f5bb-42da-8e32-5bff0c8f78f4@oracle.com> References: <3cdeb68d-ecce-4a5f-82f3-6a2c1c5eebbe@oracle.com> <6611bbc3-f5bb-42da-8e32-5bff0c8f78f4@oracle.com> Message-ID: I think this conversation/thread is exactly what we were hoping to see with JEP 449. And I believe it is starting to confirm that we are ready to remove the port, moving forward. So yes, we do want to propose a new JEP that ultimately removes the port, potentially sometime between JDK 23-24. ________________________________ From: Alan Bateman Sent: Saturday, December 9, 2023 12:26:34 a.m. To: Bruno Borges Cc: jdk-dev at openjdk.org Subject: [EXTERNAL] Re: Windows-x86 (32-bit) build is broken. Time to retire it? On 08/12/2023 01:47, Bruno Borges wrote: > Although I guess if they?re not updating to newer Windows (and hardware), they may not be upgrading Java without 32bit Windows support either. This thinking was part of the logic behind JEP 449. Are you, or someone else from Microsoft, planning to propose the removal of the port as a follow on from JEP 449 ? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at cjnash.com Sat Dec 9 21:47:43 2023 From: simon at cjnash.com (Simon Nash) Date: Sat, 9 Dec 2023 21:47:43 +0000 Subject: JDK 22 is now in Rampdown Phase One In-Reply-To: <20231207185420.1D253650C22@eggemoggin.niobe.net> References: <20231207185420.1D253650C22@eggemoggin.niobe.net> Message-ID: <3a6e0f87-1cbd-d506-e085-e95c34f20766@cjnash.com> On 07/12/2023 18:54, Mark Reinhold wrote: > Per the JDK 22 schedule [1], we are now in Rampdown Phase One. > > The overall feature set [2] is frozen. No further JEPs will be targeted > to this release. > > We?ve forked the main-line source repository to the jdk22 stabilization > repository (https://github.com/openjdk/jdk22). Any changes pushed to > the main line are now bound for JDK 23, as noted previously [3]. > > The stabilization repository is open for select bug fixes and, with > approval, late enhancements per JEP 3, the JDK Release Process [4]. > If you?re responsible for any of the bugs on the RDP 1 candidate-bug > list [5] then please see JEP 3 for guidance on how to handle them. What is the situation regarding the draft JEP to prepare to restrict the use of JNI (https://openjdk.org/jeps/8307341)? Is this targeted for JDK 22 or deferred until JDK 23? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Dec 10 06:01:22 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 10 Dec 2023 06:01:22 +0000 Subject: JDK 22 is now in Rampdown Phase One In-Reply-To: <3a6e0f87-1cbd-d506-e085-e95c34f20766@cjnash.com> References: <20231207185420.1D253650C22@eggemoggin.niobe.net> <3a6e0f87-1cbd-d506-e085-e95c34f20766@cjnash.com> Message-ID: On 09/12/2023 21:47, Simon Nash wrote: > What is the situation regarding the draft JEP to prepare to restrict > the use of JNI (https://openjdk.org/jeps/8307341)? > Is this targeted for JDK 22 or deferred until JDK 23? It's in the "Submitted" state so not a Candidate. It would need to be a Candidate before proposing to any release. -Alan From jai.forums2013 at gmail.com Mon Dec 11 13:39:53 2023 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 11 Dec 2023 19:09:53 +0530 Subject: CFV: New JDK Committer: Eirik Bjorsnos In-Reply-To: <9e75c0cc-5640-4758-8d73-dc9c84283091@gmail.com> References: <9e75c0cc-5640-4758-8d73-dc9c84283091@gmail.com> Message-ID: <40cb2ee8-1d98-4a65-8a3c-0725945e69e3@gmail.com> The due day noted for this CFV has a copy/paste error: > Votes are due by 6:30 UTC Monday 14th December 2023. It was meant to be Thursday 14th December 2023. So there are still a few more days remaining for this CFV. (Thank you Raffaello for spotting this) -Jaikiran On 30/11/23 11:35 am, Jaikiran Pai wrote: > I hereby nominate Eirik Bjorsnos to JDK Committer. > > GitHub userid: eirbjo (https://github.com/eirbjo) > OpenJDK census: https://openjdk.org/census#eirbjo > > Over the years, Eirik has been regularly contributing to the JDK. He > currently has 31 commits in the JDK project[1], mainly in the jar/zip > API area but not limited to it. Some of his contributions have also > helped improve the quality of tests that we have for the zip/jar APIs. > > From Eirik: > ?? ?"Java programmer for 20 years, mostly in the Norwegian financial > and public sectors. Individual OpenJDK Contributor since April 2020 > (Author role since March 2023) Main focus has been performance, > improved test coverage and removal of deprecated APIs in the ZIP and > JAR areas" > > > Votes are due by 6:30 UTC Monday 14th December 2023. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3] > > > [1] https://github.com/openjdk/jdk/commits?author=eirbjo > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote > > -Jaikiran > From claes.redestad at oracle.com Mon Dec 11 14:19:00 2023 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 11 Dec 2023 14:19:00 +0000 Subject: CFV: New JDK Committer: Eirik Bjorsnos In-Reply-To: <9e75c0cc-5640-4758-8d73-dc9c84283091@gmail.com> References: <9e75c0cc-5640-4758-8d73-dc9c84283091@gmail.com> Message-ID: <72F18174-6AA2-43A7-AC74-3451BBEA197C@oracle.com> Vote: yes /Claes > 30 nov. 2023 kl. 07:05 skrev Jaikiran Pai : > > I hereby nominate Eirik Bjorsnos to JDK Committer. > > GitHub userid: eirbjo (https://github.com/eirbjo) > OpenJDK census: https://openjdk.org/census#eirbjo > > Over the years, Eirik has been regularly contributing to the JDK. He currently has 31 commits in the JDK project[1], mainly in the jar/zip API area but not limited to it. Some of his contributions have also helped improve the quality of tests that we have for the zip/jar APIs. > > From Eirik: > "Java programmer for 20 years, mostly in the Norwegian financial and public sectors. Individual OpenJDK Contributor since April 2020 (Author role since March 2023) Main focus has been performance, improved test coverage and removal of deprecated APIs in the ZIP and JAR areas" > > > Votes are due by 6:30 UTC Monday 14th December 2023. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3] > > > [1] https://github.com/openjdk/jdk/commits?author=eirbjo > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote > > -Jaikiran > From ivan.walulya at oracle.com Mon Dec 11 15:30:15 2023 From: ivan.walulya at oracle.com (Ivan Walulya) Date: Mon, 11 Dec 2023 15:30:15 +0000 Subject: CFV: New JDK Committer: Eirik Bjorsnos In-Reply-To: <9e75c0cc-5640-4758-8d73-dc9c84283091@gmail.com> References: <9e75c0cc-5640-4758-8d73-dc9c84283091@gmail.com> Message-ID: Vote: yes // Ivan > On 30 Nov 2023, at 07:05, Jaikiran Pai wrote: > > I hereby nominate Eirik Bjorsnos to JDK Committer. > > GitHub userid: eirbjo (https://github.com/eirbjo) > OpenJDK census: https://openjdk.org/census#eirbjo > > Over the years, Eirik has been regularly contributing to the JDK. He currently has 31 commits in the JDK project[1], mainly in the jar/zip API area but not limited to it. Some of his contributions have also helped improve the quality of tests that we have for the zip/jar APIs. > > From Eirik: > "Java programmer for 20 years, mostly in the Norwegian financial and public sectors. Individual OpenJDK Contributor since April 2020 (Author role since March 2023) Main focus has been performance, improved test coverage and removal of deprecated APIs in the ZIP and JAR areas" > > > Votes are due by 6:30 UTC Monday 14th December 2023. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3] > > > [1] https://github.com/openjdk/jdk/commits?author=eirbjo > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote > > -Jaikiran > From volker.simonis at gmail.com Tue Dec 12 09:39:27 2023 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 12 Dec 2023 10:39:27 +0100 Subject: CFV: New JDK Committer: Eirik Bjorsnos In-Reply-To: <9e75c0cc-5640-4758-8d73-dc9c84283091@gmail.com> References: <9e75c0cc-5640-4758-8d73-dc9c84283091@gmail.com> Message-ID: Vote: yes Jaikiran Pai schrieb am Do., 30. Nov. 2023, 07:05: > I hereby nominate Eirik Bjorsnos to JDK Committer. > > GitHub userid: eirbjo (https://github.com/eirbjo) > OpenJDK census: https://openjdk.org/census#eirbjo > > Over the years, Eirik has been regularly contributing to the JDK. He > currently has 31 commits in the JDK project[1], mainly in the jar/zip > API area but not limited to it. Some of his contributions have also > helped improve the quality of tests that we have for the zip/jar APIs. > > From Eirik: > "Java programmer for 20 years, mostly in the Norwegian financial > and public sectors. Individual OpenJDK Contributor since April 2020 > (Author role since March 2023) Main focus has been performance, improved > test coverage and removal of deprecated APIs in the ZIP and JAR areas" > > > Votes are due by 6:30 UTC Monday 14th December 2023. > > Only current JDK Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3] > > > [1] https://github.com/openjdk/jdk/commits?author=eirbjo > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote > > -Jaikiran > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Dec 13 11:22:59 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Dec 2023 11:22:59 +0000 Subject: CFV: New JDK Committer: Viktor Klang Message-ID: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> I hereby nominate Viktor Klang to JDK Committer. Viktor has been a member of the Java team in Oracle since 2022. Many of you will know him from past work on Akka, Reactive Streams, and his contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a truly wonderful enhancement to the streams API to support new intermediate stream operations.? Aside from JEP 461, Viktor has contributed 19 other changes so far [2][3]. Votes are due by December 27, 2023, 23.59 UTC. Only current JDK Committers [4] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. -Alan [1] https://openjdk.org/jeps/461 [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora [4] https://openjdk.org/census [5] https://openjdk.org/projects/#committer-vote From lance.andersen at oracle.com Wed Dec 13 11:27:21 2023 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 13 Dec 2023 11:27:21 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <8326E5A0-34E2-4F7D-B759-F94F35DCDC9A@oracle.com> Vote: yes On Dec 13, 2023, at 6:22 AM, Alan Bateman > wrote: I hereby nominate Viktor Klang to JDK Committer. Viktor has been a member of the Java team in Oracle since 2022. Many of you will know him from past work on Akka, Reactive Streams, and his contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a truly wonderful enhancement to the streams API to support new intermediate stream operations. Aside from JEP 461, Viktor has contributed 19 other changes so far [2][3]. Votes are due by December 27, 2023, 23.59 UTC. Only current JDK Committers [4] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. -Alan [1] https://openjdk.org/jeps/461 [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora [4] https://openjdk.org/census [5] https://openjdk.org/projects/#committer-vote [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: oracle_sig_logo.gif URL: From james.laskey at oracle.com Wed Dec 13 11:33:37 2023 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 13 Dec 2023 11:33:37 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <8326E5A0-34E2-4F7D-B759-F94F35DCDC9A@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> <8326E5A0-34E2-4F7D-B759-F94F35DCDC9A@oracle.com> Message-ID: <76B04CD0-EB2D-4B35-AFC2-4AA30A76C260@oracle.com> Vote: yes ? On Dec 13, 2023, at 7:27?AM, Lance Andersen wrote: ? Vote: yes On Dec 13, 2023, at 6:22 AM, Alan Bateman > wrote: I hereby nominate Viktor Klang to JDK Committer. Viktor has been a member of the Java team in Oracle since 2022. Many of you will know him from past work on Akka, Reactive Streams, and his contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a truly wonderful enhancement to the streams API to support new intermediate stream operations. Aside from JEP 461, Viktor has contributed 19 other changes so far [2][3]. Votes are due by December 27, 2023, 23.59 UTC. Only current JDK Committers [4] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. -Alan [1] https://openjdk.org/jeps/461 [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora [4] https://openjdk.org/census [5] https://openjdk.org/projects/#committer-vote Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: oracle_sig_logo.gif URL: From jai.forums2013 at gmail.com Wed Dec 13 12:15:22 2023 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 13 Dec 2023 17:45:22 +0530 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: vote: yes -Jaikiran On 13/12/23 4:52 pm, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many > of you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], > a truly wonderful enhancement to the streams API to support new > intermediate stream operations.? Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this > nomination. Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From christian.s.stein at oracle.com Wed Dec 13 12:24:35 2023 From: christian.s.stein at oracle.com (Christian Stein) Date: Wed, 13 Dec 2023 12:24:35 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: yes Cheers, Christian ________________________________________ From: jdk-dev on behalf of Alan Bateman Sent: Wednesday, December 13, 2023 12:22 To: jdk-dev Subject: CFV: New JDK Committer: Viktor Klang I hereby nominate Viktor Klang to JDK Committer. Viktor has been a member of the Java team in Oracle since 2022. Many of you will know him from past work on Akka, Reactive Streams, and his contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a truly wonderful enhancement to the streams API to support new intermediate stream operations. Aside from JEP 461, Viktor has contributed 19 other changes so far [2][3]. Votes are due by December 27, 2023, 23.59 UTC. Only current JDK Committers [4] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. -Alan [1] https://openjdk.org/jeps/461 [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora [4] https://openjdk.org/census [5] https://openjdk.org/projects/#committer-vote From pavel.rappo at oracle.com Wed Dec 13 12:43:52 2023 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 13 Dec 2023 12:43:52 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <942BA605-2155-4A9B-AAEC-28804A96501E@oracle.com> Vote: yes -Pavel > On 13 Dec 2023, at 11:22, Alan Bateman wrote: > > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of you will know him from past work on Akka, Reactive Streams, and his contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a truly wonderful enhancement to the streams API to support new intermediate stream operations. Aside from JEP 461, Viktor has contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From jan.lahoda at oracle.com Wed Dec 13 12:47:49 2023 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 13 Dec 2023 13:47:49 +0100 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <646f0cd9-f5c9-4494-bd4b-30567120f63d@oracle.com> Vote: yes Jan On 13. 12. 23 12:22, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many > of you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], > a truly wonderful enhancement to the streams API to support new > intermediate stream operations.? Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this > nomination. Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From sean.coffey at oracle.com Wed Dec 13 12:58:47 2023 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=C3=A1n_Coffey?=) Date: Wed, 13 Dec 2023 12:58:47 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <92784e14-fb61-45db-9e81-1c8718b6740e@oracle.com> Vote: yes regards, Sean. On 13/12/2023 11:22, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many > of you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], > a truly wonderful enhancement to the streams API to support new > intermediate stream operations.? Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this > nomination. Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From sgehwolf at redhat.com Wed Dec 13 13:03:05 2023 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 13 Dec 2023 14:03:05 +0100 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <91c68a4185323a74ad8e61ce303a5a5bca5477e5.camel@redhat.com> Vote: yes On Wed, 2023-12-13 at 11:22 +0000, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. From rehn at rivosinc.com Wed Dec 13 13:25:36 2023 From: rehn at rivosinc.com (Robbin Ehn) Date: Wed, 13 Dec 2023 14:25:36 +0100 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: yes /Robbin On Wed, Dec 13, 2023 at 12:23?PM Alan Bateman wrote: > > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of > you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a > truly wonderful enhancement to the streams API to support new > intermediate stream operations. Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From djelinski1 at gmail.com Wed Dec 13 14:10:29 2023 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Wed, 13 Dec 2023 15:10:29 +0100 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: yes dj ?r., 13 gru 2023 o 12:50 Alan Bateman napisa?(a): > > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of > you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a > truly wonderful enhancement to the streams API to support new > intermediate stream operations. Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From christoph.langer at sap.com Wed Dec 13 14:17:06 2023 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 13 Dec 2023 14:17:06 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Alan Bateman > Sent: Mittwoch, 13. Dezember 2023 12:23 > To: jdk-dev > Subject: CFV: New JDK Committer: Viktor Klang > > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of you > will know him from past work on Akka, Reactive Streams, and his contributions > in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a truly wonderful > enhancement to the streams API to support new intermediate stream > operations.? Aside from JEP 461, Viktor has contributed 19 other changes so far > [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From mark.reinhold at oracle.com Wed Dec 13 14:18:49 2023 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 13 Dec 2023 14:18:49 +0000 Subject: Release stabilization: Create backport issues immediately Message-ID: <20231213091848.160388671@eggemoggin.niobe.net> Last May, for JDK 21, we adopted Erik Duveblad?s proposal to use the Skara backport mechanism to stabilize the release after RDP 1 [1][2]: > Erik proposes that we instead use the Skara backport mechanism, which > we already use for update releases. To fix a bug in the release being > stabilized you?d first create a PR against the main-line repository. > Then, after that PR is reviewed and integrated, you?d use Skara?s > `/backport` command to backport the fix to the stabilization repository. > If your fix is intended only for the stabilization repository then you?d > create a PR directly against that repository. This worked out reasonably well for JDK 21, except for one problem. Suppose that you have a candidate bug [3] that you want to fix in the stabilization release (e.g., JDK 22). Before you merge the PR against the main-line repository, you change the fix version of that bug to that of the main-line release (e.g., JDK 23) so that Skara will close the correct issue. This causes the bug to disappear from the results of the candidate-bug queries [4] that we use to guide our work in the RDP 1, RDP 2, and RC phases, leaving us at risk of losing track of the bug for the stabilization release. In JDK 21, various Committers worked around this in different ways, for example by using JIRA labels. The difficulty with labels is that you have to remember to remove them when they?re no longer applicable, which makes the overall process more complex. For JDK 22, let?s instead try the following small adjustment to the integration procedure: To fix a bug in the stabilization release, first target that bug to the main-line release and **immediately create a backport of the bug and target the backport to the stabilization release.** Then create a PR to integrate your fix into the main-line release. After you have obtained any necessary approvals, backport the main-line PR to the stabilization repository via the Skara `/backport` command. (As before, if your fix is intended only for the stabilization repository then target the bug to the stabilization release and create a PR directly against that repository.) We will also update the candidate-bug queries to include issues of type ?Backport? as well as ?Bug?. These changes will ensure that a bug relevant to the stabilization release remains on the appropriate candidate-bug lists. Its issue number will change when the fix is integrated into the main-line repository, but at least we won?t lose track of it. Comments welcome, as always, but we?re already in RDP 1 so I suggest that we start using this process immediately and adjust if necessary. I?ve already updated the candidate-bug queries; I?ll update JEP 3 shortly. - Mark [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-April/007612.html [2] https://mail.openjdk.org/pipermail/jdk-dev/2023-May/007822.html [3] https://openjdk.org/jeps/3#Candidate-bugs [4] https://j.mp/jdk-rdp-1, https://j.mp/jdk-rdp-2, https://j.mp/jdk-rc From roger.riggs at oracle.com Wed Dec 13 14:29:42 2023 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 13 Dec 2023 09:29:42 -0500 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <5d633d71-798b-451c-8f01-c30f08f9bd68@oracle.com> Vote: Yes On 12/13/23 6:22 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. From ron.pressler at oracle.com Wed Dec 13 14:49:57 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 13 Dec 2023 14:49:57 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <7E0391E9-45F0-44B1-8684-7DEF5B372C17@oracle.com> Vote: yes > On 13 Dec 2023, at 11:22, Alan Bateman wrote: > > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of you will know him from past work on Akka, Reactive Streams, and his contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a truly wonderful enhancement to the streams API to support new intermediate stream operations. Aside from JEP 461, Viktor has contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From daniel.fuchs at oracle.com Wed Dec 13 14:51:33 2023 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Dec 2023 14:51:33 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: Yes best regards, -- daniel On 13/12/2023 11:22, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > From pavel.rappo at oracle.com Wed Dec 13 15:44:52 2023 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 13 Dec 2023 15:44:52 +0000 Subject: Release stabilization: Create backport issues immediately In-Reply-To: <20231213091848.160388671@eggemoggin.niobe.net> References: <20231213091848.160388671@eggemoggin.niobe.net> Message-ID: <774EC18C-4CF9-4022-A78B-1E36D81A834D@oracle.com> One disadvantage of the proposed adjustment I see is the need to create a JBS backport issue manually. (Unless I'm mistaken.) Not that it's difficult, but it's error-prone. In contrast, when using Skara /backport command, the JBS backport issue is created automatically. Why can't we just _forward port_ an issue to the main-line using the same Skara /backport command, but with the benefits of automation? Fix your issue in the stabilisation repo first and then forward port it to the main-line. In this case, you don't even need any additional approvals, right? Unless, of course, people object to having "Backport-of" commits in the main-line repo. (Speaking of which, we already have 25 of such commits there.) > On 13 Dec 2023, at 14:18, Mark Reinhold wrote: > > Last May, for JDK 21, we adopted Erik Duveblad?s proposal to use the > Skara backport mechanism to stabilize the release after RDP 1 [1][2]: > >> Erik proposes that we instead use the Skara backport mechanism, which >> we already use for update releases. To fix a bug in the release being >> stabilized you?d first create a PR against the main-line repository. >> Then, after that PR is reviewed and integrated, you?d use Skara?s >> `/backport` command to backport the fix to the stabilization repository. >> If your fix is intended only for the stabilization repository then you?d >> create a PR directly against that repository. > > This worked out reasonably well for JDK 21, except for one problem. > > Suppose that you have a candidate bug [3] that you want to fix in the > stabilization release (e.g., JDK 22). Before you merge the PR against > the main-line repository, you change the fix version of that bug to that > of the main-line release (e.g., JDK 23) so that Skara will close the > correct issue. This causes the bug to disappear from the results of the > candidate-bug queries [4] that we use to guide our work in the RDP 1, > RDP 2, and RC phases, leaving us at risk of losing track of the bug for > the stabilization release. > > In JDK 21, various Committers worked around this in different ways, for > example by using JIRA labels. The difficulty with labels is that you > have to remember to remove them when they?re no longer applicable, which > makes the overall process more complex. > > For JDK 22, let?s instead try the following small adjustment to the > integration procedure: > > To fix a bug in the stabilization release, first target that bug to > the main-line release and **immediately create a backport of the bug > and target the backport to the stabilization release.** Then create > a PR to integrate your fix into the main-line release. After you > have obtained any necessary approvals, backport the main-line PR to > the stabilization repository via the Skara `/backport` command. > > (As before, if your fix is intended only for the stabilization > repository then target the bug to the stabilization release and > create a PR directly against that repository.) > > We will also update the candidate-bug queries to include issues of type > ?Backport? as well as ?Bug?. These changes will ensure that a bug > relevant to the stabilization release remains on the appropriate > candidate-bug lists. Its issue number will change when the fix is > integrated into the main-line repository, but at least we won?t lose > track of it. > > Comments welcome, as always, but we?re already in RDP 1 so I suggest > that we start using this process immediately and adjust if necessary. > I?ve already updated the candidate-bug queries; I?ll update JEP 3 > shortly. > > - Mark > > > [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-April/007612.html > [2] https://mail.openjdk.org/pipermail/jdk-dev/2023-May/007822.html > [3] https://openjdk.org/jeps/3#Candidate-bugs > [4] https://j.mp/jdk-rdp-1, https://j.mp/jdk-rdp-2, https://j.mp/jdk-rc From michael.x.mcmahon at oracle.com Wed Dec 13 16:18:17 2023 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 13 Dec 2023 16:18:17 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: yes On 13/12/2023 11:22, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many > of you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], > a truly wonderful enhancement to the streams API to support new > intermediate stream operations.? Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this > nomination. Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at rivosinc.com Wed Dec 13 16:24:41 2023 From: tony at rivosinc.com (Tony Printezis) Date: Wed, 13 Dec 2023 11:24:41 -0500 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: yes Tony > On Dec 13, 2023, at 6:22?AM, Alan Bateman wrote: > > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of you will know him from past work on Akka, Reactive Streams, and his contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a truly wonderful enhancement to the streams API to support new intermediate stream operations. Aside from JEP 461, Viktor has contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From weijun.wang at oracle.com Wed Dec 13 16:41:00 2023 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Wed, 13 Dec 2023 16:41:00 +0000 Subject: Release stabilization: Create backport issues immediately In-Reply-To: <774EC18C-4CF9-4022-A78B-1E36D81A834D@oracle.com> References: <20231213091848.160388671@eggemoggin.niobe.net> <774EC18C-4CF9-4022-A78B-1E36D81A834D@oracle.com> Message-ID: <2E6978E3-2D17-48B0-BE85-52C075637767@oracle.com> Or, we can still fix in the main line first and backport it. Only, let Skara do something different. Suppose I keep the bug?s target to jdk22, currently the Skara bot is already able to notice it and shows a warning in the jdk23 PR. When the jdk23 PR is integrated, I wonder if the bot can: 1. Change the JBS target to 23, where the fix is integrated 2. Create a backport for 22, which is the original target If I remember correctly, its current behavior is to keep the original bug unchanged and create a ?backport? for jdk23. If we believe that backport is always backward, this should be fixed anyway. If we believe a backport can be forward, then all is fine. The bug id used in the comment is still the non-backport one. Thanks, Weijun p.s. From what Mark said "so that Skara will close the correct issue", it seems backport should only be backward. > On Dec 13, 2023, at 10:44?AM, Pavel Rappo wrote: > > One disadvantage of the proposed adjustment I see is the need to create a JBS backport issue manually. (Unless I'm mistaken.) Not that it's difficult, but it's error-prone. In contrast, when using Skara /backport command, the JBS backport issue is created automatically. > > Why can't we just _forward port_ an issue to the main-line using the same Skara /backport command, but with the benefits of automation? Fix your issue in the stabilisation repo first and then forward port it to the main-line. In this case, you don't even need any additional approvals, right? Unless, of course, people object to having "Backport-of" commits in the main-line repo. (Speaking of which, we already have 25 of such commits there.) > >> On 13 Dec 2023, at 14:18, Mark Reinhold wrote: >> >> Last May, for JDK 21, we adopted Erik Duveblad?s proposal to use the >> Skara backport mechanism to stabilize the release after RDP 1 [1][2]: >> >>> Erik proposes that we instead use the Skara backport mechanism, which >>> we already use for update releases. To fix a bug in the release being >>> stabilized you?d first create a PR against the main-line repository. >>> Then, after that PR is reviewed and integrated, you?d use Skara?s >>> `/backport` command to backport the fix to the stabilization repository. >>> If your fix is intended only for the stabilization repository then you?d >>> create a PR directly against that repository. >> >> This worked out reasonably well for JDK 21, except for one problem. >> >> Suppose that you have a candidate bug [3] that you want to fix in the >> stabilization release (e.g., JDK 22). Before you merge the PR against >> the main-line repository, you change the fix version of that bug to that >> of the main-line release (e.g., JDK 23) so that Skara will close the >> correct issue. This causes the bug to disappear from the results of the >> candidate-bug queries [4] that we use to guide our work in the RDP 1, >> RDP 2, and RC phases, leaving us at risk of losing track of the bug for >> the stabilization release. >> >> In JDK 21, various Committers worked around this in different ways, for >> example by using JIRA labels. The difficulty with labels is that you >> have to remember to remove them when they?re no longer applicable, which >> makes the overall process more complex. >> >> For JDK 22, let?s instead try the following small adjustment to the >> integration procedure: >> >> To fix a bug in the stabilization release, first target that bug to >> the main-line release and **immediately create a backport of the bug >> and target the backport to the stabilization release.** Then create >> a PR to integrate your fix into the main-line release. After you >> have obtained any necessary approvals, backport the main-line PR to >> the stabilization repository via the Skara `/backport` command. >> >> (As before, if your fix is intended only for the stabilization >> repository then target the bug to the stabilization release and >> create a PR directly against that repository.) >> >> We will also update the candidate-bug queries to include issues of type >> ?Backport? as well as ?Bug?. These changes will ensure that a bug >> relevant to the stabilization release remains on the appropriate >> candidate-bug lists. Its issue number will change when the fix is >> integrated into the main-line repository, but at least we won?t lose >> track of it. >> >> Comments welcome, as always, but we?re already in RDP 1 so I suggest >> that we start using this process immediately and adjust if necessary. >> I?ve already updated the candidate-bug queries; I?ll update JEP 3 >> shortly. >> >> - Mark >> >> >> [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-April/007612.html >> [2] https://mail.openjdk.org/pipermail/jdk-dev/2023-May/007822.html >> [3] https://openjdk.org/jeps/3#Candidate-bugs >> [4] https://j.mp/jdk-rdp-1, https://j.mp/jdk-rdp-2, https://j.mp/jdk-rc > > From mandy.chung at oracle.com Wed Dec 13 16:56:42 2023 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 13 Dec 2023 08:56:42 -0800 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: yes Mandy On 12/13/23 3:22 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > From serguei.spitsyn at oracle.com Wed Dec 13 16:58:27 2023 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Wed, 13 Dec 2023 16:58:27 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: yes -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Dec 13 17:29:18 2023 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 13 Dec 2023 09:29:18 -0800 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <7ede2d21-b915-4353-b91b-32243caabb2d@oracle.com> Vote: yes -Joe On 12/13/2023 3:22 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many > of you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], > a truly wonderful enhancement to the streams API to support new > intermediate stream operations.? Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this > nomination. Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From mikael.vidstedt at oracle.com Wed Dec 13 17:41:09 2023 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 13 Dec 2023 17:41:09 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <67318CA9-0971-4EA4-8681-CC6BF3B3FAC2@oracle.com> Vote: yes Cheers, Mikael > On Dec 13, 2023, at 3:22?AM, Alan Bateman wrote: > > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of you will know him from past work on Akka, Reactive Streams, and his contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a truly wonderful enhancement to the streams API to support new intermediate stream operations. Aside from JEP 461, Viktor has contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From brian.burkhalter at oracle.com Wed Dec 13 17:41:37 2023 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 13 Dec 2023 17:41:37 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: yes From naoto.sato at oracle.com Wed Dec 13 17:43:35 2023 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 13 Dec 2023 09:43:35 -0800 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <3d43d5ae-7520-488d-8936-0f8b6d80c250@oracle.com> Vote: yes Naoto On 12/13/23 3:22 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of > you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a > truly wonderful enhancement to the streams API to support new > intermediate stream operations.? Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From brent.christian at oracle.com Wed Dec 13 17:49:35 2023 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 13 Dec 2023 09:49:35 -0800 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <8727815d-18b3-4bca-a69a-e3d6604f99a0@oracle.com> Vote: Yes On 12/13/23 3:22 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > From jorn.vernee at oracle.com Wed Dec 13 18:12:03 2023 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Wed, 13 Dec 2023 19:12:03 +0100 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: vote: yes Jorn On 13/12/2023 12:22, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many > of you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], > a truly wonderful enhancement to the streams API to support new > intermediate stream operations.? Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this > nomination. Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From dean.long at oracle.com Wed Dec 13 20:25:13 2023 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 13 Dec 2023 12:25:13 -0800 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: yes On 12/13/23 3:22 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many > of you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], > a truly wonderful enhancement to the streams API to support new > intermediate stream operations.? Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this > nomination. Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From mark.reinhold at oracle.com Wed Dec 13 22:18:41 2023 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 13 Dec 2023 22:18:41 +0000 Subject: Release stabilization: Create backport issues immediately In-Reply-To: <2E6978E3-2D17-48B0-BE85-52C075637767@oracle.com> References: <20231213091848.160388671@eggemoggin.niobe.net> <774EC18C-4CF9-4022-A78B-1E36D81A834D@oracle.com> <2E6978E3-2D17-48B0-BE85-52C075637767@oracle.com> Message-ID: <20231213171839.733197635@eggemoggin.niobe.net> 2023/12/13 11:41:00 -0500, weijun.wang at oracle.com: > Or, we can still fix in the main line first and backport it. Only, let > Skara do something different. > > Suppose I keep the bug?s target to jdk22, currently the Skara bot is > already able to notice it and shows a warning in the jdk23 PR. When > the jdk23 PR is integrated, I wonder if the bot can: > > 1. Change the JBS target to 23, where the fix is integrated > 2. Create a backport for 22, which is the original target > > If I remember correctly, its current behavior is to keep the original > bug unchanged and create a ?backport? for jdk23. If we believe that > backport is always backward, this should be fixed anyway. If we > believe a backport can be forward, then all is fine. The bug id used > in the comment is still the non-backport one. Arranging for a Skara bot to do something like this would require non-trivial logic which we don?t have time to implement for JDK 22. We?ll see how it goes this time with the tweaked process and consider other possibilities later. - Mark From mark.reinhold at oracle.com Wed Dec 13 22:21:17 2023 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 13 Dec 2023 22:21:17 +0000 Subject: Release stabilization: Create backport issues immediately In-Reply-To: <774EC18C-4CF9-4022-A78B-1E36D81A834D@oracle.com> References: <20231213091848.160388671@eggemoggin.niobe.net> <774EC18C-4CF9-4022-A78B-1E36D81A834D@oracle.com> Message-ID: <20231213172115.670752010@eggemoggin.niobe.net> 2023/12/13 10:44:52 -0500, pavel.rappo at oracle.com: > One disadvantage of the proposed adjustment I see is the need to > create a JBS backport issue manually. (Unless I'm mistaken.) Not that > it's difficult, but it's error-prone. In contrast, when using Skara > /backport command, the JBS backport issue is created automatically. > > Why can't we just _forward port_ an issue to the main-line using the > same Skara /backport command, but with the benefits of automation? Fix > your issue in the stabilisation repo first and then forward port it to > the main-line. In this case, you don't even need any additional > approvals, right? Unless, of course, people object to having > "Backport-of" commits in the main-line repo. (Speaking of which, we > already have 25 of such commits there.) That?s (roughly) what we used to do, and it wasn?t working terribly well, which is why Erik proposed the backport-from-main-line model that we discussed and adopted as of JDK 21. - Mark From dean.long at oracle.com Thu Dec 14 01:52:14 2023 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 13 Dec 2023 17:52:14 -0800 Subject: Release stabilization: Create backport issues immediately In-Reply-To: <20231213091848.160388671@eggemoggin.niobe.net> References: <20231213091848.160388671@eggemoggin.niobe.net> Message-ID: On 12/13/23 6:18 AM, Mark Reinhold wrote: > To fix a bug in the stabilization release, first target that bug to > the main-line release and **immediately create a backport of the bug > and target the backport to the stabilization release.** Then create > a PR to integrate your fix into the main-line release. After you > have obtained any necessary approvals, backport the main-line PR to > the stabilization repository via the Skara `/backport` command. JIRA seems to allow multiple Fix Versions, so I'm wondering if the fix versions were set to main-line /and/ 22, would Skara PR logic and candidate-bug queries do the right thing, or would it just cause more confusion? dl -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Dec 14 08:12:38 2023 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Dec 2023 18:12:38 +1000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: yes David On 13/12/2023 9:22 pm, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of > you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a > truly wonderful enhancement to the streams API to support new > intermediate stream operations.? Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From david.holmes at oracle.com Thu Dec 14 08:20:33 2023 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Dec 2023 18:20:33 +1000 Subject: Release stabilization: Create backport issues immediately In-Reply-To: References: <20231213091848.160388671@eggemoggin.niobe.net> Message-ID: <7342ae97-b765-48c2-819d-6c42835605ef@oracle.com> On 14/12/2023 11:52 am, dean.long at oracle.com wrote: > On 12/13/23 6:18 AM, Mark Reinhold wrote: > >> To fix a bug in the stabilization release, first target that bug to >> the main-line release and **immediately create a backport of the bug >> and target the backport to the stabilization release.** Then create >> a PR to integrate your fix into the main-line release. After you >> have obtained any necessary approvals, backport the main-line PR to >> the stabilization repository via the Skara `/backport` command. > > > JIRA seems to allow multiple Fix Versions, so I'm wondering if the fix > versions were set to main-line /and/ 22, would Skara PR logic and > candidate-bug queries do the right thing, or would it just cause more > confusion? JIRA allows it but we do not. Only CSR requests can have multiple fix-versions. If they occur in bugs/enhancements it is an error. Cheers, David > dl > From adinn at redhat.com Thu Dec 14 11:40:23 2023 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 14 Dec 2023 11:40:23 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <852772b8-a5bc-3924-e393-52261778aebd@redhat.com> Vote: yes On 13/12/2023 11:22, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of > you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a > truly wonderful enhancement to the streams API to support new > intermediate stream operations.? Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From volker.simonis at gmail.com Thu Dec 14 12:01:05 2023 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 14 Dec 2023 13:01:05 +0100 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: yes Alan Bateman schrieb am Mi., 13. Dez. 2023, 12:23: > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of > you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a > truly wonderful enhancement to the streams API to support new > intermediate stream operations. Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neugens at redhat.com Thu Dec 14 12:04:30 2023 From: neugens at redhat.com (Mario Torre) Date: Thu, 14 Dec 2023 13:04:30 +0100 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: Yes Cheers, Mario On Wed, Dec 13, 2023 at 12:24?PM Alan Bateman wrote: > > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of > you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a > truly wonderful enhancement to the streams API to support new > intermediate stream operations. Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote > -- Mario Torre Manager, Software Engineering, Red Hat OpenJDK, Java Champion https://keybase.io/neugens 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 Mastodon: https://mastodon.social/@MarioTorre Red Hat GmbH, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243, Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross From tobias.holenstein at oracle.com Thu Dec 14 12:05:32 2023 From: tobias.holenstein at oracle.com (Tobias Holenstein) Date: Thu, 14 Dec 2023 12:05:32 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <0805F0F4-362F-4F12-BBE2-2198AD60E8ED@oracle.com> Vote: yes - Toby > On Dec 13, 2023, at 12:22, Alan Bateman wrote: > > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of you will know him from past work on Akka, Reactive Streams, and his contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a truly wonderful enhancement to the streams API to support new intermediate stream operations. Aside from JEP 461, Viktor has contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From kevin.rushforth at oracle.com Thu Dec 14 12:13:25 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Dec 2023 04:13:25 -0800 Subject: Release stabilization: Create backport issues immediately In-Reply-To: References: <20231213091848.160388671@eggemoggin.niobe.net> Message-ID: <31ab0f11-330e-4cbb-9962-a5a33f95b0d4@oracle.com> That would just cause more confusion. None of our tools or queries are set up to work well in the presence of multiple fix versions. -- Kevin On 12/13/2023 5:52 PM, dean.long at oracle.com wrote: > > On 12/13/23 6:18 AM, Mark Reinhold wrote: > >> To fix a bug in the stabilization release, first target that bug to >> the main-line release and **immediately create a backport of the bug >> and target the backport to the stabilization release.** Then create >> a PR to integrate your fix into the main-line release. After you >> have obtained any necessary approvals, backport the main-line PR to >> the stabilization repository via the Skara `/backport` command. > > > JIRA seems to allow multiple Fix Versions, so I'm wondering if the fix > versions were set to main-line /and/ 22, would Skara PR logic and > candidate-bug queries do the right thing, or would it just cause more > confusion? > > dl > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Thu Dec 14 16:19:04 2023 From: adam.sotona at oracle.com (Adam Sotona) Date: Thu, 14 Dec 2023 16:19:04 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: yes From: jdk-dev on behalf of Alan Bateman Date: Wednesday, 13 December 2023 at 12:23 To: jdk-dev Subject: CFV: New JDK Committer: Viktor Klang I hereby nominate Viktor Klang to JDK Committer. Viktor has been a member of the Java team in Oracle since 2022. Many of you will know him from past work on Akka, Reactive Streams, and his contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a truly wonderful enhancement to the streams API to support new intermediate stream operations. Aside from JEP 461, Viktor has contributed 19 other changes so far [2][3]. Votes are due by December 27, 2023, 23.59 UTC. Only current JDK Committers [4] are eligible to vote on this nomination. Votes must cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. -Alan [1] https://openjdk.org/jeps/461 [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora [4] https://openjdk.org/census [5] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Dec 14 19:38:41 2023 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 14 Dec 2023 11:38:41 -0800 Subject: Release stabilization: Create backport issues immediately In-Reply-To: <31ab0f11-330e-4cbb-9962-a5a33f95b0d4@oracle.com> References: <20231213091848.160388671@eggemoggin.niobe.net> <31ab0f11-330e-4cbb-9962-a5a33f95b0d4@oracle.com> Message-ID: <7913edef-fc40-4c87-8f96-104680da8ecd@oracle.com> To summarize the multi-release model used in JBS, while Jira does allow multiple values for the fixVersions field, we viewed that as inadequate for bug management purposes. For example, we want to know status of the bug _for a given release_, what build the fix is present in _for a given release_, etc. Since Jira does not offer a per-release tuple like (status, fixed-in-build, ...) we implement this functionality using separate backport issues. When the CSR process was first rolled out, we followed the general guidance of only using a single release values, but the constraints of a CSR are different and using a single CSR for multiple releases, subject to the requirements discussed in the CSR wiki page, was a least-bad option. HTH, -Joe On 12/14/2023 4:13 AM, Kevin Rushforth wrote: > That would just cause more confusion. None of our tools or queries are > set up to work well in the presence of multiple fix versions. > > -- Kevin > > > On 12/13/2023 5:52 PM, dean.long at oracle.com wrote: >> >> On 12/13/23 6:18 AM, Mark Reinhold wrote: >> >>> To fix a bug in the stabilization release, first target that bug to >>> the main-line release and **immediately create a backport of the bug >>> and target the backport to the stabilization release.** Then create >>> a PR to integrate your fix into the main-line release. After you >>> have obtained any necessary approvals, backport the main-line PR to >>> the stabilization repository via the Skara `/backport` command. >> >> >> JIRA seems to allow multiple Fix Versions, so I'm wondering if the >> fix versions were set to main-line /and/ 22, would Skara PR logic and >> candidate-bug queries do the right thing, or would it just cause more >> confusion? >> >> dl >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From huizhe.wang at oracle.com Thu Dec 14 20:02:32 2023 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 14 Dec 2023 12:02:32 -0800 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: Yes Joe (joehw) On 12/13/23 3:22 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. From philip.race at oracle.com Thu Dec 14 22:07:41 2023 From: philip.race at oracle.com (Philip Race) Date: Thu, 14 Dec 2023 14:07:41 -0800 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <1cb19711-3c3b-4c21-ad87-29b9adcc2eda@oracle.com> Vote: yes -phil. From paul.sandoz at oracle.com Thu Dec 14 22:14:42 2023 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 14 Dec 2023 22:14:42 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: ? (yes) Paul. From stefan at selessia.com Fri Dec 15 18:50:19 2023 From: stefan at selessia.com (Stefan Norberg) Date: Fri, 15 Dec 2023 19:50:19 +0100 Subject: Regexp with word-boundary followed by unicode character doesn't work in 19, 21 Message-ID: Hi, I apologize in advance if this isn't the right forum for posting a bug report. If not, feel free to point me in the right direction! The following test works in 17 but fails in 19, and 21 on the last assertion. Bug or feature? import org.junit.jupiter.api.Assertions; import org.junit.jupiter.api.Test; import java.util.ArrayList; import java.util.regex.Matcher; import java.util.regex.Pattern; /** * Tests passes in JDK 17 but fails in JDK 19, 21. * * The combination of a \b "word boundary" and a unicode char doesn't seem to work in 19, 21. * */ public class UnicodeTest { @Test public void testRegexp() throws Exception { var text = "En sak som ?kas och sedan minskas. Bra va!"; var word = "?kas"; Assertions.assertTrue(text.contains(word)); Pattern p = Pattern.compile("(\\b" + word + "\\b)"); Matcher m = p.matcher(text); var matches = new ArrayList<>(); while (m.find()) { String matchString = m.group(); System.out.println(matchString); matches.add(matchString); } Assertions.assertEquals(1, matches.size()); } } openjdk version "21.0.1" 2023-10-17 LTS OpenJDK Runtime Environment Corretto-21.0.1.12.1 (build 21.0.1+12-LTS) OpenJDK 64-Bit Server VM Corretto-21.0.1.12.1 (build 21.0.1+12-LTS, mixed mode, sharing) System Version: macOS 14.2 (23C64) Kernel Version: Darwin 23.2.0 Model Name: MacBook Pro Model Identifier: Mac14,6 Model Number: Z175000DEKS/A Chip: Apple M2 Max Total Number of Cores: 12 (8 performance and 4 efficiency) Memory: 64 GB /Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Fri Dec 15 18:59:47 2023 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Fri, 15 Dec 2023 18:59:47 +0000 Subject: Regexp with word-boundary followed by unicode character doesn't work in 19, 21 In-Reply-To: References: Message-ID: <20231215135945.275176164@eggemoggin.niobe.net> 2023/12/15 13:50:19 -0500, stefan at selessia.com: > I apologize in advance if this isn't the right forum for posting a bug > report. If not, feel free to point me in the right direction! core-libs-dev at openjdk.org. - Mark From jai.forums2013 at gmail.com Mon Dec 18 08:34:00 2023 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 18 Dec 2023 14:04:00 +0530 Subject: Result: New JDK Committer: Eirik Bjorsnos Message-ID: Voting for Eirik Bjorsnos [1] is now closed. Yes: 16 Veto: 0 Abstain: 0 (one duplicate "yes" vote was excluded) According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-November/008474.html -Jaikiran From stuart.marks at oracle.com Tue Dec 19 04:35:50 2023 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 18 Dec 2023 20:35:50 -0800 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <42291329-edad-1ce2-7205-0636a73e08bb@oracle.com> Vote: yes On 12/13/23 3:22 AM, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of you will > know him from past work on Akka, Reactive Streams, and his contributions in the > Scala world. For JDK 22, Viktor lead JEP 461 [1], a truly wonderful enhancement to > the streams API to support new intermediate stream operations.? Aside from JEP 461, > Viktor has contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. Votes must > cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From maurizio.cimadamore at oracle.com Tue Dec 19 16:10:51 2023 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 19 Dec 2023 16:10:51 +0000 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: yes! On 13/12/2023 11:22, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many > of you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], > a truly wonderful enhancement to the streams API to support new > intermediate stream operations.? Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this > nomination. Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From tanksherman27 at gmail.com Wed Dec 20 09:19:10 2023 From: tanksherman27 at gmail.com (Julian Waters) Date: Wed, 20 Dec 2023 17:19:10 +0800 Subject: Windows/UCRT64 Port Message-ID: Hi all, I'm proud to announce on behalf of the MinGW64-MSYS2 Project that a working port of the Windows JDK (fastdebug) is now available for the UCRT64 subsystem, the binaries are available in the attachment on this post. The JDK port is still rough around the edges, and some support for it still has to be upstreamed into the MinGW Project itself, but for the most part, the experimental port is complete and should be fully functional. The experimental JDK itself for now has to be run within the UCRT64 subsystem, and you may need to install the gcc compiler support libraries for it to run properly (pacman -S mingw-w64-ucrt-x86_64-gcc), but this restriction will be removed soon (It's in place due to a current limitation in the winpthreads threading library). We will be working on improving the code for this port moving forward. It is hoped that we will be able to package the JDK for the UCRT64 subsystem once several blocking issues have been resolved, to provide numerous developers working with MSYS2 and MINGW64 a working JDK. The JDK was compiled with gcc 13.2.0. If you're curious, the code for the port can be found here: https://github.com/openjdk/jdk/compare/master...TheShermanTanker%3ajdk%3acompiler I'm excited to share our work thus far with the JDK community, and any opinions are welcome. Try out the debug binaries, give me a shout if you find anything, a heads up on bugs we may have missed is greatly appreciated! best regards, Julian jdk.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkennke at amazon.de Wed Dec 20 13:26:42 2023 From: rkennke at amazon.de (Kennke, Roman) Date: Wed, 20 Dec 2023 13:26:42 +0000 Subject: CFV: New JDK Committer: Markus Karg Message-ID: <5BD8B4CC-79FC-47CD-9A2E-CBAAD4628C04@amazon.de> I hereby nominate Markus Karg to JDK Committer. Markus Karg has been a contributor to the JDK project since more than 2 years and has contributed more than a dozen improvements and fixes, centering around performance in the (N)IO libraries: https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Amkarg+label%3Aintegrated From Mark: "Besides OpenJDK, Markus ist committed to Open Source, and especially to Java, since decades. Just to name a few engagements out of many: As a committer to the Jakarta REST project, he is co-author of the JAX-RS specification. He is committer and release manager of the JCommander CLI library. He frequently contributed to dozens of Open Source projects, including Maven, Liquibase, Jersey, EclipseLink, PGJDBC, and many more. In his sparetime he writes articles for (mostly German) technical journals and volunteers at the advisory cimmittee of some of them. Markus is part of the organization committee of the German "JavaLand" conference, a very active iJUG member (e. g. in the role of iJUG's vice ambassador at the Eclipse Foundation) and founder and lead of a local JUG, and gave numerous talks at conferences and JUGs. Since few years, he is running his own Youtube channel covering Java and particularly JAX-RS.? Votes are due by Jan-04 2024. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Roman Kennke [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 From sgehwolf at redhat.com Wed Dec 20 15:20:39 2023 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 20 Dec 2023 16:20:39 +0100 Subject: CFV: New JDK Committer: Markus Karg In-Reply-To: <5BD8B4CC-79FC-47CD-9A2E-CBAAD4628C04@amazon.de> References: <5BD8B4CC-79FC-47CD-9A2E-CBAAD4628C04@amazon.de> Message-ID: <710e315b154a0e33d91b3cba9d0e579554b3b681.camel@redhat.com> Vote: yes On Wed, 2023-12-20 at 13:26 +0000, Kennke, Roman wrote: > I hereby nominate Markus Karg to JDK Committer. From raffaello.giulietti at oracle.com Wed Dec 20 17:31:11 2023 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Wed, 20 Dec 2023 18:31:11 +0100 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: Vote: yes On 2023-12-13 12:22, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. > > Viktor has been a member of the Java team in Oracle since 2022. Many of > you will know him from past work on Akka, Reactive Streams, and his > contributions in the Scala world. For JDK 22, Viktor lead JEP 461 [1], a > truly wonderful enhancement to the streams API to support new > intermediate stream operations.? Aside from JEP 461, Viktor has > contributed 19 other changes so far [2][3]. > > Votes are due by December 27, 2023, 23.59 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -Alan > > [1] https://openjdk.org/jeps/461 > [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org > [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora > [4] https://openjdk.org/census > [5] https://openjdk.org/projects/#committer-vote From james.laskey at oracle.com Wed Dec 20 23:11:50 2023 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 20 Dec 2023 23:11:50 +0000 Subject: CFV: New JDK Committer: Markus Karg In-Reply-To: <5BD8B4CC-79FC-47CD-9A2E-CBAAD4628C04@amazon.de> References: <5BD8B4CC-79FC-47CD-9A2E-CBAAD4628C04@amazon.de> Message-ID: <5FF5A67F-D151-43FE-93D8-4FD5133B4F94@oracle.com> Vote: veto This is the time of the year when many committers are on holidays and not available to vote. Please renominate in January when you can get a reasonable number of voters. Thank you. Cheers, ? Jim > On 20 Dec 2023, at 09:26, Kennke, Roman wrote: > > I hereby nominate Markus Karg to JDK Committer. > > Markus Karg has been a contributor to the JDK project since more than 2 years and has contributed more than a dozen improvements and fixes, centering around performance in the (N)IO libraries: > https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Amkarg+label%3Aintegrated > > From Mark: "Besides OpenJDK, Markus ist committed to Open Source, and especially to Java, since decades. Just to name a few engagements out of many: As a committer to the Jakarta REST project, he is co-author of the JAX-RS specification. He is committer and release manager of the JCommander CLI library. He frequently contributed to dozens of Open Source projects, including Maven, Liquibase, Jersey, EclipseLink, PGJDBC, and many more. In his sparetime he writes articles for (mostly German) technical journals and volunteers at the advisory cimmittee of some of them. Markus is part of the organization committee of the German "JavaLand" conference, a very active iJUG member (e. g. in the role of iJUG's vice ambassador at the Eclipse Foundation) and founder and lead of a local JUG, and gave numerous talks at conferences and JUGs. Since few years, he is running his own Youtube channel covering Java and particularly JAX-RS.? > > > Votes are due by Jan-04 2024. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Roman Kennke > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#committer-vote > > > > Amazon Development Center Germany GmbH > Krausenstr. 38 > 10117 Berlin > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > Sitz: Berlin > Ust-ID: DE 289 237 879 > > From joe.darcy at oracle.com Wed Dec 20 23:37:02 2023 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 20 Dec 2023 15:37:02 -0800 Subject: CFV: New JDK Committer: Markus Karg In-Reply-To: <5FF5A67F-D151-43FE-93D8-4FD5133B4F94@oracle.com> References: <5BD8B4CC-79FC-47CD-9A2E-CBAAD4628C04@amazon.de> <5FF5A67F-D151-43FE-93D8-4FD5133B4F94@oracle.com> Message-ID: I concur with Jim that this kind of vote is better conducted in January. (If you look at the JDK commit activity graph, the only consistent deep valley are during the end-of-year period.) -Joe On 12/20/2023 3:11 PM, Jim Laskey wrote: > Vote: veto > > This is the time of the year when many committers are on holidays and not available to vote. Please renominate in January when you can get a reasonable number of voters. Thank you. > > Cheers, > > ? Jim > > > > >> On 20 Dec 2023, at 09:26, Kennke, Roman wrote: >> >> I hereby nominate Markus Karg to JDK Committer. >> >> Markus Karg has been a contributor to the JDK project since more than 2 years and has contributed more than a dozen improvements and fixes, centering around performance in the (N)IO libraries: >> https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Amkarg+label%3Aintegrated >> >> From Mark: "Besides OpenJDK, Markus ist committed to Open Source, and especially to Java, since decades. Just to name a few engagements out of many: As a committer to the Jakarta REST project, he is co-author of the JAX-RS specification. He is committer and release manager of the JCommander CLI library. He frequently contributed to dozens of Open Source projects, including Maven, Liquibase, Jersey, EclipseLink, PGJDBC, and many more. In his sparetime he writes articles for (mostly German) technical journals and volunteers at the advisory cimmittee of some of them. Markus is part of the organization committee of the German "JavaLand" conference, a very active iJUG member (e. g. in the role of iJUG's vice ambassador at the Eclipse Foundation) and founder and lead of a local JUG, and gave numerous talks at conferences and JUGs. Since few years, he is running his own Youtube channel covering Java and particularly JAX-RS.? >> >> >> Votes are due by Jan-04 2024. >> >> Only current JDK Committers [1] are eligible to vote >> on this nomination. Votes must be cast in the open by replying >> to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Roman Kennke >> >> [1] https://openjdk.org/census >> [2] https://openjdk.org/projects/#committer-vote >> >> >> >> Amazon Development Center Germany GmbH >> Krausenstr. 38 >> 10117 Berlin >> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss >> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B >> Sitz: Berlin >> Ust-ID: DE 289 237 879 >> >> From thomas.stuefe at gmail.com Thu Dec 21 08:02:58 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 21 Dec 2023 09:02:58 +0100 Subject: CFV: New JDK Committer: Markus Karg In-Reply-To: <5BD8B4CC-79FC-47CD-9A2E-CBAAD4628C04@amazon.de> References: <5BD8B4CC-79FC-47CD-9A2E-CBAAD4628C04@amazon.de> Message-ID: Vote: yes On Wed, Dec 20, 2023 at 4:01?PM Kennke, Roman wrote: > I hereby nominate Markus Karg to JDK Committer. > > Markus Karg has been a contributor to the JDK project since more than 2 > years and has contributed more than a dozen improvements and fixes, > centering around performance in the (N)IO libraries: > > https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Amkarg+label%3Aintegrated > > From Mark: "Besides OpenJDK, Markus ist committed to Open Source, and > especially to Java, since decades. Just to name a few engagements out of > many: As a committer to the Jakarta REST project, he is co-author of the > JAX-RS specification. He is committer and release manager of the JCommander > CLI library. He frequently contributed to dozens of Open Source projects, > including Maven, Liquibase, Jersey, EclipseLink, PGJDBC, and many more. In > his sparetime he writes articles for (mostly German) technical journals and > volunteers at the advisory cimmittee of some of them. Markus is part of the > organization committee of the German "JavaLand" conference, a very active > iJUG member (e. g. in the role of iJUG's vice ambassador at the Eclipse > Foundation) and founder and lead of a local JUG, and gave numerous talks at > conferences and JUGs. Since few years, he is running his own Youtube > channel covering Java and particularly JAX-RS.? > > > Votes are due by Jan-04 2024. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Roman Kennke > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#committer-vote > > > > Amazon Development Center Germany GmbH > Krausenstr. 38 > 10117 Berlin > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > Sitz: Berlin > Ust-ID: DE 289 237 879 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Dec 21 08:04:10 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 21 Dec 2023 09:04:10 +0100 Subject: CFV: New JDK Committer: Markus Karg In-Reply-To: References: <5BD8B4CC-79FC-47CD-9A2E-CBAAD4628C04@amazon.de> Message-ID: Oh, I missed Jim's veto. Yes, it makes sense to shift the voting to next year. On Thu, Dec 21, 2023 at 9:02?AM Thomas St?fe wrote: > Vote: yes > > On Wed, Dec 20, 2023 at 4:01?PM Kennke, Roman wrote: > >> I hereby nominate Markus Karg to JDK Committer. >> >> Markus Karg has been a contributor to the JDK project since more than 2 >> years and has contributed more than a dozen improvements and fixes, >> centering around performance in the (N)IO libraries: >> >> https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Amkarg+label%3Aintegrated >> >> From Mark: "Besides OpenJDK, Markus ist committed to Open Source, and >> especially to Java, since decades. Just to name a few engagements out of >> many: As a committer to the Jakarta REST project, he is co-author of the >> JAX-RS specification. He is committer and release manager of the JCommander >> CLI library. He frequently contributed to dozens of Open Source projects, >> including Maven, Liquibase, Jersey, EclipseLink, PGJDBC, and many more. In >> his sparetime he writes articles for (mostly German) technical journals and >> volunteers at the advisory cimmittee of some of them. Markus is part of the >> organization committee of the German "JavaLand" conference, a very active >> iJUG member (e. g. in the role of iJUG's vice ambassador at the Eclipse >> Foundation) and founder and lead of a local JUG, and gave numerous talks at >> conferences and JUGs. Since few years, he is running his own Youtube >> channel covering Java and particularly JAX-RS.? >> >> >> Votes are due by Jan-04 2024. >> >> Only current JDK Committers [1] are eligible to vote >> on this nomination. Votes must be cast in the open by replying >> to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Roman Kennke >> >> [1] https://openjdk.org/census >> [2] https://openjdk.org/projects/#committer-vote >> >> >> >> Amazon Development Center Germany GmbH >> Krausenstr. 38 >> 10117 Berlin >> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss >> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B >> Sitz: Berlin >> Ust-ID: DE 289 237 879 >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Dec 21 08:17:51 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Dec 2023 08:17:51 +0000 Subject: CFV: New JDK Committer: Markus Karg In-Reply-To: <5FF5A67F-D151-43FE-93D8-4FD5133B4F94@oracle.com> References: <5BD8B4CC-79FC-47CD-9A2E-CBAAD4628C04@amazon.de> <5FF5A67F-D151-43FE-93D8-4FD5133B4F94@oracle.com> Message-ID: <4b9ad8e0-19fc-40fb-a889-7de1634567b4@oracle.com> On 20/12/2023 23:11, Jim Laskey wrote: > Vote: veto > > This is the time of the year when many committers are on holidays and not available to vote. Please renominate in January when you can get a reasonable number of voters. Thank you. > The timing of this vote is indeed awkward as many Committers do shut down for this time of the year. A CFV requires the nominator to be responsive to questions or objections during the voting period so this one requires Roman to be responsive during this time too. I don't think CFV timing has been used as a veto justification before now. In any case, it means Roman needs to convince Jim to recast his vote, or else withdraw the nomination and start another CFV in the new year. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkennke at amazon.de Thu Dec 21 11:03:21 2023 From: rkennke at amazon.de (Kennke, Roman) Date: Thu, 21 Dec 2023 11:03:21 +0000 Subject: CFV: New JDK Committer: Markus Karg In-Reply-To: <5BD8B4CC-79FC-47CD-9A2E-CBAAD4628C04@amazon.de> References: <5BD8B4CC-79FC-47CD-9A2E-CBAAD4628C04@amazon.de> Message-ID: I hereby withdraw this CFV due to bad timing. I?ll re-post it when holiday season is over. Thanks for pointing it out! Roman > On Dec 20, 2023, at 2:26 PM, Kennke, Roman wrote: > > I hereby nominate Markus Karg to JDK Committer. > > Markus Karg has been a contributor to the JDK project since more than 2 years and has contributed more than a dozen improvements and fixes, centering around performance in the (N)IO libraries: > https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Amkarg+label%3Aintegrated > > From Mark: "Besides OpenJDK, Markus ist committed to Open Source, and especially to Java, since decades. Just to name a few engagements out of many: As a committer to the Jakarta REST project, he is co-author of the JAX-RS specification. He is committer and release manager of the JCommander CLI library. He frequently contributed to dozens of Open Source projects, including Maven, Liquibase, Jersey, EclipseLink, PGJDBC, and many more. In his sparetime he writes articles for (mostly German) technical journals and volunteers at the advisory cimmittee of some of them. Markus is part of the organization committee of the German "JavaLand" conference, a very active iJUG member (e. g. in the role of iJUG's vice ambassador at the Eclipse Foundation) and founder and lead of a local JUG, and gave numerous talks at conferences and JUGs. Since few years, he is running his own Youtube channel covering Java and particularly JAX-RS.? > > > Votes are due by Jan-04 2024. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Roman Kennke > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#committer-vote Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 From zjx001202 at gmail.com Sat Dec 23 18:18:45 2023 From: zjx001202 at gmail.com (Glavo) Date: Sun, 24 Dec 2023 02:18:45 +0800 Subject: The default java.library.path on Linux does not include the library paths in the mulitarch-spec Message-ID: Hi, There are already many Linux distributions that are following the multiarch-spec[1] and adding the following paths to the default library path list: - /usr/local/lib/ - /lib/ - /usr/lib/ But OpenJDK doesn't add these paths to the java.library.path by default, so System.loadLibrary(String) has annoying behavior differences with ld. Many libraries already installed on the system cannot be found by System.loadLibrary(String). I wish OpenJDK would parse the /etc/ld.so.conf to get the full library path list so it would be consistent with the behavior of ld. Can anyone consider this suggestion? Glavo [1]: https://wiki.ubuntu.com/MultiarchSpec -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Thu Dec 28 06:40:34 2023 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 27 Dec 2023 22:40:34 -0800 Subject: CFV: New JDK Committer: Viktor Klang In-Reply-To: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> References: <73fcab65-39bb-4276-b3d5-3fa4329c5b8c@oracle.com> Message-ID: <743c31cd-7a16-48de-aa1e-440aa100c9ca@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 12/13/23 03:22, Alan Bateman wrote: > I hereby nominate Viktor Klang to JDK Committer. From Alan.Bateman at oracle.com Sat Dec 30 07:42:54 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 30 Dec 2023 07:42:54 +0000 Subject: Result: New JDK Committer: Viktor Klang Message-ID: <56dbd589-207c-467e-8540-6d8837c102c4@oracle.com> Voting for Viktor Klang [1] is now closed. Yes:? 37 Veto:? 0 Abstain:? 0 One vote cast after the deadline is ignored. According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -Alan. [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008548.html