> On 11 Jun 2024, at 18:19, David Lloyd wrote:
>
> I would support this solution; it would solve the problem for conformant
> serialization libraries. If a class has a `readObject`/etc. then we use it -
> we wouldn't care if it was "natural" or generated. This also gives us the
> option to
> On 11 Jun 2024, at 17:27, David Lloyd wrote:
>
>
>
> On Tue, Jun 11, 2024 at 10:17 AM Alan Bateman wrote:
> On 06/06/2024 18:37, David Lloyd wrote:
>> Just bumping this one more time. I intend to start by opening a JIRA to add
>> the two proposed methods to `ReflectionFactory`, and go
> On 6 Jun 2024, at 18:37, David Lloyd wrote:
>
> Just bumping this one more time. I intend to start by opening a JIRA to add
> the two proposed methods to `ReflectionFactory`, and go from there. I guess
> that we might need a JEP for the proposed serialization restrictions, which
> is going
> On 3 May 2024, at 18:33, David Lloyd wrote:
>
>
> On Fri, May 3, 2024 at 10:12 AM Mark Reinhold
> wrote:
> https://openjdk.org/jeps/471
>
> Summary: Deprecate the memory-access methods in sun.misc.Unsafe for
> removal in a future release.
>
>
> We still use Unsafe fairly often in
On Wed, 11 Oct 2023 07:52:54 GMT, Per Minborg wrote:
> This PR proposes to Add @sealedGraph to `Thread.Builder`.
I don't think it's helpful here.
-
PR Comment: https://git.openjdk.org/jdk/pull/16138#issuecomment-1757905176
On Mon, 18 Sep 2023 23:00:09 GMT, Mandy Chung wrote:
> `JVM_MoreStackWalk` has a bug that always assumes that the Java frame
> stream is currently at the frame decoded in the last patch and so always
> advances to the next frame before filling in the new batch of stack frame.
> However
On Tue, 19 Sep 2023 10:35:33 GMT, Alan Bateman wrote:
>> Thread::getState is an API for monitoring and management purposes to report
>> the thread state. If a virtual thread is parked with LockSupport.parkNanos,
>> its state is reported as WAITING when it should be TIMED_WAITING. JVM TI
>>
On Thu, 14 Sep 2023 13:30:28 GMT, Alan Bateman wrote:
>> Thread::getState is an API for monitoring and management purposes to report
>> the thread state. If a virtual thread is parked with LockSupport.parkNanos,
>> its state is reported as WAITING when it should be TIMED_WAITING. JVM TI
>>
On Mon, 12 Jun 2023 14:32:07 GMT, Alan Bateman wrote:
> StructuredTaskScope's class description introduces the join method as waiting
> for all subtasks to finish but the API docs for join/joinUntil are phrased in
> terms of waiting for all threads to finish. ShutdownOnXXX join/joinUntil
>
On Wed, 7 Jun 2023 15:12:40 GMT, Alan Bateman wrote:
> Thread.interrupted is used to "get and clear" the current thread's interrupt
> status. When called from a virtual thread, the current implementation always
> clears the carrier's interrupt status. There is no need to do this when the
>
On Thu, 23 Mar 2023 09:10:26 GMT, Serguei Spitsyn wrote:
> The fix was suggested/provided by @AlanBateman.
> Continuation should use Unsafe.compareAndSetReference rather than a VH here.
> We had to change CHM and VT back to Unsafe for similar reasons.
>
> Testing: Mach5 runs of tiers 1-6 are in
On Tue, 6 Dec 2022 10:16:38 GMT, Alan Bateman wrote:
> The implementation of Thread.yield for virtual threads is currently a "lazy
> submit". This means the task for the virtual thread is queued to the
> carrier/worker local queue without signalling other threads. This behavior
> can be
Hi.
The appropriate list is core-libs-dev, where this discussion should continue.
System.in is the standard input, which may or may not be the keyboard. For
keyboard input, take a look at the java.io.Console class [1], in particular its
charset and reader methods.
[1]:
Hi.
The difference between ExtentLocals and other TwR constructs is that we’d like
to use it for critical, foundational, things where we want guarantees we can
rely on, and we haven’t been able to find a way to guarantee them as well as
we’d like with TwR, even dynamically.
Yes, we are
On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote:
> Some of the newly added Loom tests are long-running, and thus they delay the
> completion of otherwise very parallel tier1/jdk_loom. We can parallelize them
> a bit better to avoid these testing stalls.
>
> Improvements on Linux
On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote:
> Some of the newly added Loom tests are long-running, and thus they delay the
> completion of otherwise very parallel tier1/jdk_loom. We can parallelize them
> a bit better to avoid these testing stalls.
>
> Improvements on Linux
16 matches
Mail list logo
