On Thu, 30 Nov 2023 21:27:27 GMT, Serguei Spitsyn wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled. Oth
On Thu, 30 Nov 2023 21:27:27 GMT, Serguei Spitsyn wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled. Oth
On Thu, 30 Nov 2023 21:27:27 GMT, Serguei Spitsyn wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled. Oth
On Thu, 30 Nov 2023 21:27:27 GMT, Serguei Spitsyn wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled. Oth
On Thu, 30 Nov 2023 20:58:41 GMT, Serguei Spitsyn wrote:
> It is a little bit ugly to do it for each call site.
> The Handshake::execute() can do it instead, so its call sites could be
> simplified.
> BTW, it is done in the JvmtiHandshake::execute() and one can find it to be
> convenient.
Agre
On Thu, 30 Nov 2023 21:27:27 GMT, Serguei Spitsyn wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled. Oth
On Thu, 30 Nov 2023 17:48:48 GMT, Daniel D. Daugherty
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: remove newly added ThreadsListHandle from enter_interp_only_mode
>
> src/hotspot/share/prims/jvmtiTh
> This is a fix of a performance/scalability related issue. The
> `JvmtiThreadState` objects for virtual thread filtered events enabled
> globally are created eagerly because it is needed when the `interp_only_mode`
> is enabled. Otherwise, some events which are generated in `interp_only_mode`
On Thu, 30 Nov 2023 17:35:57 GMT, Daniel D. Daugherty
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: remove newly added ThreadsListHandle from enter_interp_only_mode
>
> src/hotspot/share/prims/jvmtiTh
On Thu, 30 Nov 2023 17:33:28 GMT, Daniel D. Daugherty
wrote:
> I don't think we should change the guarantee() in Handshake::execute(). When
> the
> three parameter version of execute() is called with tlh == nullptr, the
> caller is
> saying that there is supposed to be a ThreadsListHandle in t
On Thu, 30 Nov 2023 17:33:28 GMT, Daniel D. Daugherty
wrote:
> Removing the TLH is the right thing to do. If we get that failure mode again,
> then we
can file a new bug and hopefully have an hs_err_pid file with it.
Agreed.
-
PR Comment: https://git.openjdk.org/jdk/pull/16686#is
On Thu, 30 Nov 2023 02:08:39 GMT, Serguei Spitsyn wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled. Oth
On Thu, 30 Nov 2023 02:08:39 GMT, Serguei Spitsyn wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled. Oth
> This is a fix of a performance/scalability related issue. The
> `JvmtiThreadState` objects for virtual thread filtered events enabled
> globally are created eagerly because it is needed when the `interp_only_mode`
> is enabled. Otherwise, some events which are generated in `interp_only_mode`
On Wed, 29 Nov 2023 21:05:31 GMT, Daniel D. Daugherty
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: add comment for new ThreadsListHandle use
>
> I'm going to resurrect the failing guarantee() code an
On Fri, 17 Nov 2023 20:29:11 GMT, Serguei Spitsyn wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled. Oth
On Mon, 20 Nov 2023 00:59:35 GMT, David Holmes wrote:
>> @dcubed-ojdk
>> I don't know FJP implementation well enough to point at the code where it
>> happens. However, I observe that new `JavaThread `is being created between
>> two points of the execution path.
>> - First point is in the `Jvmt
On Mon, 20 Nov 2023 00:59:35 GMT, David Holmes wrote:
>> The stack trace of current thread (where the assert was fired) can explain
>> what is going on a little bit:
>>
>> Current thread (0x7f93f8043d00): JavaThread "ForkJoinPool-1-worker-1"
>> daemon [_thread_in_vm, id=16779,
>> stack(0
On Sun, 19 Nov 2023 09:41:34 GMT, Serguei Spitsyn wrote:
>> @dcubed-ojdk
>> I don't know FJP implementation well enough to point at the code where it
>> happens. However, I observe that new `JavaThread `is being created between
>> two points of the execution path.
>> - First point is in the `J
On Sun, 19 Nov 2023 09:22:43 GMT, Serguei Spitsyn wrote:
>> @sspitsyn - Please point me at the code where these JavaThreads are newly
>> created?
>
> @dcubed-ojdk
> I don't know FJP implementation well enough to point at the code where it
> happens. However, I observe that new `JavaThread `is b
On Sun, 19 Nov 2023 03:47:45 GMT, Daniel D. Daugherty
wrote:
>> Thank you for the comment, Dan!
>> Agreed, the comment needs to be corrected in two aspects.
>> I tried to simplify it but failed to do it correctly.
>> It is interesting that there is a `ThreadsListHandle` farther up the stack
>>
On Sat, 18 Nov 2023 12:22:10 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEventController.cpp line 374:
>>
>>> 372: // Protects any existing JavaThread's from being terminated while it
>>> is set.
>>> 373: // The FJP carrier thread compensating mechanism can create carrier
>
On Fri, 17 Nov 2023 21:19:05 GMT, Daniel D. Daugherty
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: add comment for new ThreadsListHandle use
>
> src/hotspot/share/prims/jvmtiEventController.cpp line
On Fri, 17 Nov 2023 20:29:11 GMT, Serguei Spitsyn wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled. Oth
On Fri, 17 Nov 2023 18:52:20 GMT, Chris Plummer wrote:
>> The `tlh` is used to protect any existing at this point JavaThread's from
>> being terminated while it is set.
>> My understanding is that there is no need to iterate over all threads in the
>> list to get this protection.
>
> Ok. A comm
> This is a fix of a performance/scalability related issue. The
> `JvmtiThreadState` objects for virtual thread filtered events enabled
> globally are created eagerly because it is needed when the `interp_only_mode`
> is enabled. Otherwise, some events which are generated in `interp_only_mode`
On Fri, 17 Nov 2023 07:23:46 GMT, Serguei Spitsyn wrote:
>> I see the PR comment, but I don't really understand it. Is this to force
>> some sort of early initialization to avoid a race later on? It just seems
>> odd to create the tlh, but never use it.
>
> The `tlh` is used to protect any exis
> This is a fix of a performance/scalability related issue. The
> `JvmtiThreadState` objects for virtual thread filtered events enabled
> globally are created eagerly because it is needed when the `interp_only_mode`
> is enabled. Otherwise, some events which are generated in `interp_only_mode`
On Fri, 17 Nov 2023 05:43:21 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiThreadState.cpp line 531:
>>
>>> 529:
>>> 530: // JvmtiThreadState objects for virtual thread filtered events
>>> enabled globally
>>> 531: // must be created eagerly if the interp_only_mode is enabled
On Fri, 17 Nov 2023 05:55:44 GMT, Chris Plummer wrote:
>> This is explained in the PR description.
>> Do you think, a just comment is needed or this has to be separated from this
>> fix?
>
> I see the PR comment, but I don't really understand it. Is this to force some
> sort of early initializa
On Fri, 17 Nov 2023 05:38:28 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEventController.cpp line 372:
>>
>>> 370: return; // EnterInterpOnlyModeClosure will be executed right
>>> after mount.
>>> 371: }
>>> 372: ThreadsListHandle tlh(current);
>>
>> Why was this added
On Thu, 16 Nov 2023 21:36:28 GMT, Chris Plummer wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled. Other
On Thu, 16 Nov 2023 11:15:27 GMT, Serguei Spitsyn wrote:
> This is a fix of a performance/scalability related issue. The
> `JvmtiThreadState` objects for virtual thread filtered events enabled
> globally are created eagerly because it is needed when the `interp_only_mode`
> is enabled. Otherwi
This is a fix of a performance/scalability related issue. The
`JvmtiThreadState` objects for virtual thread filtered events enabled globally
are created eagerly because it is needed when the `interp_only_mode` is
enabled. Otherwise, some events which are generated in `interp_only_mode` from
the
34 matches
Mail list logo
