On Thu, 26 May 2022 05:08:13 GMT, Ioi Lam wrote:
>> It seems that calculation of
>> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>>
>> Currently,
>> `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>>
>> ==> CodeHeap
On Wed, 25 May 2022 23:04:50 GMT, Leonid Mesnik wrote:
>> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line
>> 100:
>>
>>> 98: while (thread.getState() != Thread.State.BLOCKED) {
>>> 99: Thread.sleep(10);
>>> 100: if (thread.getState() =
On Mon, 23 May 2022 07:28:41 GMT, Yi Yang wrote:
> It seems that calculation of
> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>
> Currently,
> `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>
> ==> CodeHeap 'non-n
On Thu, 26 May 2022 02:35:08 GMT, David Holmes wrote:
>>> If virtual threads become permanent then the usage message would minimally
>>> be updated to drop the sentence that virtual threads are a preview feature.
>>
>> But that's precisely the commitment to this flag that I want to avoid. I
>
On Wed, 25 May 2022 16:11:52 GMT, Chris Plummer wrote:
>> If virtual threads become permanent then the usage message would minimally
>> be updated to drop the sentence that virtual threads are a preview feature.
>> At that point the debugger APIs may have been built out further and it might
>>
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
cc'ing hotspot-jfr-dev
On 26/05/2022 9:45 am, Mat Carter wrote:
The Microsoft Java Engineering Group (JEG) have been looking at how Java
developers can best understand the impact of their decisions on start-up time.
Specifically, how developers can identify and mitigate the dominant activities
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
The Microsoft Java Engineering Group (JEG) have been looking at how Java
developers can best understand the impact of their decisions on start-up time.
Specifically, how developers can identify and mitigate the dominant activities
that occur during start-up, through to their app / service reachi
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
On Wed, 25 May 2022 21:18:24 GMT, master-code-java
wrote:
>> Need to use proper synchronization.
>>
>> The CyclicBarriers might move the thread to WAITING state but not BLOCKED.
>> So it should not confuse existing checks.
>
> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.j
On Tue, 24 May 2022 19:52:57 GMT, Leonid Mesnik wrote:
> Need to use proper synchronization.
>
> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So
> it should not confuse existing checks.
test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 98
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
On Wed, 25 May 2022 06:23:48 GMT, Alan Bateman wrote:
> If virtual threads become permanent then the usage message would minimally be
> updated to drop the sentence that virtual threads are a preview feature.
But that's precisely the commitment to this flag that I want to avoid. I want
someth
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
On Tue, 24 May 2022 17:09:10 GMT, Magnus Ihse Bursie wrote:
> The logic in BASIC_SETUP_DEVKIT for setting a correct sysroot for Xcode is
> hard to follow. This should be straightened out. We also expose variables
> that are no longer used. So there's a bit of related cleanup.
>
> The new code
A part of this issue was contributed with the following changeset:
commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
Date: Mon Nov 8 14:45:04 2021 +
8249004: Reduce ThreadsListHandle overhead in relation to direct
21 matches
Mail list logo
