On Mon, 26 May 2025 19:38:16 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profile
On Mon, 17 Mar 2025 16:20:42 GMT, Robert Toyonaga wrote:
> ### Update:
> After some discussion it was decided it's not necessary to expand the lock
> scope for reserve/commit. Instead, we are opting to add comments explaining
> the reasons for locking and the conditions to
On Wed, 9 Apr 2025 13:43:01 GMT, Robert Toyonaga wrote:
>> ### Update:
>> After some discussion it was decided it's not necessary to expand the lock
>> scope for reserve/commit. Instead, we are opting to add comments explaining
>> the reasons for locking and the co
ready checks
> `MemTracker::enabled()` and checks against nullptr. This refactoring
> previously wasn't possible because `ThreadCritical` was used before
> https://github.com/openjdk/jdk/pull/22745 introduced
> `NmtVirtualMemoryLocker`.
>
> I considered moving the lockin
On Tue, 1 Apr 2025 15:29:55 GMT, Stefan Karlsson wrote:
>> OK should I update this PR to do the following things:
>> - Add comments explaining the asymmetrical locking and warning against
>> patterns that lead to races
>> - swapping the order of `NmtVirtualMemoryLocker` and release/uncommit
>>
ready checks
> `MemTracker::enabled()` and checks against nullptr. This refactoring
> previously wasn't possible because `ThreadCritical` was used before
> https://github.com/openjdk/jdk/pull/22745 introduced
> `NmtVirtualMemoryLocker`.
>
> I considered moving the lockin
On Tue, 8 Apr 2025 14:08:23 GMT, Stefan Karlsson wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> exclude file mapping tests on AIX.
>
> src/hotspot/share/runtime/os.cpp line 2
On Tue, 25 Mar 2025 18:55:56 GMT, Stefan Karlsson wrote:
> Are there any code that we know of that doesn't fit into a synchronization
> pattern similar to the above?
> I can think of some contrived example where Thread B asks the OS for memory
> mappings and uses that to ascertain that a pre-de
On Mon, 24 Mar 2025 16:16:34 GMT, Stefan Karlsson wrote:
>> ### Summary:
>> This PR makes memory operations atomic with NMT accounting.
>>
>> ### The problem:
>> In memory related functions like `os::commit_memory` and
>> `os::reserve_memory` the OS memory operations are currently done before
racker::record }. The hope
> was that this would help reduce the size of the critical section. However, I
> found that the OS-specific "pd_" functions are already short and
> to-the-point, so doing this wasn't reducing the lock scope very much. Instead
> it just m
On Thu, 3 Apr 2025 10:21:29 GMT, Joachim Kern wrote:
> Internal Error (os_aix.cpp:1917), pid=26476938, tid=258 Error:
> guarantee((vmi)) failed
>
> This will happen if a `os::pd_commit_memory()` or `os::pd_release_memory()`
> or `os::pd_uncommit_memory()` is called on memory not allocated with
On Wed, 2 Apr 2025 14:02:25 GMT, Robert Toyonaga wrote:
>> ### Summary:
>> This PR makes memory operations atomic with NMT accounting.
>>
>> ### The problem:
>> In memory related functions like `os::commit_memory` and
>> `os::reserve_memory` the OS memory
racker::record }. The hope
> was that this would help reduce the size of the critical section. However, I
> found that the OS-specific "pd_" functions are already short and
> to-the-point, so doing this wasn't reducing the lock scope very much. Instead
> it just m
On Mon, 17 Mar 2025 16:20:42 GMT, Robert Toyonaga wrote:
> ### Summary:
> This PR makes memory operations atomic with NMT accounting.
>
> ### The problem:
> In memory related functions like `os::commit_memory` and `os::reserve_memory`
> the OS memory operations are cur
On Wed, 26 Mar 2025 20:18:43 GMT, Stefan Karlsson wrote:
> > > > > I don't understand why we don't treat that as a fatal error OR make
> > > > > sure that all call-sites handles that error, which they don't do
> > > > > today.
> > > >
> > > >
> > > > I think release/uncommit failures should b
On Wed, 26 Mar 2025 16:05:00 GMT, Stefan Karlsson wrote:
>>> What state is the memory in when such a failure happens? Do we even know if
>>> the memory is still committed if an uncommit fails?
> >
>> If release/uncommit fails, then it would be hard to know what state the
>> target memory is in.
On Tue, 25 Mar 2025 18:55:56 GMT, Stefan Karlsson wrote:
> ... swapping the order of the release and NMT release booking as a way to
> shrink the lock scope for the release operation:
...
As long as we hold the reservation, no other thread can re-reserve the
reservation, so Thread B can take it
### Summary:
This PR makes memory operations atomic with NMT accounting.
### The problem:
In memory related functions like `os::commit_memory` and `os::reserve_memory`
the OS memory operations are currently done before acquiring the the NMT mutex.
And the the virtual memory accounting is done la
On Fri, 13 Dec 2024 21:29:53 GMT, Robert Toyonaga wrote:
> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824)
> which was backed out by
> [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems
> documented in [JDK-8343244](https://bugs
On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga wrote:
>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824)
>> which was backed out by
>> [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems
>> documente
On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga wrote:
>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824)
>> which was backed out by
>> [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems
>> documente
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - hotspot_nmt
On Mon, 13 Jan 2025 21:21:55 GMT, David Holmes wrote:
>I need to rewind a few steps and see exactly what it is we need to be
>initialized before this lock can be used
Before `NmtVirtualMemoryLocker` can be used, Hotspot mutexes must be
initialized (`vm_init_globals()`) and
`main_thread->initi
On Mon, 13 Jan 2025 02:56:13 GMT, David Holmes wrote:
> So a simple solution would be to just use Thread::number_of_threads() > 0 as
> the guard. That means we will skip the lock whilst it is unsafe to try and
> use it, then start using it once the main thread has "attached" even though
> it i
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - hotspot_nmt
On Mon, 13 Jan 2025 07:40:10 GMT, Thomas Stuefe wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> small fix to is_single_threaded and whitespace
>
> Do we still think using hots
On Thu, 9 Jan 2025 14:27:56 GMT, Robert Toyonaga wrote:
>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824)
>> which was backed out by
>> [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems
>> documente
On Tue, 7 Jan 2025 04:40:36 GMT, David Holmes wrote:
>>> In case my comment within the existing conversations gets missed I will
>>> re-state that I don't think you need any new "is bootstrapping" logic
>>> because you can just use `Threads::number_of_threads() > 0` to tell you if
>>> you need
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - hotspot_n
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - hotspot
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - hotspot_
On Mon, 6 Jan 2025 05:00:01 GMT, David Holmes wrote:
> In case my comment within the existing conversations gets missed I will
> re-state that I don't think you need any new "is bootstrapping" logic because
> you can just use `Threads::number_of_threads() > 0` to tell you if you need
> to acqu
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - hotsp
On Mon, 23 Dec 2024 07:58:32 GMT, Thomas Stuefe wrote:
>> I don't think this should ever get called during bootstrapping because
>> thread stacks are only accounted lazily when a snapshot is created. I don't
>> think an NMT snapshot would ever get created during bootstrapping, but just
>> in c
On Sat, 21 Dec 2024 07:16:22 GMT, Kim Barrett wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> move boostrapping_done flag into Mutex from MutexLocker
>
> src/hotspot/share/nmt/
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - h
On Fri, 20 Dec 2024 18:23:46 GMT, Thomas Stuefe wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment fo
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - h
On Fri, 20 Dec 2024 17:22:30 GMT, Thomas Stuefe wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for
>> Shar
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - hotspo
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - hots
On Thu, 19 Dec 2024 22:43:39 GMT, Kim Barrett wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for
>> Shar
On Thu, 19 Dec 2024 22:52:39 GMT, Kim Barrett wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for
>> Shar
On Fri, 20 Dec 2024 15:33:29 GMT, Coleen Phillimore wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for
>&
On Fri, 20 Dec 2024 15:24:13 GMT, Coleen Phillimore wrote:
>> Yes, I agree, bootstrap_done reads better.
>
> There's a few other is_bootstrapping() predicates in the code like
> Universe::is_bootstrapping. This might read nicely as
> is_bootstrapping_done() and the instance is _bootstrapping_d
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - hotspot_
On Thu, 19 Dec 2024 02:19:29 GMT, David Holmes wrote:
>> This change was decided on in the original PR after it was discovered that
>> calling
>> [os::print_memory_mappings](https://github.com/openjdk/jdk/blob/jdk-25%2B2/src/hotspot/os/windows/os_windows.cpp#L3623)
>> from the windows implemen
On Wed, 18 Dec 2024 23:01:38 GMT, Coleen Phillimore wrote:
>> Robert Toyonaga has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains seven commits:
>>
>> - Merge master
>> - move MemTracker::set_don
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - hotspot_nmt
On Wed, 18 Dec 2024 04:31:45 GMT, David Holmes wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updates tests and remove old class
>
> src/hotspot/share/runtime/threads.cp
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - hotspot_
On Wed, 18 Dec 2024 04:24:51 GMT, David Holmes wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updates tests and remove old class
>
> src/hotspot/os/windows/os_windows.cpp line 3
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - hotspot
On Tue, 17 Dec 2024 15:46:01 GMT, Robert Toyonaga wrote:
>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824)
>> which was backed out by
>> [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems
>> documente
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> - hotspot_nm
y reproduce the errors described
> in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing
> the number of test threads in
> `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test
> consistently passes with the new changes in this PR.
> -
On Tue, 17 Dec 2024 06:57:59 GMT, David Holmes wrote:
>> CML could perhaps be used has-a (though that might be messy), but should not
>> be used is-a. One of the basic rules for base classes is to have either a
>> public virtual destructor (don't do that here) or a non-public non-virtual
>> dest
This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824)
which was backed out by
[JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems
documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
The problem was that `NmtVirtualMemoryLocker`
On Mon, 4 Nov 2024 07:53:48 GMT, Johan Sjölen wrote:
>> src/hotspot/share/runtime/mutexLocker.hpp line 31:
>>
>>> 29: #include "runtime/flags/flagSetting.hpp"
>>> 30: #include "runtime/mutex.hpp"
>>> 31: #include "runtime/thread.hpp"
>>
>> This include is not needed because there are no uses th
On Thu, 31 Oct 2024 12:34:38 GMT, Thomas Stuefe wrote:
>>> I had to analyze this again, to understand why we need this locking, since
>>> my mind slips.
>>>
>>> I updated my findings in https://bugs.openjdk.org/browse/JDK-8325890 .
>>> Please see details there.
>>>
>>> But I don't think the c
On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga wrote:
>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.
>> `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT.
>> I've implemented the new lock with a sem
On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga wrote:
>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.
>> `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT.
>> I've implemented the new lock with a sem
On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga wrote:
>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.
>> `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT.
>> I've implemented the new lock with a sem
On Wed, 30 Oct 2024 12:32:17 GMT, Johan Sjölen wrote:
>>> Hi @tstuefe,
>>>
>>> > Ah thank you. I think I added that printing ages ago. I should not have
>>> > used tty. The immediate solution to get you going may be to just change
>>> > this from tty to fileStream fs(stderr);
>>>
>>> Thanks!
On Wed, 4 Sep 2024 14:17:08 GMT, Robert Toyonaga wrote:
> ### Summary
> This PR just replaces `ThreadCritical` with a lock specific to NMT.
> `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT.
> I've implemented the new lock with a semaphore so th
On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga wrote:
>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.
>> `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT.
>> I've implemented the new lock with a sem
On Fri, 25 Oct 2024 14:32:19 GMT, Thomas Stuefe wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update src/hotspot/share/utilities/vmError.cpp
>>
>> Co-authored-by
On Mon, 28 Oct 2024 16:03:32 GMT, Thomas Stuefe wrote:
>> Otherwise `make test TEST=hotspot_nmt` throws a lock rank error when running
>> the test `location_printing_mmap_1`. That test uses
>> `MemTracker::print_containing_region`.
>
> Thanks. But eew. Okay, ugly but not easy to fix.
> Can you
which I
> can also add more assertions.
>
> Testing:
> - hotspot_nmt
> - gtest:VirtualSpace
> - tier1
Robert Toyonaga has updated the pull request incrementally with two additional
commits since the last revision:
- add a comment explaining lock rank
- remove unnecessary dropping
On Mon, 28 Oct 2024 15:45:31 GMT, Robert Toyonaga wrote:
>> src/hotspot/share/runtime/mutexLocker.cpp line 299:
>>
>>> 297: MUTEX_DEFN(ThreadsSMRDelete_lock , PaddedMonitor,
>>> service-2); // Holds ConcurrentHashTableResize_lock
>>> 298
On Fri, 25 Oct 2024 14:23:29 GMT, Thomas Stuefe wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update src/hotspot/share/utilities/vmError.cpp
>>
>> Co-authored-by
On Sat, 12 Oct 2024 18:42:34 GMT, Afshin Zafari wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update src/hotspot/share/utilities/vmError.cpp
>>
>> Co-authored-by
On Sat, 12 Oct 2024 18:42:34 GMT, Afshin Zafari wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update src/hotspot/share/utilities/vmError.cpp
>>
>> Co-authored-by
On Wed, 2 Oct 2024 02:34:29 GMT, David Holmes wrote:
> Okay I am happy with this now. Thanks.
Thank you for the review!
> If I heard correctly Thomas is on vacation this month so you may need to
> proceed with a different second review and follow up when he gets back if
> there are any proble
which I
> can also add more assertions.
>
> Testing:
> - hotspot_nmt
> - gtest:VirtualSpace
> - tier1
Robert Toyonaga has updated the pull request incrementally with one additional
commit since the last revision:
Update src/hotspot/share/utilities/vmErro
which I
> can also add more assertions.
>
> Testing:
> - hotspot_nmt
> - gtest:VirtualSpace
> - tier1
Robert Toyonaga has updated the pull request incrementally with one additional
commit since the last revision:
Rename lock and mutex locker. Add back ThreadCritical when pr
On Sun, 22 Sep 2024 23:27:52 GMT, David Holmes wrote:
>> src/hotspot/share/runtime/mutexLocker.hpp line 261:
>>
>>> 259: // Same as MutexLocker but can be used during VM init.
>>> 260: // Performs no action if given a null mutex or with detached threads.
>>> 261: class NMTMutexLocker: public Con
On Wed, 18 Sep 2024 05:53:05 GMT, Thomas Stuefe wrote:
> > Hi @tstuefe,
> > > Ah thank you. I think I added that printing ages ago. I should not have
> > > used tty. The immediate solution to get you going may be to just change
> > > this from tty to fileStream fs(stderr);
> >
> >
> > Thanks!
On Tue, 17 Sep 2024 23:16:47 GMT, David Holmes wrote:
>> Robert Toyonaga has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains five commits:
>>
>> - Merge master
>> - replace tty in pd_release
which I
> can also add more assertions.
>
> Testing:
> - hotspot_nmt
> - gtest:VirtualSpace
> - tier1
Robert Toyonaga has updated the pull request incrementally with one additional
commit since the last revision:
Inherit from ConditionalMutexLocker. Use current_or_null_safe inst
which I
> can also add more assertions.
>
> Testing:
> - hotspot_nmt
> - gtest:VirtualSpace
> - tier1
Robert Toyonaga has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains five commits:
- Merge master
- replace tty in pd_re
On Sat, 14 Sep 2024 06:56:01 GMT, Thomas Stuefe wrote:
>> Hi @tstuefe, it looks like calling
>> [`os::print_memory_mappings`](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L3785)
>> from the windows implementation of `os::pd_release_memory` is causing the
>>
which I
> can also add more assertions.
>
> Testing:
> - hotspot_nmt
> - gtest:VirtualSpace
> - tier1
Robert Toyonaga has updated the pull request incrementally with one additional
commit since the last revision:
replace tty in pd_release_memory while holding NMT lock.
On Fri, 13 Sep 2024 16:17:56 GMT, Thomas Stuefe wrote:
>>> After switching to a Hotspot Mutex, it looks like the `windows-x64 / test
>>> (hs/tier1 common) GHA` is failing because the test `release_bad_ranges` in
>>> test_os.cpp is expecting an assertion and an error message to be printed.
>>>
On Thu, 12 Sep 2024 14:37:22 GMT, Robert Toyonaga wrote:
>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.
>> `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT.
>> I've implemented the new lock with a sem
On Wed, 11 Sep 2024 06:10:11 GMT, Thomas Stuefe 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`.
>>
>> Hi @jdksjol
which I
> can also add more assertions.
>
> Testing:
> - hotspot_nmt
> - gtest:VirtualSpace
> - tier1
Robert Toyonaga has updated the pull request incrementally with one additional
commit since the last revision:
Switch to using a Hotspot Mutex.
-
Changes:
- all: ht
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) co
On Thu, 5 Sep 2024 21:10:27 GMT, Robert Toyonaga wrote:
>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.
>> `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT.
>> I've implemented the new lock with a sem
On Fri, 6 Sep 2024 20:18:36 GMT, Gerard Ziemski wrote:
>> Robert Toyonaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Comments. Hide assertion behind DEBUG. Replace MemoryFileTracker locker.
>> make re
On Fri, 6 Sep 2024 10:35:39 GMT, Thomas Stuefe wrote:
>> We have a healthy amount of tests already. We need a wide use of
>> assert_locked and need to take a close look at error reporting. Locking, in
>> NMT, is rather simple.
>>
>> Error handling: My pragmatic "good enough for this rare scena
On Fri, 6 Sep 2024 10:36:15 GMT, Thomas Stuefe 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`.
Hi @jdksjolen. No problem! O
which I
> can also add more assertions.
>
> Testing:
> - hotspot_nmt
> - gtest:VirtualSpace
> - tier1
Robert Toyonaga has updated the pull request incrementally with one additional
commit since the last revision:
Comments. Hide assertion behind DEBUG. Replace MemoryFileTracker
On Wed, 4 Sep 2024 14:17:08 GMT, Robert Toyonaga wrote:
> ### Summary
> This PR just replaces `ThreadCritical` with a lock specific to NMT.
> `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT.
> I've implemented the new lock with a semaphore so th
### Summary
This PR just replaces `ThreadCritical` with a lock specific to NMT.
`ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've
implemented the new lock with a semaphore so that it can be used early before
VM init. There is also the possibility of adding asserti
counters, this makes sense, since all we do for malloc is to
> increase these counters (in summary mode) and in detail mode, we add the
> call site to the malloc site table, which is lock free.
>
> Cheers, Thomas
>
>
>
> On Thu, Aug 29, 2024 at 5:30 PM Robert Toyonaga
&g
ic, peak updating, and only need getters.
The JBS issue for this is JDK-8334234
Thanks!
Robert Toyonaga
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) co
### 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 been
shapshotted, they no longer need to be atomic or require thi
On Wed, 5 Jun 2024 20:08:10 GMT, Robert Toyonaga wrote:
> ### Summary
> This change ensures we don't get undefined behavior when
> calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).
> `isspace` accepts an `int` argument that "
1 - 100 of 104 matches
Mail list logo
