On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where th
On Tue, 9 Apr 2024 11:08:31 GMT, Kevin Walls wrote:
> This test incorrectly fails, although rarely, thinking its "thread 2" has
> deadlocked.
> A change of sleep will likely fix this, but there are other issues, so
> cleaning up the test a little.
>
> Remove the probe for the ManagementFactory
On Wed, 10 Apr 2024 00:28:01 GMT, Alex Menkov wrote:
> The test starts listening on dynamic port and calls stopListening with
> incorrect (cArgs1) and correct (cArgs2) argument maps.
> Incorrect map is created by finding "free" port (`(new
> ServerSocket(0)).getLocalPort()`)
> The test fails if
> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes
> were introduced in the JDK 22 to unify/simplify the JVM TI functions
> supporting implementation of the virtual threads. This enhancement is to
> refactor the JVM TI internal functions
> JvmtiEnvThreadState::reset_cu
On Thu, 4 Apr 2024 15:28:41 GMT, Serguei Spitsyn wrote:
> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes
> were introduced in the JDK 22 to unify/simplify the JVM TI functions
> supporting implementation of the virtual threads. This enhancement is to
> refactor the
> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure`
> classes were introduced in the JDK 22 to unify/simplify the JVM TI functions
> supporting implementation of the virtual threads. This enhancement is to
> refactor the JVM TI function `GetThreadListStackTraces` on the base
On Tue, 9 Apr 2024 00:56:16 GMT, Leonid Mesnik wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: cleanup - removed temporary logging used for debugging
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 207
> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure`
> classes were introduced in the JDK 22 to unify/simplify the JVM TI functions
> supporting implementation of the virtual threads. This enhancement is to
> refactor JVM TI functions `PopFrame` and `ForceEarlyReturn` on the
On Tue, 9 Apr 2024 12:10:57 GMT, Kevin Walls wrote:
> EnableVMInspectCommand
I can live with that.
-
PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2046351694
The test starts listening on dynamic port and calls stopListening with
incorrect (cArgs1) and correct (cArgs2) argument maps.
Incorrect map is created by finding "free" port (`(new
ServerSocket(0)).getLocalPort()`)
The test fails if the same port is selected later when the listening starts.
To av
On Tue, 9 Apr 2024 01:19:18 GMT, Leonid Mesnik wrote:
>> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure`
>> classes were introduced in the JDK 22 to unify/simplify the JVM TI functions
>> supporting implementation of the virtual threads. This enhancement is to
>> refacto
On Tue, 9 Apr 2024 01:18:35 GMT, Leonid Mesnik wrote:
>> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure`
>> classes were introduced in the JDK 22 to unify/simplify the JVM TI functions
>> supporting implementation of the virtual threads. This enhancement is to
>> refacto
> Hi all,
>
> Could anyone review this fix to make serial heap dump only write to a single
> file?
> We highly appreciate the work in https://bugs.openjdk.org/browse/JDK-8306441.
> However, many of our customers still need to use serial heap dump, as they
> have limited disk space and need to d
On Fri, 5 Apr 2024 12:50:04 GMT, Ludvig Janiuk wrote:
> I used "fold -sw 120" and removed trailing whitespaces.
I think using 100 would be more consistent with the rest of the file, although
you may need to undo some long "code" lines after the initial reformat.
-
PR Comment: http
On Thu, 4 Apr 2024 15:28:41 GMT, Serguei Spitsyn wrote:
> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes
> were introduced in the JDK 22 to unify/simplify the JVM TI functions
> supporting implementation of the virtual threads. This enhancement is to
> refactor the
On Fri, 5 Apr 2024 12:32:30 GMT, Stefan Karlsson wrote:
> The GCs scan and handles nmethods and ignores CodeBlobs of other kinds. The I
> propose that we stop sending in CodeBlobs to the GCs and make sure to only
> give them nmethods.
>
> I removed `void CodeCache::blobs_do(CodeBlobClosure* f)
On Tue, 9 Apr 2024 06:00:21 GMT, David Holmes wrote:
> sounds far too general. I would have expected something that was obviously
> connected to jcmd and/or the specific jcmd under discussion.
I don't expect so many more of these, but EnableVMInspectDCmd looked too
specific, I didn't want to p
This test incorrectly fails, although rarely, thinking its "thread 2" has
deadlocked.
A change of sleep will likely fix this, but there are other issues, so cleaning
up the test a little.
Remove the probe for the ManagementFactory class, to check we are on jdk5 or
later. 8-)
When sleeping, sle
On Fri, 5 Apr 2024 12:32:30 GMT, Stefan Karlsson wrote:
> The GCs scan and handles nmethods and ignores CodeBlobs of other kinds. The I
> propose that we stop sending in CodeBlobs to the GCs and make sure to only
> give them nmethods.
>
> I removed `void CodeCache::blobs_do(CodeBlobClosure* f)
> The GCs scan and handles nmethods and ignores CodeBlobs of other kinds. The I
> propose that we stop sending in CodeBlobs to the GCs and make sure to only
> give them nmethods.
>
> I removed `void CodeCache::blobs_do(CodeBlobClosure* f)` since there's no
> more usage of that function. Is this
20 matches
Mail list logo
