On Thu, 22 Dec 2022 06:23:25 GMT, David Holmes wrote:
> Yeah that isn't nice. I was thinking a more simple check of the property
> value against the required number of threads. Though based on your comment
> "nthreads+1" is not always enough so the check would not be sufficient.
I think I can
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 Tue, 20 Dec 2022 05:21:21 GMT, David Holmes wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Better comments.
>
> The JEP defines pinning as expected:
>> There are two scenarios in which a virtual thread cannot
On 3/11/2022 4:36 am, Mark Reinhold wrote:
https://openjdk.org/jeps/435
Summary: Define an efficient and reliable API to collect stack traces
asynchronously and include information on both Java and native stack
frames.
There has been some commentary on this in the JBS issue and some
Please review this change to WhiteBox and some tests involving G1 concurrent
GCs.
Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
concurrent GC. Many of them follow it with a loop waiting for a concurrent
cycle to not be in progress. A few also preceed that call with a sim
On Wed, 21 Dec 2022 21:33:28 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 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
> 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 Tue, 20 Dec 2022 10:22:03 GMT, Serguei Spitsyn wrote:
>> This can be a separate RFE if the reason for it being a nosafepoint lock no
>> longer holds. It would be cleaner to use a normal safepoint checking lock
>> than to artificially make the thread safepoint-safe before using it.
>
> Agreed
On Wed, 21 Dec 2022 09:31:51 GMT, David Holmes wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address wqsecond round review comments
>
> src/hotspot/share/classfile/javaClasses.cpp line 1739:
>
>> 1737: void j
On Tue, 20 Dec 2022 20:52:10 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
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 8943169791 ns.
GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=
On Tue, 20 Dec 2022 20:52:10 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
13 matches
Mail list logo
