On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were
On Wed, 26 Jun 2024 07:48:54 GMT, Daniel Jeliński wrote:
> the waiting thread wakes up, but still needs to compete with the notifying
> thread for the monitor.
No, a notified thread is moved from the wait-queue to the monitor-entry queue.
It is only unparked once the notifier thread releases
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were
On Tue, 25 Jun 2024 18:23:18 GMT, Daniel Jeliński wrote:
> With the new implementation, it wakes up much more frequently,
Why? The number of unparks is unchanged. Are we seeing spurious unparks that
are consuming too much CPU?
-
PR Comment:
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were
On Sun, 23 Jun 2024 09:35:07 GMT, Daniel Jeliński wrote:
> the GHA failure looks related, but I can't reproduce it locally. Will dig...
The failure in jdk/jshell/ToolTabSnippetTest.java? That test is somewhat flakey
- search JBS.
-
PR Comment:
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were
On Thu, 20 Jun 2024 05:58:16 GMT, Thomas Stuefe wrote:
>> Oh. That's interesting.
>
> Of course pre-existing, but the typical pattern we use with RAII objects that
> may or may not do something is to give it a constructor argument, e.g. `bool
> activate`, that controls if it is
On Sun, 23 Jun 2024 09:35:07 GMT, Daniel Jeliński wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update comment
>
> the GHA failure looks related, but I can't reproduce it locally. Will dig...
@djelinski why
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were
On Wed, 19 Jun 2024 14:53:27 GMT, Viktor Klang wrote:
>> yeah, it's the C++ construction where the constructor and the destructor
>> have side effects. It increases the system timer resolution, unless
>> `ForceTimeHighResolution` is set. `ForceTimeHighResolution`, contrary to its
>> name and
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
> were live at any time.
>
> On Windows, the ParkEvent object wraps a
On Wed, 19 Jun 2024 14:12:13 GMT, Daniel Jeliński wrote:
>> src/hotspot/os/windows/os_windows.cpp line 5565:
>>
>>> 5563: prd = MAXTIMEOUT;
>>> 5564: }
>>> 5565: HighResolutionInterval *phri = nullptr;
>>
>> @djelinski Is this even used?
>
> yeah, it's the C++ construction where
On Wed, 19 Jun 2024 13:59:23 GMT, Viktor Klang wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were live
On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński wrote:
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
> were live
On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński wrote:
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
> were live
On Wed, 19 Jun 2024 12:09:41 GMT, Thomas Stuefe wrote:
> With UseHeavyMonitors, even uncontended locks are inflated to OMs.
I don't think that matters much for the changed code; only the implementation
of park/unpark methods changed, and these methods are called for contended
locks only.
I
On Wed, 19 Jun 2024 11:40:16 GMT, Daniel Jeliński wrote:
> As you found out already, the implementation is based on a hash table, so
> access will be slower with many threads waiting at the same time. The hash
> table is stored in user space (in PEB), and the implementation reportedly
>
On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński wrote:
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
> were live
On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński wrote:
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
> were live
On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński wrote:
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
> were live
On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński wrote:
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
> were live
We use 2 ParkEvent instances per thread. The ParkEvent objects are never freed,
but they are recycled when a thread dies, so the number of live ParkEvent
instances is proportional to the maximum number of threads that were live at
any time.
On Windows, the ParkEvent object wraps a kernel Event
28 matches
Mail list logo
