On Mon, 9 Sep 2024 10:16:24 GMT, Thomas Schatzl wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix bit counts in GCForwarding
>
> src/hotspot/share/gc/shared/gcForwarding.hpp line 41:
>
>> 39: * bits (to indicat
On Mon, 2 Sep 2024 12:25:05 GMT, Alan Bateman wrote:
> This PR proposes to add a JDK-specific monitoring and management interface
> for the virtual thread scheduler. The interface is named
> VirtualThreadSchedulerMXBean and allows JMX based tooling monitor/manage the
> scheduler's target paral
On Mon, 9 Sep 2024 10:21:54 GMT, Thomas Schatzl wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix bit counts in GCForwarding
>
> src/hotspot/share/gc/shared/collectedHeap.cpp line 232:
>
>> 230: }
>> 231:
>>
On Mon, 9 Sep 2024 14:58:07 GMT, Stefan Karlsson wrote:
>> src/hotspot/share/oops/oop.hpp line 134:
>>
>>> 132: inline Klass* forward_safe_klass(markWord m) const;
>>> 133: inline size_t forward_safe_size();
>>> 134: inline void forward_safe_init_mark();
>>
>> Given the comment th
On Mon, 9 Sep 2024 15:01:10 GMT, Thomas Schatzl wrote:
>> Just to be clear, the second part of the quoted sentence is important:
>>> could be any value *that is not a valid field offset*
>
>> could be any value that is not a valid field offset
>
> I understand that that "random value" needs
On Mon, 9 Sep 2024 12:12:23 GMT, Thomas Schatzl wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Try to avoid lea in loadNklass (aarch64)
>> - Fix release build error
>
> src/hotspot/share/oops/objArrayKlass.inli
On Mon, 9 Sep 2024 14:08:53 GMT, Roman Kennke wrote:
>> Yes, I'm interested in it. Thanks for raising the discussion. :)
>
> If anybody is doing it, please send me a patch, or we can do it as a
> follow-up PR.
Thanks. I'll send it to you if I finish it in time, otherwise I will do it in a
sepa
On Tue, 10 Sep 2024 08:37:43 GMT, Roman Kennke wrote:
>>> could be any value that is not a valid field offset
>>
>> I understand that that "random value" needs to satisfy this condition.
>
> With compact headers, this value should only be used in C2, and not really as
> an actual offset. An
On Tue, 10 Sep 2024 08:41:16 GMT, Roman Kennke wrote:
>> src/hotspot/share/oops/objArrayKlass.inline.hpp line 74:
>>
>>> 72: void ObjArrayKlass::oop_oop_iterate(oop obj, OopClosureType* closure) {
>>> 73: // In this assert, we cannot safely access the Klass* with compact
>>> headers.
>>> 74:
On Tue, 10 Sep 2024 07:53:23 GMT, Roman Kennke wrote:
>> src/hotspot/share/gc/shared/collectedHeap.cpp line 232:
>>
>>> 230: }
>>> 231:
>>> 232: // With compact headers, we can't safely access the class, due
>>
>> Suggestion:
>>
>> // With compact headers, we can't safely access the kla
On Mon, 9 Sep 2024 15:49:57 GMT, Coleen Phillimore wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Try to avoid lea in loadNklass (aarch64)
>> - Fix release build error
>
> src/hotspot/share/oops/compressedKlass
On Mon, 9 Sep 2024 15:50:50 GMT, Coleen Phillimore wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Try to avoid lea in loadNklass (aarch64)
>> - Fix release build error
>
> src/hotspot/share/oops/compressedKlass
On Tue, 10 Sep 2024 12:03:59 GMT, Thomas Stuefe wrote:
>> src/hotspot/share/oops/compressedKlass.cpp line 214:
>>
>>> 212: ss.print("Class space size (%zu) exceeds the maximum possible size
>>> (%zu)",
>>> 213: len, max_encoding_range_size());
>>> 214: vm_exit_during_initi
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes)
> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
> previously missing.
>
> Main changes:
> - Introduction of the (
On Mon, 9 Sep 2024 15:59:43 GMT, Coleen Phillimore wrote:
>> Roman Kennke has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - More touch-ups, fix Shenandoah oop iterator
>> - Remove asserts in XArrayKlass::oop_oop_iterate()
>> - Various
On Mon, 9 Sep 2024 16:01:10 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/oops/compressedKlass.hpp line 43:
>>
>>> 41:
>>> 42: // Tiny-class-pointer mode
>>> 43: static int _tiny_cp; // -1, 0=true, 1=false
>>
>> Suggestion:
>>
>> static int _tiny_cp; // -1 = uninitialized, 0 = true
> Remove very very old serialization compatibility logic from JMX.
>
> This relates to keeping the JDK's JMX implementation compatible with JMX
> versions from when JMX was a separate component, before being integrated into
> JDK 5. It should all be removed.
Kevin Walls has updated the pull re
On Tue, 10 Sep 2024 13:06:25 GMT, Kevin Walls wrote:
>> Remove very very old serialization compatibility logic from JMX.
>>
>> This relates to keeping the JDK's JMX implementation compatible with JMX
>> versions from when JMX was a separate component, before being integrated
>> into JDK 5. It
On Tue, 10 Sep 2024 13:06:25 GMT, Kevin Walls wrote:
>> Remove very very old serialization compatibility logic from JMX.
>>
>> This relates to keeping the JDK's JMX implementation compatible with JMX
>> versions from when JMX was a separate component, before being integrated
>> into JDK 5. It
On Tue, 10 Sep 2024 13:06:25 GMT, Kevin Walls wrote:
>> Remove very very old serialization compatibility logic from JMX.
>>
>> This relates to keeping the JDK's JMX implementation compatible with JMX
>> versions from when JMX was a separate component, before being integrated
>> into JDK 5. It
On Tue, 10 Sep 2024 13:06:25 GMT, Kevin Walls wrote:
>> Remove very very old serialization compatibility logic from JMX.
>>
>> This relates to keeping the JDK's JMX implementation compatible with JMX
>> versions from when JMX was a separate component, before being integrated
>> into JDK 5. It
On Mon, 26 Aug 2024 13:54:36 GMT, Joakim Nordström
wrote:
>> Can I get a review of this documentation update to clarify the usage of
>> GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and
>> GetProcessCpuLoad.
>>
>> Calling either of these methods in quick succession can lead to
>> u
On Mon, 26 Aug 2024 13:54:36 GMT, Joakim Nordström
wrote:
>> Can I get a review of this documentation update to clarify the usage of
>> GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and
>> GetProcessCpuLoad.
>>
>> Calling either of these methods in quick succession can lead to
>> u
> Remove very very old serialization compatibility logic from JMX.
>
> This relates to keeping the JDK's JMX implementation compatible with JMX
> versions from when JMX was a separate component, before being integrated into
> JDK 5. It should all be removed.
Kevin Walls has updated the pull re
On Tue, 10 Sep 2024 13:06:25 GMT, Kevin Walls wrote:
>> Remove very very old serialization compatibility logic from JMX.
>>
>> This relates to keeping the JDK's JMX implementation compatible with JMX
>> versions from when JMX was a separate component, before being integrated
>> into JDK 5. It
On Mon, 12 Aug 2024 12:33:04 GMT, Joakim Nordström
wrote:
> Can I get a review of this documentation update to clarify the usage of
> GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
>
> Calling either of these methods in quick succession can lead to
> unrepresen
On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote:
>> As a preparation for Hermetic Java, we need to have a way to look up during
>> runtime if we are using a statically linked library or not.
>>
>> This change will be the first step needed towards compiling the object files
>> only o
On Tue, 10 Sep 2024 00:53:32 GMT, Ioi Lam wrote:
>> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> **Overview**
>>
>> - A new `-XX:+AOTClassLinking` flag is added. See [JEP
>> 498](https://bugs.openjdk.org/browse/
On Tue, 10 Sep 2024 13:47:47 GMT, Kevin Walls wrote:
>> Remove very very old serialization compatibility logic from JMX.
>>
>> This relates to keeping the JDK's JMX implementation compatible with JMX
>> versions from when JMX was a separate component, before being integrated
>> into JDK 5. It
On Mon, 12 Aug 2024 14:01:29 GMT, Robert Toyonaga wrote:
> ### Summary
> This PR splits up NMT memory counter classes into "live" and "flat" versions.
> Currently, the same classes are used and reused in both live (recording) and
> snapshotted (reporting) contexts. However, after counters have
On Thu, 5 Sep 2024 13:25:17 GMT, Severin Gehwolf wrote:
>> Please review this fix for cgroups-based metrics reporting in the
>> `jdk.internal.platform` package. This fix is supposed to address wrong
>> reporting of certain limits if the limits aren't set at the leaf nodes.
>>
>> For example, o
On Tue, 10 Sep 2024 05:57:08 GMT, David Holmes wrote:
> > The template parameter rename I was planning on doing in a followup issue,
> > however, if you really want, I can make the fix here too.
>
> Personally I'd be okay with doing it here as one final commit that can be
> viewed in isolation
On Tue, 27 Aug 2024 22:58:52 GMT, Simon Tooke wrote:
>> This is a port of [JDK-8318636](https://github.com/openjdk/jdk/pull/16301)
>> to Windows.
>>
>> System.map and System.dump_map are implemented using the Windows API and
>> provide roughly the same information in the same format. Most of
On Mon, 9 Sep 2024 19:02:25 GMT, Gerard Ziemski wrote:
>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>>
>> `MEMFLAGS` implies that we can use more than one at the same time, but those
>> are exclusive values, so `MemTag` is a more suitable name.
>>
>> This fix also inc
> Hi all,
>
> This PR addresses [8204681](https://bugs.openjdk.org/browse/JDK-8204681)
> enabling support for timestamp expansion in filenames specified in
> `-XX:HeapDumpPath` using `%t`.
>
> As mentioned in this comments for this issue, this is somewhat related to
> [8334492](https://bugs.
> Please review this fix for cgroups-based metrics reporting in the
> `jdk.internal.platform` package. This fix is supposed to address wrong
> reporting of certain limits if the limits aren't set at the leaf nodes.
>
> For example, on cg v2, the memory limit interface file is `memory.max`.
> Co
On Tue, 3 Sep 2024 08:06:14 GMT, Kevin Walls wrote:
> Deprecation annotations and warnings on starting the tool(s).
> Handle man page in a separate issue.
This pull request has now been integrated.
Changeset: 33525226
Author:Kevin Walls
URL:
https://git.openjdk.org/jdk/commit/335252
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes)
> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
> previously missing.
>
> Main changes:
> - Introduction of the (
On Mon, 9 Sep 2024 17:40:03 GMT, Coleen Phillimore wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Try to avoid lea in loadNklass (aarch64)
>> - Fix release build error
>
> src/hotspot/share/oops/compressedKlass
On Mon, 9 Sep 2024 19:02:25 GMT, Gerard Ziemski wrote:
>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>>
>> `MEMFLAGS` implies that we can use more than one at the same time, but those
>> are exclusive values, so `MemTag` is a more suitable name.
>>
>> This fix also inc
> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>
> `MEMFLAGS` implies that we can use more than one at the same time, but those
> are exclusive values, so `MemTag` is a more suitable name.
>
> This fix also includes a cleanup of all the related parameter names and local
>
> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>
> `MEMFLAGS` implies that we can use more than one at the same time, but those
> are exclusive values, so `MemTag` is a more suitable name.
>
> This fix also includes a cleanup of all the related parameter names and local
>
On Tue, 10 Sep 2024 20:28:01 GMT, Coleen Phillimore wrote:
>> Gerard Ziemski has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix test
>
> src/hotspot/share/nmt/memTracker.hpp line 265:
>
>> 263:
>> 264: // MallocLimt: Given an alloca
On Tue, 10 Sep 2024 20:53:46 GMT, Gerard Ziemski wrote:
>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>>
>> `MEMFLAGS` implies that we can use more than one at the same time, but those
>> are exclusive values, so `MemTag` is a more suitable name.
>>
>> This fix also in
On Tue, 10 Sep 2024 20:53:46 GMT, Gerard Ziemski wrote:
>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>>
>> `MEMFLAGS` implies that we can use more than one at the same time, but those
>> are exclusive values, so `MemTag` is a more suitable name.
>>
>> This fix also in
On Fri, 6 Sep 2024 18:56:32 GMT, Leonid Mesnik wrote:
> Field watch tests updated to be executed with virtual threads when virtual
> test thread factory enabled.I added
> jdk.test.lib.thread.TestThreadFactory
> to created test threads so they support virtual thread factory jtreg plugin.
>
> It
On Fri, 6 Sep 2024 18:56:32 GMT, Leonid Mesnik wrote:
> Field watch tests updated to be executed with virtual threads when virtual
> test thread factory enabled.I added
> jdk.test.lib.thread.TestThreadFactory
> to created test threads so they support virtual thread factory jtreg plugin.
>
> It
On Fri, 6 Sep 2024 18:56:32 GMT, Leonid Mesnik wrote:
> Field watch tests updated to be executed with virtual threads when virtual
> test thread factory enabled.I added
> jdk.test.lib.thread.TestThreadFactory
> to created test threads so they support virtual thread factory jtreg plugin.
>
> It
On Tue, 10 Sep 2024 13:51:55 GMT, Josef Eisl wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also update build to link properly
>
> src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c line 135:
>
>> 13
On Tue, 10 Sep 2024 14:15:53 GMT, Gerard Ziemski wrote:
> Is everyone OK with `MT` as the template parameter name? Another obvious
> choice is `MEM_TAG`
>
> Side note: why are template parameter names all capitals? To help distinguish
> them from "regular" parameters? Do we still want that nam
On Tue, 10 Sep 2024 21:58:39 GMT, Kim Barrett wrote:
> Type template parameters should follow the style guide rules for type names.
> I've not noticed many (any?) cases of noncompliance.
... other than ConcurrentHashTable (sigh!)
-
PR Comment: https://git.openjdk.org/jdk/pull/2087
On Tue, 10 Sep 2024 00:53:32 GMT, Ioi Lam wrote:
>> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> **Overview**
>>
>> - A new `-XX:+AOTClassLinking` flag is added. See [JEP
>> 498](https://bugs.openjdk.org/browse/
On Tue, 10 Sep 2024 00:53:32 GMT, Ioi Lam wrote:
>> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> **Overview**
>>
>> - A new `-XX:+AOTClassLinking` flag is added. See [JEP
>> 498](https://bugs.openjdk.org/browse/
On Tue, 10 Sep 2024 00:27:23 GMT, Chris Plummer wrote:
> This test fails periodically. It only prints the exception message when it
> fails. It should print the entire stack trace so we have a better idea of why
> it is failing.
>
> Testing: This test is not run until tier5 CI testing, so I'm
On Tue, 10 Sep 2024 00:27:23 GMT, Chris Plummer wrote:
> This test fails periodically. It only prints the exception message when it
> fails. It should print the entire stack trace so we have a better idea of why
> it is failing.
>
> Testing: This test is not run until tier5 CI testing, so I'm
On Tue, 10 Sep 2024 21:58:39 GMT, Kim Barrett wrote:
> Side note: why are template parameter names all capitals?
I think it is an artifact of them usually being a single letter to represent a
Type and thus a capital. But then we sometimes use more than a single-letter
and decided to capitalize
On Sat, 7 Sep 2024 17:29:41 GMT, Robert Toyonaga wrote:
>>> Thank you Robert.
>>>
>>> I think that the `MemoryFileTracker`'s locker should probably also be
>>> replaced with this semaphore, as in the future we have plans to have a
>>> globally shared `NativeCallStackStorage`.
>>
>> +1
>
>> Th
57 matches
Mail list logo
