On Sun, 6 Nov 2022 16:39:48 GMT, Aleksei Efimov wrote:
> ### The Proposed Change
>
> The proposed change updates JNDI's `DnsClient` internal implementation to use
> `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS).
> The main motivation behind this change is to make JNDI/DNS lo
On Sun, 6 Nov 2022 16:39:48 GMT, Aleksei Efimov wrote:
> ### The Proposed Change
>
> The proposed change updates JNDI's `DnsClient` internal implementation to use
> `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS).
> The main motivation behind this change is to make JNDI/DNS lo
On Sun, 6 Nov 2022 16:39:48 GMT, Aleksei Efimov wrote:
> ### The Proposed Change
>
> The proposed change updates JNDI's `DnsClient` internal implementation to use
> `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS).
> The main motivation behind this change is to make JNDI/DNS lo
On Sun, 6 Nov 2022 23:09:54 GMT, Coleen Phillimore wrote:
>> This change adds an option **EnableWaitForParallelLoad** to enable the
>> legacy behavior where the VM will manage synchronization for multiple
>> threads loading the same class using a non-parallel capable class loader
>> that have
On Sun, 6 Nov 2022 23:03:19 GMT, Coleen Phillimore wrote:
>> Coleen has reminded me that I am confused about what the workaround was
>> doing - this code doesn't prevent deadlock, it prevents a LinkageError that
>> would otherwise occur because the classloader has done something tricky
>> (rel
> This change adds an option **EnableWaitForParallelLoad** to enable the legacy
> behavior where the VM will manage synchronization for multiple threads
> loading the same class using a non-parallel capable class loader that have
> released the class loader lock. The VM will break the class loa
On Sun, 6 Nov 2022 22:50:26 GMT, David Holmes wrote:
>> Okay but isn't that what should be expected? This is a flag to prevent a
>> certain kind of classloader from deadlocking, so if we have that kind of
>> classloader and the flag is disabled, then we should expect deadlock.
>> Otherwise wha
On Sun, 6 Nov 2022 21:57:36 GMT, David Holmes wrote:
>> If we don't return we'll actually do a wait and will hang. Worse, we'll be
>> in a tight loop holding both the ClassLoader and SystemDictionary_lock, that
>> the other thread can't get.
>
> Okay but isn't that what should be expected? Thi
On Sun, 6 Nov 2022 21:54:46 GMT, David Holmes wrote:
>> If you want, it seemed unnecessary clutter for the assert. And it's really
>> only necessary for non null class loader data
>
> I'd like to understand how the assert connects to the changes.
Multiple threads can now create the LOAD_INSTANC
On Thu, 3 Nov 2022 17:23:53 GMT, Jim Laskey wrote:
>> Enhance the Java programming language with string templates, which are
>> similar to string literals but contain embedded expressions. A string
>> template is interpreted at run time by replacing each expression with the
>> result of evalua
On Fri, 4 Nov 2022 12:21:22 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/classfile/placeholders.cpp line 137:
>>
>>> 135: assert(action != PlaceholderTable::LOAD_INSTANCE || seen == NULL,
>>> 136: "Only one LOAD_INSTANCE allowed at a time");
>>> 137:
>>
>> Unclear why this is
### The Proposed Change
The proposed change updates JNDI's `DnsClient` internal implementation to use
`DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS).
The main motivation behind this change is to make JNDI/DNS lookups friendly to
virtual-thread environments and update its under
On Thu, 3 Nov 2022 17:23:53 GMT, Jim Laskey wrote:
>> Enhance the Java programming language with string templates, which are
>> similar to string literals but contain embedded expressions. A string
>> template is interpreted at run time by replacing each expression with the
>> result of evalua
On Fri, 5 Aug 2022 02:15:21 GMT, Ichiroh Takiguchi
wrote:
> To support Windows command prompt's codepage, following charsets should be
> moved from jdk.charsets module to java.base module.
>
> - IBM860
> - IBM861
> - IBM863
> - IBM864
> - IBM865
> - IBM869
This pull request has been closed wi
On 04/11/2022 16:54, Thomas Stüfe wrote:
Hi all,
I am currently working on https://bugs.openjdk.org/browse/JDK-8296360;
I was preparing the final PR [1], but then Alan did ask me to discuss
this on core-libs first.
Backstory:
NMT tracks hotspot native allocations but does not cover the JDK
15 matches
Mail list logo