Re: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases

2022-01-18 Thread Aleksey Shipilev
On Tue, 18 Jan 2022 19:36:18 GMT, Chris Plummer wrote: >> While working on JDK-8280003, I noticed that >> java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays >> with more than 1-byte size elements, and no large arrays (past 4G limit) are >> tested either. It would be bet

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v2]

2022-01-18 Thread Ioi Lam
On Wed, 19 Jan 2022 02:50:16 GMT, Chris Plummer wrote: > > > It seems it would be useful to support the verbose output with just a > > > single class that is specified, although that would suggest that the dcmd > > > name should then be something other than `VM.classes`. > > > > > > This is a

Re: RFR: 8279124: VirtualMachineImpl should check signal handler has installed before sending SIGQUIT [v2]

2022-01-18 Thread David Holmes
On Tue, 18 Jan 2022 19:44:12 GMT, Xin Liu wrote: >> src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c line 164: >> >>> 162: { >>> 163: // Only give up sending SIGQUIT if we see that SigCgt is not set. >>> 164: if (check_sigquit_caught(pid) == 0) return; >> >> Suggestion (assume

Re: RFR: 8279124: VirtualMachineImpl should check signal handler has installed before sending SIGQUIT [v2]

2022-01-18 Thread David Holmes
On Wed, 19 Jan 2022 06:54:01 GMT, Xin Liu wrote: >> src/hotspot/os/posix/signals_posix.cpp line 597: >> >>> 595: #endif >>> 596: >>> 597: if (!signal_was_handled && sig == BREAK_SIGNAL) { >> >> I would print out a little message, since callers of SIGQUIT may expect >> something to happen he

Re: RFR: 8279124: VirtualMachineImpl should check signal handler has installed before sending SIGQUIT

2022-01-18 Thread Xin Liu
On Mon, 17 Jan 2022 09:52:04 GMT, Thomas Stuefe wrote: > > > I propose a simpler and more robust way to fix it though > > > > > > Great, this is the kind of thing I was heading towards with the > > conversation in the bug text. Although not sure why I could not reproduce > > the problem, with

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v2]

2022-01-18 Thread David Holmes
On Wed, 19 Jan 2022 02:29:22 GMT, Yi Yang wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 2100: >> >>> 2098: char buf[10]; >>> 2099: int i = 0; >>> 2100: if (k->has_finalizer()) buf[i++] = 'F'; >> >> Where is the meaning of these flags documented? > > I don't find a proper place t

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v2]

2022-01-18 Thread David Holmes
On Wed, 19 Jan 2022 02:19:02 GMT, Yi Yang wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 2103: >> >>> 2101: if (k->has_final_method()) buf[i++] = 'f'; >>> 2102: if (k->has_vanilla_constructor()) buf[i++] = 'V'; >>> 2103: if (k->is_instance_klass()) { >> >> Don't the properties qu

Re: RFR: 8279124: VirtualMachineImpl should check signal handler has installed before sending SIGQUIT [v2]

2022-01-18 Thread Xin Liu
On Wed, 19 Jan 2022 06:49:54 GMT, Thomas Stuefe wrote: >> Xin Liu has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Intercept SIGQUIT in the early stage of HotSpot. > > src/hotspot/os/posix/signals_posix.cpp line 597: > >> 595: #endif >>

Re: RFR: 8279124: VirtualMachineImpl should check signal handler has installed before sending SIGQUIT [v2]

2022-01-18 Thread Thomas Stuefe
On Wed, 19 Jan 2022 05:21:04 GMT, Xin Liu wrote: >> There is a handshake protocol between attach and HotSpot. Linux >> VirtualMachineImpl sends SIGQUIT(3) if the AttachListener has not been >> initialized. It expects "Signal Dispatcher" to handle SIGBREAK(same as >> SIGQUIT) and create AttachL

Re: RFR: 8270199: Most SA tests are skipped on macosx-aarch64 because all executables are signed

2022-01-18 Thread David Holmes
On Tue, 21 Dec 2021 06:17:25 GMT, Chris Plummer wrote: > For any SA test that attaches to an OSX process (this would be all SA tests > except for those that test core file support), there is a check to make sure > that the target jvm process is not a signed binary. If it is, > SkippedException

Re: RFR: 8269542: JDWP: EnableCollection support is no longer spec compliant after JDK-8255987

2022-01-18 Thread David Holmes
On Wed, 19 Jan 2022 05:58:01 GMT, Chris Plummer wrote: >> ok > > I though normally we just gave the name of the argument in the comment, and > not apply the value. So in the above case we would use `JNI_FALSE /* pinAll > */`. AFAIAA both styles are used in different places, so whichever you pr

Re: RFR: 8269542: JDWP: EnableCollection support is no longer spec compliant after JDK-8255987

2022-01-18 Thread Chris Plummer
On Wed, 19 Jan 2022 04:40:57 GMT, Chris Plummer wrote: >> src/jdk.jdwp.agent/share/native/libjdwp/commonRef.c line 532: >> >>> 530: jobject strongRef; >>> 531: >>> 532: strongRef = strengthenNode(env, node, JNI_FALSE); >> >> Can you comment the JNI_FALSE parameter in th

Re: RFR: 8279124: VirtualMachineImpl should check signal handler has installed before sending SIGQUIT

2022-01-18 Thread Xin Liu
On Mon, 17 Jan 2022 09:52:04 GMT, Thomas Stuefe wrote: >>> I propose a simpler and more robust way to fix it though >> >> Great, this is the kind of thing I was heading towards with the conversation >> in the bug text. Although not sure why I could not reproduce the problem, >> with various d

Re: RFR: 8269542: JDWP: EnableCollection support is no longer spec compliant after JDK-8255987

2022-01-18 Thread David Holmes
On Wed, 19 Jan 2022 04:41:30 GMT, Chris Plummer wrote: >> src/jdk.jdwp.agent/share/native/libjdwp/util.h line 69: >> >>> 67: jint count; /* count of references */ >>> 68: jboolean isStrong; /* true if this is a strong reference. >>> Either or both of isPinAll >>

Re: RFR: 8279124: VirtualMachineImpl should check signal handler has installed before sending SIGQUIT [v2]

2022-01-18 Thread Xin Liu
> There is a handshake protocol between attach and HotSpot. Linux > VirtualMachineImpl sends SIGQUIT(3) if the AttachListener has not been > initialized. It expects "Signal Dispatcher" to handle SIGBREAK(same as > SIGQUIT) and create AttachListener. However, it is possible that attach > starts

Re: RFR: 8269542: JDWP: EnableCollection support is no longer spec compliant after JDK-8255987

2022-01-18 Thread Chris Plummer
On Wed, 19 Jan 2022 04:28:34 GMT, David Holmes wrote: > Hi Chris, > > Your links to JDK-8269232 actually go to the wrong bug. Ok. Fixed. > src/jdk.jdwp.agent/share/native/libjdwp/commonRef.c line 532: > >> 530: jobject strongRef; >> 531: >> 532: strongRef = strengthen

Re: RFR: 8269542: JDWP: EnableCollection support is no longer spec compliant after JDK-8255987

2022-01-18 Thread David Holmes
On Tue, 18 Jan 2022 20:25:41 GMT, Chris Plummer wrote: > The JDWP spec mentions nothing about `DisableCollection` and > `EnableCollection` tracking the depth or nesting of the commands. This means > that `EnableCollection` should enable collection no matter how many > `DisableCollection` comma

Re: RFR: 8269542: JDWP: EnableCollection support is no longer spec compliant after JDK-8255987

2022-01-18 Thread David Holmes
On Tue, 18 Jan 2022 20:25:41 GMT, Chris Plummer wrote: > The JDWP spec mentions nothing about `DisableCollection` and > `EnableCollection` tracking the depth or nesting of the commands. This means > that `EnableCollection` should enable collection no matter how many > `DisableCollection` comma

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v2]

2022-01-18 Thread Chris Plummer
On Wed, 19 Jan 2022 02:42:13 GMT, Yi Yang wrote: > > It seems it would be useful to support the verbose output with just a > > single class that is specified, although that would suggest that the dcmd > > name should then be something other than `VM.classes`. > > This is a good idea, but `jcmd

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v2]

2022-01-18 Thread Yi Yang
On Tue, 18 Jan 2022 19:43:12 GMT, Chris Plummer wrote: > It seems it would be useful to support the verbose output with just a single > class that is specified, although that would suggest that the dcmd name > should then be something other than `VM.classes`. This is a good idea, but `jcmd VM.

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v3]

2022-01-18 Thread Yi Yang
> Add VM.classes to print details of all classes, output looks like: > > 1. jcmd VM.classes > > KlassAddr Size State Flags LoaderName ClassName > 0x000800c0b400 62 inited W bootstrap > java.lang.invoke.LambdaForm$MH/0x000800c0b400 > 0x000800c0b000 62 inited W bootstrap > java.lang.i

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v2]

2022-01-18 Thread Yi Yang
On Tue, 18 Jan 2022 03:10:11 GMT, David Holmes wrote: >> Yi Yang has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. The pull request contains one >> new commit si

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v2]

2022-01-18 Thread Yi Yang
On Tue, 18 Jan 2022 03:04:15 GMT, David Holmes wrote: >> Yi Yang has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. The pull request contains one >> new commit si

Re: RFR: 8269542: JDWP: EnableCollection support is no longer spec compliant after JDK-8255987

2022-01-18 Thread Chris Plummer
On Tue, 18 Jan 2022 20:25:41 GMT, Chris Plummer wrote: > The JDWP spec mentions nothing about `DisableCollection` and > `EnableCollection` tracking the depth or nesting of the commands. This means > that `EnableCollection` should enable collection no matter how many > `DisableCollection` comma

RFR: 8269542: JDWP: EnableCollection support is no longer spec compliant after JDK-8255987

2022-01-18 Thread Chris Plummer
The JDWP spec mentions nothing about `DisableCollection` and `EnableCollection` tracking the depth or nesting of the commands. This means that `EnableCollection` should enable collection no matter how many `DisableCollection` commands were done before it. This is how the debug agent used to wor

RFR: 8270199: Most SA tests are skipped on macosx-aarch64 because all executables are signed

2022-01-18 Thread Chris Plummer
For any SA test that attaches to an OSX process (this would be all SA tests except for those that test core file support), there is a check to make sure that the target jvm process is not a signed binary. If it is, SkippedException is thrown, and the test passes without doing anything. This is a

Re: RFR: 8279124: VirtualMachineImpl should check signal handler has installed before sending SIGQUIT

2022-01-18 Thread Xin Liu
On Mon, 17 Jan 2022 06:11:22 GMT, David Holmes wrote: >> There is a handshake protocol between attach and HotSpot. Linux >> VirtualMachineImpl sends SIGQUIT(3) if the AttachListener has not been >> initialized. It expects "Signal Dispatcher" to handle SIGBREAK(same as >> SIGQUIT) and create At

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v2]

2022-01-18 Thread Chris Plummer
On Tue, 18 Jan 2022 02:50:06 GMT, Yi Yang wrote: >> Add VM.classes to print details of all classes, output looks like: >> >> 1. jcmd VM.classes >> >> KlassAddr Size State Flags LoaderName ClassName >> 0x000800c0b400 62 inited W bootstrap >> java.lang.invoke.LambdaForm$MH/0x000800c0b400

Re: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases

2022-01-18 Thread Chris Plummer
On Tue, 18 Jan 2022 18:33:29 GMT, Aleksey Shipilev wrote: > While working on JDK-8280003, I noticed that > java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays > with more than 1-byte size elements, and no large arrays (past 4G limit) are > tested either. It would be bett

Integrated: 8176567: nsk/jdi/ReferenceType/instances/instances002: TestFailure: Unexpected size of referenceType.instances(nsk.share.jdi.TestInterfaceImplementer1): 11, expected: 10

2022-01-18 Thread Chris Plummer
On Sun, 2 Jan 2022 04:06:05 GMT, Chris Plummer wrote: > The test is failing because it is detecting an extra instance of > `TestClass1`. The test (the debugger side) first tells the debuggee to create > 10 instances of `TestClass1`. The debugger then uses JDI > `ClassType.newInstance()` to cre

Re: Deprecate DTrace support

2022-01-18 Thread Laurence Cable
On 1/18/22 10:24 AM, Vladimir Kozlov wrote: Hi The question about dropping DTrace support in HotSpot VM rose during discussion 8278423: "ExtendedDTraceProbes should be deprecated" [1]. It is not clear for me about Oracle support for it after we dropped SPARC. Do we still need to support i

Re: RFR: 8176567: nsk/jdi/ReferenceType/instances/instances002: TestFailure: Unexpected size of referenceType.instances(nsk.share.jdi.TestInterfaceImplementer1): 11, expected: 10 [v2]

2022-01-18 Thread Chris Plummer
On Mon, 10 Jan 2022 17:40:12 GMT, Alex Menkov wrote: >> Chris Plummer has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix indentation > > src/jdk.jdwp.agent/share/native/libjdwp/invoker.c line 802: > >> 800: */ >> 801:

Re: RFR: 8176567: nsk/jdi/ReferenceType/instances/instances002: TestFailure: Unexpected size of referenceType.instances(nsk.share.jdi.TestInterfaceImplementer1): 11, expected: 10 [v2]

2022-01-18 Thread Chris Plummer
> The test is failing because it is detecting an extra instance of > `TestClass1`. The test (the debugger side) first tells the debuggee to create > 10 instances of `TestClass1`. The debugger then uses JDI > `ClassType.newInstance()` to create 100 more instances. It then resumes the > debuggee

Integrated: 8250801: Add clhsdb "threadcontext" command

2022-01-18 Thread Chris Plummer
On Thu, 23 Dec 2021 04:06:58 GMT, Chris Plummer wrote: > SA has the ability to fetch the thread's registers via the thread context. It > would be nice to allow access to the registers from clhsdb. This plays in > well with the enhancements being done to PointerFinder as part of > JDK-8247514.

Integrated: 8279194: Add Annotated Memory Viewer feature to SA's HSDB

2022-01-18 Thread Chris Plummer
On Thu, 23 Dec 2021 03:31:44 GMT, Chris Plummer wrote: > HSDB has a Memory Viewer feature that brings up a window that shows the > memory contents in a specific address range. It basically looks just like the > clhsdb "mem" output. The recently revived "mem" command (see > [JDK-824466](https:/

RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases

2022-01-18 Thread Aleksey Shipilev
While working on JDK-8280003, I noticed that java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays with more than 1-byte size elements, and no large arrays (past 4G limit) are tested either. It would be better to add those test cases. Additional testing: - [x] Linux x86_6

Deprecate DTrace support

2022-01-18 Thread Vladimir Kozlov
Hi The question about dropping DTrace support in HotSpot VM rose during discussion 8278423: "ExtendedDTraceProbes should be deprecated" [1]. It is not clear for me about Oracle support for it after we dropped SPARC. Do we still need to support it or we can drop it (remove code from HotSpot)?

Integrated: 8280010: Remove double buffering of InputStream for Properties.load

2022-01-18 Thread Andrey Turbanov
On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already > buffers input stream. Hence wrapping InputStream in BufferedInputStream is > redundant. This pull request has now been integrated. Changeset: 9eb50a5e Auth

Re: RFR: 8269537: memset() is called after operator new [v4]

2022-01-18 Thread Leo Korinth
On Wed, 20 Oct 2021 09:36:38 GMT, Leo Korinth wrote: >> The basic problem is that we are relying on undefined behaviour, as >> documented in the code: >> >> // This whole business of passing information from ResourceObj::operator new >> // to the ResourceObj constructor via fields in the "objec

Re: RFR: 8279124: VirtualMachineImpl should check signal handler has installed before sending SIGQUIT

2022-01-18 Thread David Holmes
On Mon, 17 Jan 2022 09:00:25 GMT, Kevin Walls wrote: >> Hi @navyxliu, >> >> nice catch. I can see how this can be annoying. >> >> I propose a simpler and more robust way to fix it though. We (1) set up >> general hotspot signal handling very early, then (2) proceed to initialize >> the heap -