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
On Wed, 27 Mar 2024 05:26:09 GMT, Chris Plummer wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Undo include
>
> src/hotspot/share/utilities/debug.cpp line 680:
>
>> 678:
>> 679: // Additional "good oop" checks,
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
On Wed, 27 Mar 2024 18:39:38 GMT, Chris Plummer wrote:
> I think we also need to consider the flip side of this argument. Is this
> something that some customers might want to always enable, but don't want to
> always have UnlockDiagnosticVMOptions enabled. A new command line flag would
> be
On Thu, 28 Mar 2024 14:12:08 GMT, Andrew Dinn wrote:
>>> It looks like the test only inspects a thread and a java object. Perhaps
>>> you could add tests for additional VM objects. Maybe grab a frame PC from a
>>> thread stack trace.
>>
>> Yes - added a couple of metadata tests, and a
On Wed, 27 Mar 2024 18:28:07 GMT, Kevin Walls wrote:
>> It looks like the test only inspects a thread and a java object. Perhaps you
>> could add tests for additional VM objects. Maybe grab a frame PC from a
>> thread stack trace.
>
>> It looks like the test only inspects a thread and a java
On Wed, 27 Mar 2024 09:33:43 GMT, Thomas Stuefe 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 often
>
On Wed, 27 Mar 2024 05:44:25 GMT, Chris Plummer wrote:
> It looks like the test only inspects a thread and a java object. Perhaps you
> could add tests for additional VM objects. Maybe grab a frame PC from a
> thread stack trace.
Yes - added a couple of metadata tests, and a compiled method
On Tue, 26 Mar 2024 21:55:38 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
On Tue, 26 Mar 2024 21:55:38 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
On Tue, 26 Mar 2024 21:55:38 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
On Tue, 26 Mar 2024 21:55:38 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
> 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
14 matches
Mail list logo
