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
17 matches
Mail list logo
