Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v3]

2024-03-27 Thread Serguei Spitsyn
On Wed, 27 Mar 2024 05:12:53 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains three additional >>

Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v4]

2024-03-27 Thread Serguei Spitsyn
> This PR fixes a synchronization issue in the test: > `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` > > The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it > has not reached an expected breakpoint yet. > The fix is to add a call to the method

Re: RFR: JDK-8327769: jcmd GC.heap_dump without options should write to location given by -XX:HeapDumpPath, if set [v9]

2024-03-27 Thread Matthias Baesken
On Tue, 26 Mar 2024 21:42:15 GMT, Chris Plummer wrote: > A docs CR will need to be filed to get it updated (and I see it is already > appears out-of-date w.r.t. HeapDumpGzipLevel) Sorry maybe it is maybe obvious for you but where should I open a "docs CR", would that be a separate JBS issue

Re: RFR: 8318026: jcmd should provide access to detailed JVM object information [v10]

2024-03-27 Thread Kevin Walls
> 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

Re: RFR: JDK-8327769: jcmd GC.heap_dump without options should write to location given by -XX:HeapDumpPath, if set [v10]

2024-03-27 Thread Matthias Baesken
> 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 the is optional. > In case the filename is NOT set, we take the

Re: RFR: 8318026: jcmd should provide access to detailed JVM object information [v9]

2024-03-27 Thread Thomas Stuefe
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

Re: RFR: 8318026: jcmd should provide access to detailed JVM object information [v10]

2024-03-27 Thread Kevin Walls
On Wed, 27 Mar 2024 12:23:50 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

Re: RFR: 8329204: Diagnostic command for zeroing unused parts of the heap [v2]

2024-03-27 Thread Volker Simonis
> Diagnostic command for zeroing unused parts of the heap > > I propose to add a new diagnostic command `System.zero_unused_memory` which > zeros out all unused parts of the heap. The name of the command is > intentionally GC/heap agnostic because in the future it might be extended to > also

Re: RFR: 8318026: jcmd should provide access to detailed JVM object information [v9]

2024-03-27 Thread Chris Plummer
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 >

RFR: 8329204: Diagnostic command for zeroing unused parts of the heap

2024-03-27 Thread Volker Simonis
Diagnostic command for zeroing unused parts of the heap I propose to add a new diagnostic command `System.zero_unused_memory` which zeros out all unused parts of the heap. The name of the command is intentionally GC/heap agnostic because in the future it might be extended to also zero unused

Re: RFR: 8318026: jcmd should provide access to detailed JVM object information [v9]

2024-03-27 Thread Kevin Walls
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

Re: RFR: 8318026: jcmd should provide access to detailed JVM object information [v11]

2024-03-27 Thread Kevin Walls
> 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

Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v4]

2024-03-27 Thread Chris Plummer
On Wed, 27 Mar 2024 06:44:37 GMT, Serguei Spitsyn wrote: >> This PR fixes a synchronization issue in the test: >> `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` >> >> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it >> has not reached an expected

Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

2024-03-27 Thread Pavel Rappo
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote: > Please review the updates to support a proposed new > `-Xlint:dangling-doc-comments` option. > > The work can be thought of as in 3 parts: > > 1. An update to the `javac` internal class `DeferredLintHandler` so that it > is possible

Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v4]

2024-03-27 Thread Daniel D . Daugherty
On Wed, 27 Mar 2024 20:08:19 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one >> additional commit since the last revision: >> >> review: improve diagnostics and reliability > >

RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

2024-03-27 Thread Jonathan Gibbons
Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option. The work can be thought of as in 3 parts: 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to

Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

2024-03-27 Thread Pavel Rappo
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote: > Please review the updates to support a proposed new > `-Xlint:dangling-doc-comments` option. > > The work can be thought of as in 3 parts: > > 1. An update to the `javac` internal class `DeferredLintHandler` so that it > is possible

Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

2024-03-27 Thread Pavel Rappo
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote: > Please review the updates to support a proposed new > `-Xlint:dangling-doc-comments` option. > > The work can be thought of as in 3 parts: > > 1. An update to the `javac` internal class `DeferredLintHandler` so that it > is possible

Re: RFR: JDK-8327769: jcmd GC.heap_dump without options should write to location given by -XX:HeapDumpPath, if set [v10]

2024-03-27 Thread David Holmes
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

Re: RFR: JDK-8327769: jcmd GC.heap_dump without options should write to location given by -XX:HeapDumpPath, if set [v9]

2024-03-27 Thread Chris Plummer
On Wed, 27 Mar 2024 12:36:31 GMT, Matthias Baesken wrote: > Sorry maybe it is maybe obvious for you but where should I open a "docs CR", > would that be a separate JBS issue with Component name docs ? You would file a JBS issue with component "docs" and subcategory "hotspot". But let's hold

Re: RFR: JDK-8327769: jcmd GC.heap_dump without options should write to location given by -XX:HeapDumpPath, if set [v10]

2024-03-27 Thread Chris Plummer
On Wed, 27 Mar 2024 23:05:22 GMT, David Holmes wrote: > Notwithstanding that there may be cases where this change would be > convenient... I did get feedback from a couple of our support engineers. One felt it was of no real benefit as it was just as easy to provide the filename as an

Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

2024-03-27 Thread Jonathan Gibbons
On Wed, 27 Mar 2024 22:41:33 GMT, Pavel Rappo wrote: > Would this be the first lint -- not doclint -- warning related to comments, > let alone doc comments? No. `-Xlint:dep-ann` correlates `@Deprecated` annotations with `@deprecated` tags in doc comments. >