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 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 t
On Mon, 29 Jul 2024 10:06:08 GMT, Daniel Jeliński wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update comment
>
> WaitOnAddress is reported to spin before yielding. It might be related.
@djelinski @dholmes-o
On Thu, 1 Aug 2024 04:38:11 GMT, David Holmes wrote:
>> @djelinski @dholmes-ora Couldn't it be that the producer thread is already
>> scheduled, so it can reacquire the monitor whereas if the consumer was
>> parked then the wake-up "lag" means that statistically it will lose?
>
> @viktorklang-o
On Fri, 2 Aug 2024 06:46:51 GMT, David Holmes wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update comment
>
> I read that as meaning it is more efficient than a polling loop using Sleep
> because WFA nominal
On Fri, 18 Apr 2025 18:25:54 GMT, Chen Liang wrote:
>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>>
>> For calling little color management system
>> https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>>
>>
