On Mon, 8 Apr 2024 15:54:30 GMT, Kevin Walls wrote:
>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object
>> information.
>>
>> Not recommended for live production use. Requires UnlockDiagnosticVMOptions
>> and not included in jcmd help output, to remind us this is not
On Tue, 23 Jan 2024 13:04:43 GMT, SendaoYan wrote:
>> 8323640: [TESTBUG]testMemoryFailCount in
>> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail
>> because OOM killed
>
> SendaoYan has updated the pull request incrementally with one additional
> commit since the last rev
On Tue, 2 Apr 2024 00:22:28 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
On Tue, 2 Apr 2024 23:52:33 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
>> refac
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 Mon, 8 Apr 2024 15:54:30 GMT, Kevin Walls wrote:
>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object
>> information.
>>
>> Not recommended for live production use. Requires UnlockDiagnosticVMOptions
>> and not included in jcmd help output, to remind us this is not
> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object
> information.
>
> Not recommended for live production use. Requires UnlockDiagnosticVMOptions
> and not included in jcmd help output, to remind us this is not a
> general-purpose customer-facing tool.
Kevin Walls ha
> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object
> information.
>
> Not recommended for live production use. Requires UnlockDiagnosticVMOptions
> and not included in jcmd help output, to remind us this is not a
> general-purpose customer-facing tool.
Kevin Walls ha
On Thu, 4 Apr 2024 12:46:26 GMT, Kevin Walls wrote:
>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object
>> information.
>>
>> Not recommended for live production use. Requires UnlockDiagnosticVMOptions
>> and not included in jcmd help output, to remind us this is not
On Mon, 8 Apr 2024 13:20:03 GMT, Thomas Stuefe wrote:
> Thank you for answering our questions.
No problem, thanks Thomas and Andrew. 8-)
-
PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2043005639
On Thu, 28 Mar 2024 17:15:26 GMT, Kevin Walls wrote:
>>> In my opinion, UnlockDiagnosticVMOptions is not a good enough safeguard
>>> since it guards a whole swathe of switches that we may instruct the
>>> customer to enable. Once enabled, my experience is that
>>> UnlockDiagnosticVMOptions oft
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 Mon, 8 Apr 2024 06:47:09 GMT, Matthias Baesken wrote:
> If (3) has defaults, why (4) and (maybe) (5) don't have the same defaults?
I could open a separate JBS issue (or issues) for scenario 4 and 5 , if this is
desired.
-
PR Comment: https://git.openjdk.org/jdk/pull/18190#issue
13 matches
Mail list logo
