On Fri, 9 May 2025 06:37:40 GMT, Alan Bateman wrote:
> No, it will still uses synchronized if there is contention and this will not
> consume the park permit when it's a virtual thread. Im not sure if Heinz ran
> into an issue, or just remember the issue from 2015, Heinz?
I saw this comment in
On Fri, 9 May 2025 02:45:16 GMT, David Holmes wrote:
> The underlying issue is nested-parking as Alan notes. From re-reading
> 8074773, pre-loading in any class loaded by the boot loader, has no affect on
> the bug. The issue was the action taken by the AppLoader that involved
> creating an en
On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman wrote:
> Hopefully David will remember more of this when he gets back.
Sadly I have to page in all the details again like everyone else.
The underlying issue is nested-parking as Alan notes. From re-reading 8074773,
pre-loading in any class loaded
On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman wrote:
>> The bug description seems like it is a fault in the JVM implementation - if
>> that is the case, a core library bypass is unreliable, as such faults might
>> happen to other classes and cause other consequences; and we might need to
>> f
On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman wrote:
>> The bug description seems like it is a fault in the JVM implementation - if
>> that is the case, a core library bypass is unreliable, as such faults might
>> happen to other classes and cause other consequences; and we might need to
>> f
On Tue, 29 Apr 2025 19:02:20 GMT, Chen Liang wrote:
> The bug description seems like it is a fault in the JVM implementation - if
> that is the case, a core library bypass is unreliable, as such faults might
> happen to other classes and cause other consequences; and we might need to
> fix it
On Tue, 29 Apr 2025 17:02:38 GMT, kabutz wrote:
> In 2015, Google discovered a rare disastrous classloading bug in first call
> to LockSupport.park() that occurred in the AppClassLoader using the Java 7
> ConcurrentHashMap, which used ReentrantLock for the synchronization.
>
> Since then, the
On Tue, 29 Apr 2025 18:32:12 GMT, kabutz wrote:
> What is the potential downside of adding the static block to make sure the
> class is loaded?
LockSupport is part of the standard API, we can't force every usage to preload
this class. So if we have to change anything then it would be better to
On Tue, 29 Apr 2025 17:02:38 GMT, kabutz wrote:
> In 2015, Google discovered a rare disastrous classloading bug in first call
> to LockSupport.park() that occurred in the AppClassLoader using the Java 7
> ConcurrentHashMap, which used ReentrantLock for the synchronization.
>
> Since then, the
On Tue, 29 Apr 2025 17:02:38 GMT, kabutz wrote:
> In 2015, Google discovered a rare disastrous classloading bug in first call
> to LockSupport.park() that occurred in the AppClassLoader using the Java 7
> ConcurrentHashMap, which used ReentrantLock for the synchronization.
>
> Since then, the
In 2015, Google discovered a rare disastrous classloading bug in first call to
LockSupport.park() that occurred in the AppClassLoader using the Java 7
ConcurrentHashMap, which used ReentrantLock for the synchronization.
Since then, the recommended fix for this bug seems to be this code snippet i
11 matches
Mail list logo
