On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
> The TestScaffold incorrectly parse options, it should insert wrapper class
> between VM options and applications classame.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
added comments and trim arguments
-
Changes:
On Thu, 23 Mar 2023 21:49:55 GMT, Leonid Mesnik wrote:
> The TestScaffold incorrectly parse options, it should insert wrapper class
> between VM options and applications classame.
I've added comment with example from one of tests and expected result of
parsing.
The problem was that wrapper ins
On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Thu, 23 Mar 2023 21:49:55 GMT, Leonid Mesnik wrote:
> The TestScaffold incorrectly parse options, it should insert wrapper class
> between VM options and applications classame.
Sorry I'm struggling a bit to see where the current parsing logic is failing.
Can you given an example of a comman
On Thu, 23 Mar 2023 22:18:51 GMT, Leonid Mesnik wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address review comment: remove unneeded function
>
> src/hotspot/share/prims/whitebox.cpp line 2537:
>
>> 2535:
On Thu, 23 Mar 2023 22:24:45 GMT, Leonid Mesnik wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address review comment: remove unneeded function
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJv
On Thu, 23 Mar 2023 16:32:57 GMT, Roman Kennke wrote:
> Is anybody familiar with the academic literature on this topic? I am sure I
> am not the first person which has come up with this form of locking. Maybe we
> could use a name that refers to some academic paper?
Well not to diminish this i
On Thu, 23 Mar 2023 22:11:58 GMT, Leonid Mesnik wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address review comment: remove unneeded function
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1581:
>
>> 1579
On Thu, 23 Mar 2023 22:27:07 GMT, Leonid Mesnik wrote:
> There are few comments in the code.
> Also, I think it would be nice to have a high-level comment about sync of
> VTMTDisable and lately attached agent.
> What is set and why VMOp is needed.
> BTW why VMOp and not handshake is used?
Good
On Thu, 23 Mar 2023 17:59:52 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address review comment: remove unneeded function
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJv
On Thu, 23 Mar 2023 18:08:47 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address review comment: remove unneeded function
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJv
On Thu, 23 Mar 2023 18:07:23 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address review comment: remove unneeded function
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJv
On Thu, 23 Mar 2023 18:02:29 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address review comment: remove unneeded function
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJv
On Thu, 23 Mar 2023 17:49:31 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address review comment: remove unneeded function
>
> src/hotspot/share/prims/jvmtiThreadState.hpp line 101:
>
>> 9
On Thu, 23 Mar 2023 05:54:29 GMT, Serguei Spitsyn wrote:
>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which
>> does enabling JVMTI VTMS transition notifications in case
The TestScaffold incorrectly parse options, it should insert wrapper class
between VM options and applications classame.
-
Commit messages:
- parsing updted
- problemlist fixed
- comments
- fix
Changes: https://git.openjdk.org/jdk/pull/13170/files
Webrev: https://webrevs.openjd
On Thu, 23 Mar 2023 05:54:29 GMT, Serguei Spitsyn wrote:
>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which
>> does enabling JVMTI VTMS transition notifications in case
On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Thu, 23 Mar 2023 13:25:52 GMT, Jesper Wilhelmsson
wrote:
> UseNewLocks... Surely there must be a better name? For how long will these be
> the new locks? Do we rename the flag to UseOldLocks when the next locking
> scheme comes along? There must be some property that differentiates these
>
> The current structure used to store the resolution information for
> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
> ambigious fields f1 and f2. This structure can hold information for fields,
> methods, and invokedynamics and each of its fields can hold different
On Thu, 23 Mar 2023 15:06:21 GMT, Matias Saavedra Silva
wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improved comment for load-acquire aarch64
>
> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 2294
On Wed, 22 Mar 2023 17:42:35 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>>
On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Thu, 23 Mar 2023 12:43:38 GMT, Thomas Stuefe wrote:
> Yes, but while JFR interrupts threads too, its sampler runs in its own
> thread, so the async-safety of the interrupted code should not matter, or?
You're right.
> wrt info, just a little marker in the thread "AGCT was here", maybe with
On Thu, 23 Mar 2023 08:20:18 GMT, Johannes Bechberger
wrote:
>> Fixes the issue by transitioning the thread into the WXWrite mode while
>> walking the stack in AsyncGetCallTrace.
>>
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additiona
On Thu, 23 Mar 2023 12:00:33 GMT, Johannes Bechberger
wrote:
> > In particular, we do not know if AGCT did interrupt the crashing thread
> > recently. Or do we? This would be valuable information.
>
> Yes. But it could indeed be helpful information when debugging problems.
> Please don't forg
On Thu, 23 Mar 2023 08:20:18 GMT, Johannes Bechberger
wrote:
>> Fixes the issue by transitioning the thread into the WXWrite mode while
>> walking the stack in AsyncGetCallTrace.
>>
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additiona
On Thu, 23 Mar 2023 08:20:18 GMT, Johannes Bechberger
wrote:
>> Fixes the issue by transitioning the thread into the WXWrite mode while
>> walking the stack in AsyncGetCallTrace.
>>
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additiona
On Thu, 23 Mar 2023 11:46:12 GMT, Thomas Stuefe wrote:
> There are variants of this play, but my point is the resulting crashes may
> happen after AGCT was invoked.
I see the problem. Thanks for adding some clarification. We can all agree that
my intended fix is not really a fix.
>So all we s
On Thu, 23 Mar 2023 08:36:59 GMT, Erik Österlund wrote:
>> The best alternative to me is to take the perf hit and disable the caching
>> when we're in forte (possibly only on Mac).
>
>> The best alternative to me is to take the perf hit and disable the caching
>> when we're in forte (possibly o
On Wed, 22 Mar 2023 17:42:35 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>>
On Thu, 23 Mar 2023 08:36:59 GMT, Erik Österlund wrote:
>> The best alternative to me is to take the perf hit and disable the caching
>> when we're in forte (possibly only on Mac).
>
>> The best alternative to me is to take the perf hit and disable the caching
>> when we're in forte (possibly o
On Thu, 23 Mar 2023 08:36:59 GMT, Erik Österlund wrote:
>> The best alternative to me is to take the perf hit and disable the caching
>> when we're in forte (possibly only on Mac).
>
>> The best alternative to me is to take the perf hit and disable the caching
>> when we're in forte (possibly o
On Thu, 23 Mar 2023 08:36:59 GMT, Erik Österlund wrote:
> > The best alternative to me is to take the perf hit and disable the caching
> > when we're in forte (possibly only on Mac).
>
> Sounds like a plan.
I'm going to write some code to check the performance impact of disabling it,
on Mac a
> Fixes the issue by transitioning the thread into the WXWrite mode while
> walking the stack in AsyncGetCallTrace.
>
> Tested on my M1 mac.
Johannes Bechberger has updated the pull request incrementally with one
additional commit since the last revision:
Use raw_thread instead of Thread::cu
On Thu, 23 Mar 2023 08:20:18 GMT, Johannes Bechberger
wrote:
>> Fixes the issue by transitioning the thread into the WXWrite mode while
>> walking the stack in AsyncGetCallTrace.
>>
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additiona
On Thu, 23 Mar 2023 08:27:23 GMT, Johannes Bechberger
wrote:
> The best alternative to me is to take the perf hit and disable the caching
> when we're in forte (possibly only on Mac).
Sounds like a plan.
-
PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1480784139
On Thu, 23 Mar 2023 08:20:18 GMT, Johannes Bechberger
wrote:
>> Fixes the issue by transitioning the thread into the WXWrite mode while
>> walking the stack in AsyncGetCallTrace.
>>
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additiona
On Thu, 23 Mar 2023 06:09:42 GMT, Chris Plummer wrote:
>> Yes, this is from the PR description:
>>> New function JvmtiEnvBase::disable_virtual_threads_notify_jvmti() which is
>>> needed for testing.
>>> It is used by the WhiteBox API.
>>
>> Do you think a comment is needed?
>
> I was wondering
On Thu, 23 Mar 2023 07:27:14 GMT, Johannes Bechberger
wrote:
> > You now effectively disable execution of generated code for the whole
> > extend of AGCT?
>
>
>
> That's exactly what async-profiler does already
> https://github.com/async-profiler/async-profiler/blob/c8de91df6b090af82e91a066
On Thu, 23 Mar 2023 08:20:18 GMT, Johannes Bechberger
wrote:
>> Fixes the issue by transitioning the thread into the WXWrite mode while
>> walking the stack in AsyncGetCallTrace.
>>
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additiona
> Fixes the issue by transitioning the thread into the WXWrite mode while
> walking the stack in AsyncGetCallTrace.
>
> Tested on my M1 mac.
Johannes Bechberger has updated the pull request incrementally with one
additional commit since the last revision:
Make _wx_state volatile
---
On Thu, 23 Mar 2023 07:03:04 GMT, Thomas Stuefe wrote:
> You now effectively disable execution of generated code for the whole extend
> of AGCT?
That's exactly what async-profiler does already
https://github.com/async-profiler/async-profiler/blob/c8de91df6b090af82e91a066deb81a3afb505331/src/pr
On Wed, 22 Mar 2023 15:57:40 GMT, Johannes Bechberger
wrote:
> Fixes the issue by transitioning the thread into the WXWrite mode while
> walking the stack in AsyncGetCallTrace.
>
> Tested on my M1 mac.
Drive by comment: how async safe is WX enabler? If a thread is in the middle of
it and we
On Thu, 23 Mar 2023 06:05:33 GMT, Johannes Bechberger
wrote:
>> Seems okay. But I am really over this game of whack-a-mole with
>> ThreadWXEnable.
>
>> Seems okay. But I am really over this game of whack-a-mole with
>> ThreadWXEnable.
>
> You're not the only one.
>
> Andrei Pangin added a w
On Wed, 22 Mar 2023 17:42:35 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>>
On Wed, 22 Mar 2023 15:57:40 GMT, Johannes Bechberger
wrote:
> Fixes the issue by transitioning the thread into the WXWrite mode while
> walking the stack in AsyncGetCallTrace.
>
> Tested on my M1 mac.
Okay. Though the prospect of async profiler modifying the code cache by walking
the stack
On Thu, 23 Mar 2023 05:43:35 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.hpp line 87:
>>
>>> 85:
>>> 86: static bool enable_virtual_threads_notify_jvmti();
>>> 87: static bool disable_virtual_threads_notify_jvmti();
>>
>> "disable" only seems to be used by the WB AP
54 matches
Mail list logo
