On Mon, 4 Nov 2024 14:52:06 GMT, Robert Toyonaga wrote:
>>>This include is not needed because there are no uses that require the
>>>definition of Thread.
>>
>> Right, seems like the forward declaration used to be provided by
>> `memory/allocation.hpp`. Let's get rid of the include and use a fo
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 Fri, 1 Nov 2024 21:56:36 GMT, Markus Grönlund wrote:
>This include is not needed because there are no uses that require the
>definition of Thread.
Right, seems like the forward declaration used to be provided by
`memory/allocation.hpp`. Let's get rid of the include and use a forward
declar
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 semaphore so that it can be used
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 semaphore so that it can be used
On Thu, 31 Oct 2024 11:11:21 GMT, Johan Sjölen wrote:
> If this is so brittle and complex, then I wonder what you even get out of us
> doing the ThreadCritical trick. In other words, if we just removed it, would
> anyone notice and be able to discern what's occurred? Open question, I might
> d
On Thu, 31 Oct 2024 10:53:12 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 current locking
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 semaphore so that it can be used
On Wed, 30 Oct 2024 15:57:57 GMT, Robert Toyonaga wrote:
> So that means we'd need to have both ThreadCritical and NmtVirtualMemory_lock
> in that method (if we were to do the other replacements). One to protect the
> chunks and one to protect the malloc accounting. It might also be good to
>
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 semaphore so that it can be used
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 semaphore so that it can be used
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 semaphore so that it can be used
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 semaphore so that it can be used
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 semaphore so that it can be used
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 semaphore so that it can be used
On Mon, 28 Oct 2024 16:09:44 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 that it can be used
> ### 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 addi
18 matches
Mail list logo
