On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer wrote:
>> There are a few nsk debugger tests that pin multiple virtual threads to
>> carrier threads when synchronizing. Sometime the default number of carrier
>> threads (which equals the number of CPUs) is not enough, and the test
>> deadlocks
On Mon, 19 Dec 2022 12:50:11 GMT, Serguei Spitsyn wrote:
>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS
>> transitions for all virtual threads only. It should also support disabling
>> transitions for any specific virtual thread as well. This will improve
>> scalabi
On Mon, 19 Dec 2022 12:27:08 GMT, Serguei Spitsyn wrote:
>> @dholmes-ora
>> Thank you for looking at this fix and for the comments.
>> I will on replying and resolving them.
>
> This update just follows the common pattern which was introduced about two
> years ago. At the moment I do not remembe
On Mon, 19 Dec 2022 11:32:40 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/classfile/javaClasses.cpp line 1745:
>>
>>> 1743: int val = VTMS_transition_disable_count(java_thread);
>>> 1744:
>>> java_thread->int_field_put(_jvmti_VTMS_transition_disable_count_offset, val
>>> - 1);
>>> 1745
On Mon, 19 Dec 2022 12:13:42 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiThreadState.cpp line 298:
>>
>>> 296: HandleMark hm(thread);
>>> 297: Handle vth = Handle(thread,
>>> JNIHandles::resolve_external_guard(_vthread));
>>> 298: if (!java_lang_VirtualThread::is_instance(
On Tue, 20 Dec 2022 02:19:31 GMT, David Holmes wrote:
> This sounds like a bug with the underlying executor. If the VT's pin their
> carrier threads then the executor should increase its parallelism level
> automatically to compensate for that.
It's probably best if @AlanBateman explains this
On Tue, 20 Dec 2022 02:04:01 GMT, Chris Plummer wrote:
> There are a few nsk debugger tests that pin multiple virtual threads to
> carrier threads when synchronizing. Sometime the default number of carrier
> threads (which equals the number of CPUs) is not enough, and the test
> deadlocks beca
> There are a few nsk debugger tests that pin multiple virtual threads to
> carrier threads when synchronizing. Sometime the default number of carrier
> threads (which equals the number of CPUs) is not enough, and the test
> deadlocks because virtual threads start to wait forever for an availabl
There are a few nsk debugger tests that pin multiple virtual threads to carrier
threads when synchronizing. Sometime the default number of carrier threads
(which equals the number of CPUs) is not enough, and the test deadlocks because
virtual threads start to wait forever for an available carrie
On Tue, 13 Dec 2022 22:34:06 GMT, Chris Plummer wrote:
> The following ProblemList-zgc.txt entries need a lot of cleanup.
>
> serviceability/sa/ClhsdbCDSCore.java 8268722
> macosx-x64
> serviceability/sa/ClhsdbFindPC.java#xcomp-core8268722,8284045
>
On Tue, 13 Dec 2022 22:34:06 GMT, Chris Plummer wrote:
> The following ProblemList-zgc.txt entries need a lot of cleanup.
>
> serviceability/sa/ClhsdbCDSCore.java 8268722
> macosx-x64
> serviceability/sa/ClhsdbFindPC.java#xcomp-core8268722,8284045
>
> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS
> transitions for all virtual threads only. It should also support disabling
> transitions for any specific virtual thread as well. This will improve
> scalability of the JVMTI functions operating on target virtual threads
On Fri, 16 Dec 2022 14:14:54 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiThreadState.cpp line 304:
>>
>>> 302:
>>> 303: ThreadBlockInVM tbivm(thread);
>>> 304: MonitorLocker ml(JvmtiVTMSTransition_lock,
>>> Mutex::_no_safepoint_check_flag);
>>
>> Aside: this pattern looks
On Fri, 16 Dec 2022 02:15:38 GMT, David Holmes wrote:
>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS
>> transitions for all virtual threads only. It should also support disabling
>> transitions for any specific virtual thread as well. This will improve
>> scalabilit
On Fri, 16 Dec 2022 02:14:24 GMT, David Holmes wrote:
>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS
>> transitions for all virtual threads only. It should also support disabling
>> transitions for any specific virtual thread as well. This will improve
>> scalabilit
On Fri, 16 Dec 2022 02:10:09 GMT, David Holmes wrote:
>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS
>> transitions for all virtual threads only. It should also support disabling
>> transitions for any specific virtual thread as well. This will improve
>> scalabilit
On Thu, 15 Dec 2022 21:20:31 GMT, David Holmes wrote:
>> This is a simple cleanup RFE to get rid of old-style C casts in relation to
>> JavaThread.
>>
>> In many cases involving NULL/nullptr the cast could just be dropped.
>> Sometimes a static cast is needed to disambiguate overloads.
>>
>>
17 matches
Mail list logo
