On Thu, 16 Feb 2023 14:25:15 GMT, Johannes Bechberger wrote:
>> Extends the existing AsyncGetCallTrace test case and fixes the issue by
>> modifying `MethodHandles` code.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additional commit since the last revision:
>
On Tue, 14 Feb 2023 05:37:51 GMT, Serguei Spitsyn wrote:
> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of
> nosafepoint.
> The fix includes removal of the function
> `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
>
> Testing:
> mach5 jobs are i
On Tue, 14 Feb 2023 05:37:51 GMT, Serguei Spitsyn wrote:
> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of
> nosafepoint.
> The fix includes removal of the function
> `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
>
> Testing:
> mach5 jobs are i
On Thu, 24 Mar 2022 07:01:43 GMT, Fei Yang wrote:
>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the
>> https://openjdk.java.net/projects/riscv-port branch.
>>
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive
>> Unmatched bo
On Thu, 16 Feb 2023 14:25:15 GMT, Johannes Bechberger wrote:
>> Extends the existing AsyncGetCallTrace test case and fixes the issue by
>> modifying `MethodHandles` code.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additional commit since the last revision:
>
On Thu, 16 Feb 2023 18:05:54 GMT, Serguei Spitsyn wrote:
> This is a minor JVM TI spec update for two timer functions
> `GetCurrentThreadCpuTime` and `GetThreadCpuTime` to allow implementations to
> support virtual threads.
>
> The CSR is:
> [JDK-8302616](https://bugs.openjdk.org/browse/JDK-83
On Thu, 16 Feb 2023 18:05:54 GMT, Serguei Spitsyn wrote:
> This is a minor JVM TI spec update for two timer functions
> `GetCurrentThreadCpuTime` and `GetThreadCpuTime` to allow implementations to
> support virtual threads.
>
> The CSR is:
> [JDK-8302616](https://bugs.openjdk.org/browse/JDK-83
This is a minor JVM TI spec update for two timer functions
`GetCurrentThreadCpuTime` and `GetThreadCpuTime` to allow implementations to
support virtual threads.
The CSR is:
[JDK-8302616](https://bugs.openjdk.org/browse/JDK-8302616): make JVMTI thread
cpu time functions optional for virtual thre
On Thu, 16 Feb 2023 07:48:16 GMT, Serguei Spitsyn wrote:
> The `SuspendAllVirtualThreads` spec has this statement:
>
> ```
> Suspend all virtual threads except those in the exception list.
> Virtual threads that are currently suspended do not change state.
> ```
>
> And the `ResumeAllVirtua
> Please review the following change. Some of the JVMTI functions had to be
> modified since they are not supported by the specs on virtual threads
> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
> shouldn't include virtual threads in the results (GetAllThreads,
> G
On Thu, 16 Feb 2023 08:38:42 GMT, Robbin Ehn wrote:
> Hi all, please consider.
>
> The original issue was when thread 1 asked to deopt nmethod set X and thread
> 2 asked for the same or a subset of X.
> All method will already be marked, but the actual deoptimizing, not entrant,
> patching PC
On Thu, 16 Feb 2023 11:00:14 GMT, Richard Reingruber wrote:
>>> (Maybe too) long version:
>>
>> Not at all :) I don't know much about the interpreter, so this is pretty
>> helpful.
>>
>> Ok. I think the main point is that a MH linker method doesn't ~have~ use a
>> c2i adapter, it instead has
> Fixes the issue by applying a fix that is already implemented in PPC.
Johannes Bechberger has updated the pull request incrementally with one
additional commit since the last revision:
Implement addptr suggestion by @JohnVernee and @reinrich
-
Changes:
- all: https://git.open
On Tue, 14 Feb 2023 08:57:38 GMT, Stefan Karlsson wrote:
> FWIW, I strongly dislike the uppercase MEMFLAGS name. I wouldn't mind this
> rename at all.
Thinking this through again, I somewhat regret my strong opposition. Reeks too
much of resisting change for resisting's sake, and we don't want
Hi all, please consider.
The original issue was when thread 1 asked to deopt nmethod set X and thread 2
asked for the same or a subset of X.
All method will already be marked, but the actual deoptimizing, not entrant,
patching PC on stacks and patching post call nops, was not done yet. Which
me
On Thu, 16 Feb 2023 00:36:03 GMT, Jorn Vernee wrote:
> So... my understanding is that a c2i adapter is used when a callee is
> interpreted, so its `from_compiled_entry` points to the c2i adapter. A
> compiled caller calls the `from_compiled_entry`, so it ends up going through
> the `c2i` adapter
On Thu, 16 Feb 2023 08:16:40 GMT, Serguei Spitsyn wrote:
> Hi Alexey, I hope, Kevin will have a chance to review your PR. I'll check
> with him.
Thank you!
-
PR: https://git.openjdk.org/jdk/pull/11758
On Thu, 2 Feb 2023 13:42:51 GMT, Alexey Bakhtin wrote:
>> Please find a patch to improve JMX Repository.query performance
>>
>> Using ObjectName.apply() allows significantly decrease memory usage and the
>> number of GC cycles:
>> Before:
>>
>> $ java test 100 100
>> Test PASSED in 894
18 matches
Mail list logo
