From iklam at openjdk.java.net Tue Dec 1 01:14:55 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 01:14:55 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: <3wo_c-mOOD6m5wBMpO6uDXEi1SPBxAREMp8ai-814pY=.8f0a5223-a9ac-47e7-8c43-e1095e2aa3c6@github.com> On Mon, 30 Nov 2020 21:13:05 GMT, Harold Seigel wrote: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold LGTM. Thanks for fixing the CDS tests. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Tue Dec 1 01:18:54 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 01:18:54 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 21:13:05 GMT, Harold Seigel wrote: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold Hi Harold, I don't think we need to add all this new infrastructure for obsolete-aliased flags just so we can continue to print the -Xlog equivalents. I think simply adding these previously aliased flags as obsolete flags in the special flags table would suffice. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Tue Dec 1 01:33:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 01:33:58 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 01:16:11 GMT, David Holmes wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Hi Harold, > I don't think we need to add all this new infrastructure for obsolete-aliased flags just so we can continue to print the -Xlog equivalents. I think simply adding these previously aliased flags as obsolete flags in the special flags table would suffice. > Thanks, > David I should clarify this. I suggested in the bug report that we could continue to print the -Xlog equivalents, but when I wrote that I was thinking that the existing deprecated-aliased code would simply be changed to obsoleted-aliased code. I didn't consider that we might need to keep the deprecated-aliased code for future conversions to UL. But I can see now that we might want to do that. In which case I'd prefer to no longer print the -Xlog equivalents, rather than duplicate the deprecated-aliased code into an obsolete-aliased form. My intent was to get rid of this special aliased flag handling code in the near future. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From cjplummer at openjdk.java.net Tue Dec 1 01:45:56 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Dec 2020 01:45:56 GMT Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> Message-ID: On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga wrote: > > * Q3: What has to be done for statically linked agent? > > JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. ------------- PR: https://git.openjdk.java.net/jdk/pull/19 From dholmes at openjdk.java.net Tue Dec 1 02:25:55 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 02:25:55 GMT Subject: RFR: 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" [v2] In-Reply-To: References: <4GRPSMKxwFONrO-YzHXh7z8WxPHJM2tP0Y5X5uWnV10=.03265f2f-a4f7-4ef0-99e3-37701aa6b7fa@github.com> Message-ID: On Mon, 30 Nov 2020 12:57:36 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/jvmtiTagMap.cpp line 1162: >> >>> 1160: if (_needs_cleaning) { >>> 1161: // Recheck whether to post object free events under the lock. >>> 1162: post_object_free = post_object_free && env()->is_enabled(JVMTI_EVENT_OBJECT_FREE); >> >> Where is `is_enabled` called without the lock being held in a caller of `remove_dead_entries()`? > > void JvmtiTagMap::flush_object_free_events() { > assert_not_at_safepoint(); > if (env()->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { > > Called by JVMTI to disable events and called by the service thread. And here for get_objects_with_tags: > > if (collector.some_dead_found() && env()->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { > post_dead_objects_on_vm_thread(); > } That isn't quite what I asked. The claim is that `remove_dead_entries_locked` needs to recheck `is_enabled` if `post_object_free` is true in case the enabled state changed from true to false. But I can't see how such a situation can arise. In `flush_object_free_events` we only call `remove_dead_entries(false)` and that is when events were seen to be disabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/1439 From david.holmes at oracle.com Tue Dec 1 02:44:29 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2020 12:44:29 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> Message-ID: <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> On 1/12/2020 11:45 am, Chris Plummer wrote: > On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga wrote: > >>> * Q3: What has to be done for statically linked agent? >> >> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. > > I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. Agreed. Even though you can't physically unload the statically linked library, if it is logically unloaded by some mechanism, then Agent_OnUnload_L is supposed to be called. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/19 > From suenaga at oss.nttdata.com Tue Dec 1 04:46:14 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Tue, 1 Dec 2020 13:46:14 +0900 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> Message-ID: <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> Hi Chris, David, Currently Agent_OnUnload() is not called when Agent_OnLoad() is failed - JVM will abort. Should we re-think this behavior? https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld ``` $ java -agentpath:/path/to/libhelloworld.so=error --version Hello World from Agent_OnLoad() options = error Error occurred during initialization of VM agent library failed to init: /path/to/libhelloworld.so ``` Thanks, Yasumasa On 2020/12/01 11:44, David Holmes wrote: > On 1/12/2020 11:45 am, Chris Plummer wrote: >> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga wrote: >> >>>> * Q3: What has to be done for statically linked agent? >>> >>> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. >> >> I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. > > Agreed. Even though you can't physically unload the statically linked library, if it is logically unloaded by some mechanism, then Agent_OnUnload_L is supposed to be called. > > David > ----- > >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/19 >> From david.holmes at oracle.com Tue Dec 1 05:19:04 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2020 15:19:04 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> Message-ID: On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: > Hi Chris, David, > > Currently Agent_OnUnload() is not called when Agent_OnLoad() is failed - > JVM will abort. > Should we re-think this behavior? We should we rethink that? It is probably one of the clearest parts of the spec. If Agent_Onload fails that is considered a fatal error - end of story. The issue is with Agent_onAttach and how its failure should, or should not, impact Agent_OnUnload. David ----- > https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld > > ``` > $ java -agentpath:/path/to/libhelloworld.so=error --version > Hello World from Agent_OnLoad() > ? options = error > Error occurred during initialization of VM > agent library failed to init: /path/to/libhelloworld.so > ``` > > > Thanks, > > Yasumasa > > > On 2020/12/01 11:44, David Holmes wrote: >> On 1/12/2020 11:45 am, Chris Plummer wrote: >>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga >>> wrote: >>> >>>>> * Q3: What has to be done for statically linked agent? >>>> >>>> JVMTI spec says "unless it is statically linked into the >>>> executable", so I think we can ignore about Agent_OnUnload_L() in >>>> this PR. >>> >>> I don't think that makes sense. If you call it for dynamically linked >>> then you need to call it for statically linked also. >> >> Agreed. Even though you can't physically unload the statically linked >> library, if it is logically unloaded by some mechanism, then >> Agent_OnUnload_L is supposed to be called. >> >> David >> ----- >> >>> ------------- >>> >>> PR: https://git.openjdk.java.net/jdk/pull/19 >>> From david.holmes at oracle.com Tue Dec 1 05:21:27 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2020 15:21:27 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> Message-ID: On 1/12/2020 3:19 pm, David Holmes wrote: > On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >> Hi Chris, David, >> >> Currently Agent_OnUnload() is not called when Agent_OnLoad() is failed >> - JVM will abort. >> Should we re-think this behavior? > > We should we rethink that? It is probably one of the clearest parts of > the spec. If Agent_Onload fails that is considered a fatal error - end > of story. I meant, of course, "Why should we rethink that?". David > The issue is with Agent_onAttach and how its failure should, or should > not, impact Agent_OnUnload. > > David > ----- > >> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >> >> ``` >> $ java -agentpath:/path/to/libhelloworld.so=error --version >> Hello World from Agent_OnLoad() >> ?? options = error >> Error occurred during initialization of VM >> agent library failed to init: /path/to/libhelloworld.so >> ``` >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/12/01 11:44, David Holmes wrote: >>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga >>>> wrote: >>>> >>>>>> * Q3: What has to be done for statically linked agent? >>>>> >>>>> JVMTI spec says "unless it is statically linked into the >>>>> executable", so I think we can ignore about Agent_OnUnload_L() in >>>>> this PR. >>>> >>>> I don't think that makes sense. If you call it for dynamically >>>> linked then you need to call it for statically linked also. >>> >>> Agreed. Even though you can't physically unload the statically linked >>> library, if it is logically unloaded by some mechanism, then >>> Agent_OnUnload_L is supposed to be called. >>> >>> David >>> ----- >>> >>>> ------------- >>>> >>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>> From david.holmes at oracle.com Tue Dec 1 05:59:53 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2020 15:59:53 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> Message-ID: Looking at the original webrev from September: https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExport.cpp.cdiff.html The suggestion to unload the library if Agent_OnAttach fails seems quite reasonable - it is what happens if no Agent_OnAttach function can be found in the agent. But the specification is lacking because it simply states any such error is "ignored" - which is an oversimplification and I think was really intended to contrast with the abort behaviour if Agent_OnLoad fails. In addition the specification indicates that Agent_OnUnload is called any time the agent library is unloaded, except for "uncontrolled shutdown". This unfortunately suggests that before unloading the library after OnAttach fails, we also call OnUnload. That seems wrong and in fact the VM does not do that - and noone seems to have complained. Also note the specification states an agent "must export a start-up function ..." but doesn't say what happens if it doesn't do so. My gut feeling for what the specification should say here is that if the start-up function does not exist, or the call to Agent_OnAttach reports an error, then the agent library is immediately unloaded with no attempt to call the agent shutdown function (Agent_OnUnload). But with my "compatibility glasses" on this may be too strong to retrofit to the specification as other VMs may behave differently. So as I stated in the CSR request we probably want to allow the current hotspot behaviour but not mandate it (unless we check with all the other VM implementations that such a specification is okay with them). I agree that the more general issue of re-loading an agent is a separate issue. David ----- On 1/12/2020 3:21 pm, David Holmes wrote: > On 1/12/2020 3:19 pm, David Holmes wrote: >> On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >>> Hi Chris, David, >>> >>> Currently Agent_OnUnload() is not called when Agent_OnLoad() is >>> failed - JVM will abort. >>> Should we re-think this behavior? >> >> We should we rethink that? It is probably one of the clearest parts of >> the spec. If Agent_Onload fails that is considered a fatal error - end >> of story. > > I meant, of course, "Why should we rethink that?". > > David > >> The issue is with Agent_onAttach and how its failure should, or should >> not, impact Agent_OnUnload. >> >> David >> ----- >> >>> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >>> >>> ``` >>> $ java -agentpath:/path/to/libhelloworld.so=error --version >>> Hello World from Agent_OnLoad() >>> ?? options = error >>> Error occurred during initialization of VM >>> agent library failed to init: /path/to/libhelloworld.so >>> ``` >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/12/01 11:44, David Holmes wrote: >>>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga >>>>> wrote: >>>>> >>>>>>> * Q3: What has to be done for statically linked agent? >>>>>> >>>>>> JVMTI spec says "unless it is statically linked into the >>>>>> executable", so I think we can ignore about Agent_OnUnload_L() in >>>>>> this PR. >>>>> >>>>> I don't think that makes sense. If you call it for dynamically >>>>> linked then you need to call it for statically linked also. >>>> >>>> Agreed. Even though you can't physically unload the statically >>>> linked library, if it is logically unloaded by some mechanism, then >>>> Agent_OnUnload_L is supposed to be called. >>>> >>>> David >>>> ----- >>>> >>>>> ------------- >>>>> >>>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>>> From suenaga at oss.nttdata.com Tue Dec 1 06:41:43 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Tue, 1 Dec 2020 15:41:43 +0900 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> Message-ID: <6515a8b8-0c4a-d06a-af8e-a28a6c31d185@oss.nttdata.com> Hi David, On 2020/12/01 14:59, David Holmes wrote: > Looking at the original webrev from September: > > https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExport.cpp.cdiff.html > > The suggestion to unload the library if Agent_OnAttach fails seems quite reasonable - it is what happens if no Agent_OnAttach function can be found in the agent. > > But the specification is lacking because it simply states any such error is "ignored" - which is an oversimplification and I think was really intended to contrast with the abort behaviour if Agent_OnLoad fails. In addition the specification indicates that Agent_OnUnload is called any time the agent library is unloaded, except for "uncontrolled shutdown". This unfortunately suggests that before unloading the library after OnAttach fails, we also call OnUnload. That seems wrong and in fact the VM does not do that - and noone seems to have complained. > > Also note the specification states an agent "must export a start-up function ..." but doesn't say what happens if it doesn't do so. > > My gut feeling for what the specification should say here is that if the start-up function does not exist, or the call to Agent_OnAttach reports an error, then the agent library is immediately unloaded with no attempt to call the agent shutdown function (Agent_OnUnload). That's what I wanted to suggest! I understand we need to consider following case in this issue, is it right? Agent_OnLoad / Agent_OnLoad_L does not exist: - Agent_OnUnload is not called - DLL is not unloaded (JVM will abort) Agent_OnLoad / Agent_OnLoad_L failed: - Agent_OnUnload is not called - DLL is not unloaded (JVM will abort) Agent_OnAttach does not exist: - Agent_OnUnload is not called - DLL is unloaded Agent_OnAttach_L does not exist: - Agent_OnUnload is not called - DLL is not unloaded (static link) Agent_OnAttach failed: - Agent_OnUnload is not called - DLL is unloaded Agent_OnAttach_L faled: - Agent_OnUnload is not called - DLL is not unloaded (static link) > But with my "compatibility glasses" on this may be too strong to retrofit to the specification as other VMs may behave differently. So as I stated in the CSR request we probably want to allow the current hotspot behaviour but not mandate it (unless we check with all the other VM implementations that such a specification is okay with them). Ok, for example, can we change the spec as following? (Of course, this is not all) ``` diff --git a/src/hotspot/share/prims/jvmti.xml b/src/hotspot/share/prims/jvmti.xml index 44553b8065f..57c87b1a71b 100644 --- a/src/hotspot/share/prims/jvmti.xml +++ b/src/hotspot/share/prims/jvmti.xml @@ -688,7 +688,8 @@ Agent_OnUnload_L(JavaVM *vm) mechanism causes the unload (an unload mechanism is not specified in this document) or the library is (in effect) unloaded by the termination of the VM whether through normal termination or VM failure, including start-up failure. - Uncontrolled shutdown is, of course, an exception to this rule. + Uncontrolled shutdown is, of course, an exception to this rule, and also it might not be called + when start-up function does not exist or fails (returns non-zero value). Note the distinction between this function and the VM Death event: for the VM Death event to be sent, the VM must have run at least to the point of initialization and a valid ``` > I agree that the more general issue of re-loading an agent is a separate issue. Thanks! Yasumasa > David > ----- > > On 1/12/2020 3:21 pm, David Holmes wrote: >> On 1/12/2020 3:19 pm, David Holmes wrote: >>> On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >>>> Hi Chris, David, >>>> >>>> Currently Agent_OnUnload() is not called when Agent_OnLoad() is failed - JVM will abort. >>>> Should we re-think this behavior? >>> >>> We should we rethink that? It is probably one of the clearest parts of the spec. If Agent_Onload fails that is considered a fatal error - end of story. >> >> I meant, of course, "Why should we rethink that?". >> >> David >> >>> The issue is with Agent_onAttach and how its failure should, or should not, impact Agent_OnUnload. >>> >>> David >>> ----- >>> >>>> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >>>> >>>> ``` >>>> $ java -agentpath:/path/to/libhelloworld.so=error --version >>>> Hello World from Agent_OnLoad() >>>> ?? options = error >>>> Error occurred during initialization of VM >>>> agent library failed to init: /path/to/libhelloworld.so >>>> ``` >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/12/01 11:44, David Holmes wrote: >>>>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga wrote: >>>>>> >>>>>>>> * Q3: What has to be done for statically linked agent? >>>>>>> >>>>>>> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. >>>>>> >>>>>> I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. >>>>> >>>>> Agreed. Even though you can't physically unload the statically linked library, if it is logically unloaded by some mechanism, then Agent_OnUnload_L is supposed to be called. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> ------------- >>>>>> >>>>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>>>> From kbarrett at openjdk.java.net Tue Dec 1 10:04:54 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 1 Dec 2020 10:04:54 GMT Subject: RFR: 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" [v2] In-Reply-To: References: <4GRPSMKxwFONrO-YzHXh7z8WxPHJM2tP0Y5X5uWnV10=.03265f2f-a4f7-4ef0-99e3-37701aa6b7fa@github.com> Message-ID: On Tue, 1 Dec 2020 02:22:57 GMT, David Holmes wrote: >> void JvmtiTagMap::flush_object_free_events() { >> assert_not_at_safepoint(); >> if (env()->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { >> >> Called by JVMTI to disable events and called by the service thread. And here for get_objects_with_tags: >> >> if (collector.some_dead_found() && env()->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { >> post_dead_objects_on_vm_thread(); >> } > > That isn't quite what I asked. The claim is that `remove_dead_entries_locked` needs to recheck `is_enabled` if `post_object_free` is true in case the enabled state changed from true to false. But I can't see how such a situation can arise. In `flush_object_free_events` we only call `remove_dead_entries(false)` and that is when events were seen to be disabled. I think you've missed the indirect remove_dead_entries(true) via post_dead_objects_on_vm_thread() in the enabled case, over on the vmthread. And that's exactly the case that shows up in the hs_err file. The assert happens on the vmthread, in the VMOp used by post_dead_entries_xxx: Stack: [0x00007f07456c6000,0x00007f07457c6000], sp=0x00007f07457c48c0, free space=1018k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x11e92fc] JvmtiExport::post_object_free(JvmtiEnv*, long)+0x8c V [libjvm.so+0x12293b2] JvmtiTagMapTable::remove_dead_entries(JvmtiEnv*, bool)+0x192 V [libjvm.so+0x12212cd] VM_JvmtiPostObjectFree::doit()+0x5d V [libjvm.so+0x198469a] VM_Operation::evaluate()+0x18a V [libjvm.so+0x19a7e7f] VMThread::evaluate_operation(VM_Operation*)+0x17f V [libjvm.so+0x19a88cc] VMThread::inner_execute(VM_Operation*)+0x17c V [libjvm.so+0x19a8b85] VMThread::loop()+0xb5 V [libjvm.so+0x19a8cba] VMThread::run()+0xca V [libjvm.so+0x1893db0] Thread::call_run()+0x100 V [libjvm.so+0x1574796] thread_native_entry(Thread*)+0x116 ------------- PR: https://git.openjdk.java.net/jdk/pull/1439 From coleenp at openjdk.java.net Tue Dec 1 12:13:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 12:13:56 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 21:13:05 GMT, Harold Seigel wrote: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold I agree with David. We should remove the helpful messages at least for most of the obsolete Print/Trace flags. Not sure about the big 3 though. src/hotspot/share/runtime/arguments.cpp line 617: > 615: #ifndef PRODUCT > 616: // These options are removed in jdk9. Remove this code for jdk10. > 617: static AliasedFlag const removed_develop_logging_flags[] = { I think this removed_develop_logging_flags infrastructure should be removed. src/hotspot/share/runtime/arguments.cpp line 612: > 610: { "TraceRedefineClasses", "-Xlog:redefine+class=", "info", "16.0" }, > 611: { "PrintJNIResolving", "-Xlog:jni+resolve=", "debug", "16.0" }, > 612: { NULL, NULL, NULL, NULL } I think if we wanted to give a message that the flag was obsolete and to suggest changing the command line, we should only do it for -XX:+TraceClassLoading and -XX:+TraceExceptions (I'd originally thought -XX:+TraceClassUnloading was important enough to release note but now I'm not so sure.) The rest of the flags should either go in the table that they're no longer recognized. src/hotspot/share/runtime/arguments.cpp line 1325: > 1323: *arg == '+' ? obs_replacement->tag_name : "off"); > 1324: return true; > 1325: } I see you left this empty in case we change more flags to logging flags. I don't see any Trace flags left that users would care about that merit this amount of helpfulness. I think this should be removed too. ------------- Changes requested by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From coleenp at openjdk.java.net Tue Dec 1 12:22:55 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 12:22:55 GMT Subject: RFR: 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" [v2] In-Reply-To: References: <4GRPSMKxwFONrO-YzHXh7z8WxPHJM2tP0Y5X5uWnV10=.03265f2f-a4f7-4ef0-99e3-37701aa6b7fa@github.com> Message-ID: On Tue, 1 Dec 2020 10:02:08 GMT, Kim Barrett wrote: >> That isn't quite what I asked. The claim is that `remove_dead_entries_locked` needs to recheck `is_enabled` if `post_object_free` is true in case the enabled state changed from true to false. But I can't see how such a situation can arise. In `flush_object_free_events` we only call `remove_dead_entries(false)` and that is when events were seen to be disabled. > > I think you've missed the indirect remove_dead_entries(true) via > post_dead_objects_on_vm_thread() in the enabled case, over on the vmthread. > And that's exactly the case that shows up in the hs_err file. The assert > happens on the vmthread, in the VMOp used by post_dead_entries_xxx: > > Stack: [0x00007f07456c6000,0x00007f07457c6000], sp=0x00007f07457c48c0, free space=1018k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x11e92fc] JvmtiExport::post_object_free(JvmtiEnv*, long)+0x8c > V [libjvm.so+0x12293b2] JvmtiTagMapTable::remove_dead_entries(JvmtiEnv*, bool)+0x192 > V [libjvm.so+0x12212cd] VM_JvmtiPostObjectFree::doit()+0x5d > V [libjvm.so+0x198469a] VM_Operation::evaluate()+0x18a > V [libjvm.so+0x19a7e7f] VMThread::evaluate_operation(VM_Operation*)+0x17f > V [libjvm.so+0x19a88cc] VMThread::inner_execute(VM_Operation*)+0x17c > V [libjvm.so+0x19a8b85] VMThread::loop()+0xb5 > V [libjvm.so+0x19a8cba] VMThread::run()+0xca > V [libjvm.so+0x1893db0] Thread::call_run()+0x100 > V [libjvm.so+0x1574796] thread_native_entry(Thread*)+0x116 In flush_object_free_events, we read that the event is enabled outside the lock, then we call remove_dead_entries(true). Then remove_dead_entries() gets the table lock and proceeds to walk the table and post the events. Another thread could be disabling the event while this is happening, leading to the assert. So the fix is to make enabling/disabling the event be under the same table lock, and recheck that the event is enabled under that lock in remove_dead_entries_locked. ------------- PR: https://git.openjdk.java.net/jdk/pull/1439 From pliden at openjdk.java.net Tue Dec 1 12:35:57 2020 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 1 Dec 2020 12:35:57 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 20:03:01 GMT, Chris Plummer wrote: >> Just a friendly ping. Still looking for reviewers for this fix. > >> Just a friendly ping. Still looking for reviewers for this fix. > > Until we resolve the discussion in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987), I don't think your suggested fix should be applied since it could be viewed as a workaround to a debug agent issue (not shutting down GC during `VM.suspendAll`) or as something that needs to be clarified in the JDI and JDWP specs (checking for `ObjectReference.disableCollection` failures, even when under `VM.suspendAll`, and retrying the allocation). I'd like to see the discussion resolved and follow-on bugs files. Sorry, I had missed your latest reply in the JDK-8255987. Let's continue the discussion there. ------------- PR: https://git.openjdk.java.net/jdk/pull/1348 From coleenp at openjdk.java.net Tue Dec 1 12:50:02 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 12:50:02 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() Message-ID: The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. ------------- Commit messages: - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to null out deleted entries. - 8257140: Crash in JvmtiTagMap::flush_object_free_events() Changes: https://git.openjdk.java.net/jdk/pull/1539/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1539&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257140 Stats: 25 lines in 5 files changed: 17 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1539/head:pull/1539 PR: https://git.openjdk.java.net/jdk/pull/1539 From coleenp at openjdk.java.net Tue Dec 1 12:50:02 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 12:50:02 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:44:24 GMT, Coleen Phillimore wrote: > The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. > > There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. > > The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. Test passed tier1-3 with no failures. ------------- PR: https://git.openjdk.java.net/jdk/pull/1539 From dholmes at openjdk.java.net Tue Dec 1 13:03:55 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 13:03:55 GMT Subject: RFR: 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" [v2] In-Reply-To: References: <4GRPSMKxwFONrO-YzHXh7z8WxPHJM2tP0Y5X5uWnV10=.03265f2f-a4f7-4ef0-99e3-37701aa6b7fa@github.com> Message-ID: On Tue, 1 Dec 2020 10:02:08 GMT, Kim Barrett wrote: >> That isn't quite what I asked. The claim is that `remove_dead_entries_locked` needs to recheck `is_enabled` if `post_object_free` is true in case the enabled state changed from true to false. But I can't see how such a situation can arise. In `flush_object_free_events` we only call `remove_dead_entries(false)` and that is when events were seen to be disabled. > > I think you've missed the indirect remove_dead_entries(true) via > post_dead_objects_on_vm_thread() in the enabled case, over on the vmthread. > And that's exactly the case that shows up in the hs_err file. The assert > happens on the vmthread, in the VMOp used by post_dead_entries_xxx: > > Stack: [0x00007f07456c6000,0x00007f07457c6000], sp=0x00007f07457c48c0, free space=1018k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x11e92fc] JvmtiExport::post_object_free(JvmtiEnv*, long)+0x8c > V [libjvm.so+0x12293b2] JvmtiTagMapTable::remove_dead_entries(JvmtiEnv*, bool)+0x192 > V [libjvm.so+0x12212cd] VM_JvmtiPostObjectFree::doit()+0x5d > V [libjvm.so+0x198469a] VM_Operation::evaluate()+0x18a > V [libjvm.so+0x19a7e7f] VMThread::evaluate_operation(VM_Operation*)+0x17f > V [libjvm.so+0x19a88cc] VMThread::inner_execute(VM_Operation*)+0x17c > V [libjvm.so+0x19a8b85] VMThread::loop()+0xb5 > V [libjvm.so+0x19a8cba] VMThread::run()+0xca > V [libjvm.so+0x1893db0] Thread::call_run()+0x100 > V [libjvm.so+0x1574796] thread_native_entry(Thread*)+0x116 Thanks @kimbarrett and @coleenp I missed the path at the safepoint that leads to the call without the lock. ------------- PR: https://git.openjdk.java.net/jdk/pull/1439 From coleenp at openjdk.java.net Tue Dec 1 13:10:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 13:10:58 GMT Subject: RFR: 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" [v2] In-Reply-To: References: <5Ed2eVORB8pJ0BmKISasvgLZCT4HIjJt-YA4sjZZW0k=.96a9d20c-f931-493a-83c2-2444e2646896@github.com> Message-ID: <7VprB_RQAWmwT0gQdcU9uWZLdsfcL-GD8_KJZDqn7Ak=.525eb4ba-d00e-4aeb-8ada-403722721b2a@github.com> On Tue, 1 Dec 2020 13:04:56 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Make enable events lock unconditionally if tagmap present. > > Thanks Coleen. > > I think the locking strategy around this code leaves something to be desired but I see the problem more clearly now and how the fix addresses it. > > David Thanks for reviewing this David, Kim and Serguei. ------------- PR: https://git.openjdk.java.net/jdk/pull/1439 From dholmes at openjdk.java.net Tue Dec 1 13:10:57 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 13:10:57 GMT Subject: RFR: 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" [v2] In-Reply-To: <5Ed2eVORB8pJ0BmKISasvgLZCT4HIjJt-YA4sjZZW0k=.96a9d20c-f931-493a-83c2-2444e2646896@github.com> References: <5Ed2eVORB8pJ0BmKISasvgLZCT4HIjJt-YA4sjZZW0k=.96a9d20c-f931-493a-83c2-2444e2646896@github.com> Message-ID: On Mon, 30 Nov 2020 13:57:14 GMT, Coleen Phillimore wrote: >> The ServiceThread cleaning used a stale ObjectFree state when calling remove_dead_entries, because another thread had concurrently set is_enabled to false. Add a lock around setting/resetting the lock event state and retest the state under a lock. Ran the test 100s of time without failure, where otherwise it fails very quickly. >> Tested with tier2,3 and running tiers 4,5,6 in progress. >> Thanks to Kim for his previous feedback. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Make enable events lock unconditionally if tagmap present. Thanks Coleen. I think the locking strategy around this code leaves something to be desired but I see the problem more clearly now and how the fix addresses it. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1439 From coleenp at openjdk.java.net Tue Dec 1 13:10:59 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 13:10:59 GMT Subject: Integrated: 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" In-Reply-To: References: Message-ID: <2ALyaFO4a_bzkRjeF24LK0oMzvGNer7zproEkg0sEqU=.a433355a-2a32-43f8-9347-21f992e7328b@github.com> On Wed, 25 Nov 2020 18:40:49 GMT, Coleen Phillimore wrote: > The ServiceThread cleaning used a stale ObjectFree state when calling remove_dead_entries, because another thread had concurrently set is_enabled to false. Add a lock around setting/resetting the lock event state and retest the state under a lock. Ran the test 100s of time without failure, where otherwise it fails very quickly. > Tested with tier2,3 and running tiers 4,5,6 in progress. > Thanks to Kim for his previous feedback. This pull request has now been integrated. Changeset: 3a11009d Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/3a11009d Stats: 20 lines in 3 files changed: 17 ins; 1 del; 2 mod 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" Reviewed-by: kbarrett, sspitsyn, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1439 From coleenp at openjdk.java.net Tue Dec 1 14:08:00 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 14:08:00 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 Message-ID: Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: `$ java -XX:+UseNewCode -version [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). There is insufficient memory for the Java Runtime Environment to continue. Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages An error report file with more information is saved as: /16mprotect/hs_err_pid30596.log` ` ------------- Commit messages: - Made resexhaused001.004 manual tests. You can't reliably run these tests. - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 Changes: https://git.openjdk.java.net/jdk/pull/1540/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1540&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253916 Stats: 15 lines in 6 files changed: 5 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1540.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1540/head:pull/1540 PR: https://git.openjdk.java.net/jdk/pull/1540 From shade at openjdk.java.net Tue Dec 1 14:08:00 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 14:08:00 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:55:05 GMT, Coleen Phillimore wrote: > Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: > > `$ java -XX:+UseNewCode -version > [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). > > There is insufficient memory for the Java Runtime Environment to continue. > Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages > An error report file with more information is saved as: > /16mprotect/hs_err_pid30596.log` > ` You need to merge from master to get GH Actions fixes. They are currently failing with outdated dependencies in your branch, and master has a fix for that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Tue Dec 1 14:16:14 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 14:16:14 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: > Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: > > `$ java -XX:+UseNewCode -version > [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). > > There is insufficient memory for the Java Runtime Environment to continue. > Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages > An error report file with more information is saved as: > /16mprotect/hs_err_pid30596.log` > ` Coleen Phillimore 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 commits since the last revision: - Merge branch 'master' into mprotect - Made resexhaused001.004 manual tests. You can't reliably run these tests. - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1540/files - new: https://git.openjdk.java.net/jdk/pull/1540/files/5751660c..d34286f9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1540&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1540&range=00-01 Stats: 24816 lines in 603 files changed: 13248 ins; 3971 del; 7597 mod Patch: https://git.openjdk.java.net/jdk/pull/1540.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1540/head:pull/1540 PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Tue Dec 1 14:16:14 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 14:16:14 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 13:53:08 GMT, Aleksey Shipilev wrote: >> Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: >> >> `$ java -XX:+UseNewCode -version >> [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). >> >> There is insufficient memory for the Java Runtime Environment to continue. >> Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages >> An error report file with more information is saved as: >> /16mprotect/hs_err_pid30596.log` >> ` > > You need to merge from master to get GH Actions fixes. They are currently failing with outdated dependencies in your branch, and master has a fix for that. Thanks Aleksey, I've remerged, we'll see if that helps. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Tue Dec 1 14:19:15 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 14:19:15 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() [v2] In-Reply-To: References: Message-ID: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> > The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. > > There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. > > The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. Coleen Phillimore 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 commits since the last revision: - Merge branch 'master' into more-jvmti-table - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to null out deleted entries. - 8257140: Crash in JvmtiTagMap::flush_object_free_events() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1539/files - new: https://git.openjdk.java.net/jdk/pull/1539/files/9aaa0c88..a035ec89 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1539&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1539&range=00-01 Stats: 24816 lines in 603 files changed: 13248 ins; 3971 del; 7597 mod Patch: https://git.openjdk.java.net/jdk/pull/1539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1539/head:pull/1539 PR: https://git.openjdk.java.net/jdk/pull/1539 From dcubed at openjdk.java.net Tue Dec 1 15:58:54 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 1 Dec 2020 15:58:54 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:47:04 GMT, Coleen Phillimore wrote: > Test passed tier1-3 with no failures. Tier5 and Tier6 have more JPDA testing (JVM/TI, JDWP, JDI, ...) ------------- PR: https://git.openjdk.java.net/jdk/pull/1539 From stuefe at openjdk.java.net Tue Dec 1 16:55:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 16:55:00 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 14:12:58 GMT, Coleen Phillimore wrote: >> You need to merge from master to get GH Actions fixes. They are currently failing with outdated dependencies in your branch, and master has a fix for that. > > Thanks Aleksey, I've remerged, we'll see if that helps. Hi Coleen, I believe this is intermittent and can be temporary (most likely number of process local mappings, see my comment in JBS). Therefore ideally, this should result in an OOM, not a VM exit - at least when it happens during thread creation, which is the most likely scenario. I believe this can happen when the number of mappings exceeds the allowed process limit. One simple maybe stupid approach could be to pre-reserve mappings, and release them in this situation to decrease the process local mapping counter. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From stuefe at openjdk.java.net Tue Dec 1 20:19:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 20:19:00 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 14:16:14 GMT, Coleen Phillimore wrote: >> Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: >> >> `$ java -XX:+UseNewCode -version >> [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). >> >> There is insufficient memory for the Java Runtime Environment to continue. >> Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages >> An error report file with more information is saved as: >> /16mprotect/hs_err_pid30596.log` >> ` > > Coleen Phillimore 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 commits since the last revision: > > - Merge branch 'master' into mprotect > - Made resexhaused001.004 manual tests. You can't reliably run these tests. > - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 After reading through the JBS comments I think this makes sense as an intermediate solution, since - as it was pointed out - running on without stack guards could cause crashes on later. The situation is not ideal but this change does not change much. As far as native memory shortages go, whether or not they result in an OOM is random anyway. pthread_create may fail, which would result in an OOM, or it may cause any number of other APIs to fail, e.g. mmap, which would cause the VM to terminate. The hotspot changes look good. I cannot comment on the changed test attributes. src/hotspot/share/runtime/stackOverflow.cpp line 109: > 107: } > 108: > 109: log_debug(os, thread)("Thread " UINTX_FORMAT " stack guard pages activated: " I always was curious about this uncommit. I wondered whether it was a fallback for platforms where mprotect would not work on thread stacks. But then, why warn unconditionally? ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1540 From amenkov at openjdk.java.net Tue Dec 1 21:05:12 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 1 Dec 2020 21:05:12 GMT Subject: RFR: 8256808: com/sun/jdi/CatchAllTest.java failed with "NullPointerException: Cannot invoke "lib.jdb.Jdb.log(String)" because "this.jdb" is null" [v2] In-Reply-To: References: Message-ID: > JdbTest can get exception before jdb field is initialized. > As Jdb logging does not depend on the instance, made Jdb.log method static Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Updated accordingly feedback - made Jdb.log instance private method (I'd prefer to keep the method as a single point to logging); - updated JdbTest to use System.out.println directly. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1443/files - new: https://git.openjdk.java.net/jdk/pull/1443/files/cf63a02e..d271cecc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1443&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1443&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1443.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1443/head:pull/1443 PR: https://git.openjdk.java.net/jdk/pull/1443 From cjplummer at openjdk.java.net Tue Dec 1 21:15:58 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Dec 2020 21:15:58 GMT Subject: RFR: 8256808: com/sun/jdi/CatchAllTest.java failed with "NullPointerException: Cannot invoke "lib.jdb.Jdb.log(String)" because "this.jdb" is null" [v2] In-Reply-To: References: Message-ID: <_cDv3KHx_k_0aCyCEkXtS_xFpzI_5e_T-i8xISHhBX0=.1e7fdbc6-7c1c-4d6e-bda7-9a894efc4c48@github.com> On Tue, 1 Dec 2020 21:05:12 GMT, Alex Menkov wrote: >> JdbTest can get exception before jdb field is initialized. >> As Jdb logging does not depend on the instance, made Jdb.log method static > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Updated accordingly feedback > > - made Jdb.log instance private method (I'd prefer to keep the method as a single point to logging); > - updated JdbTest to use System.out.println directly. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1443 From hseigel at openjdk.java.net Tue Dec 1 21:44:09 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 1 Dec 2020 21:44:09 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8256718: Obsolete the long term deprecated and aliased Trace flags ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1525/files - new: https://git.openjdk.java.net/jdk/pull/1525/files/9c373c6b..84e421f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1525&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1525&range=00-01 Stats: 206 lines in 3 files changed: 13 ins; 192 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1525/head:pull/1525 PR: https://git.openjdk.java.net/jdk/pull/1525 From hseigel at openjdk.java.net Tue Dec 1 21:48:57 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 1 Dec 2020 21:48:57 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:10:59 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > I agree with David. We should remove the helpful messages at least for most of the obsolete Print/Trace flags. Not sure about the big 3 though. Thanks everyone for the reviews. Please review the updated commit which contains the following changes: 1. Moves most of the flags to the normal location for obsolete flags. 2. Keeps the extra -Xlog message for the three most commonly used flags. 3. Removes the removed_develop_logging_flags struct and support functions. 4. Removes the aliased_logging_flags struct and support functions based on Coleen's statement that there are no existing flags that would use it. Thanks! Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From coleenp at openjdk.java.net Tue Dec 1 22:04:00 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 22:04:00 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 20:12:28 GMT, Thomas Stuefe wrote: >> Coleen Phillimore 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 commits since the last revision: >> >> - Merge branch 'master' into mprotect >> - Made resexhaused001.004 manual tests. You can't reliably run these tests. >> - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 > > src/hotspot/share/runtime/stackOverflow.cpp line 109: > >> 107: } >> 108: >> 109: log_debug(os, thread)("Thread " UINTX_FORMAT " stack guard pages activated: " > > I always was curious about this uncommit. I wondered whether it was a fallback for platforms where mprotect would not work on thread stacks. But then, why warn unconditionally? Maybe the uncommit was an attempt to achieve the same thing as protecting the pages, ie get a SEGV when accessing them. I don't know either. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Tue Dec 1 22:11:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 22:11:01 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 15:55:41 GMT, Daniel D. Daugherty wrote: >> Test passed tier1-3 with no failures. > >> Test passed tier1-3 with no failures. > > Tier5 and Tier6 have more JPDA testing (JVM/TI, JDWP, JDI, ...) tier 4,5,6 pass with no failures. ------------- PR: https://git.openjdk.java.net/jdk/pull/1539 From coleenp at openjdk.java.net Tue Dec 1 22:11:05 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 22:11:05 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 20:16:05 GMT, Thomas Stuefe wrote: >> Coleen Phillimore 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 commits since the last revision: >> >> - Merge branch 'master' into mprotect >> - Made resexhaused001.004 manual tests. You can't reliably run these tests. >> - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 > > After reading through the JBS comments I think this makes sense as an intermediate solution, since - as it was pointed out - running on without stack guards could cause crashes on later. The situation is not ideal but this change does not change much. > > As far as native memory shortages go, whether or not they result in an OOM is random anyway. pthread_create may fail, which would result in an OOM, or it may cause any number of other APIs to fail, e.g. mmap, which would cause the VM to terminate. > > The hotspot changes look good. I cannot comment on the changed test attributes. Thanks for reviewing this Thomas, and for more information about this failure. I answered your comments in the JBS issue. It might be possible to throw OOM instead of vm_exit_out_of_memory but it's not very clean where it'll propagate in the code, and for this low native memory situation, I don't think it's going to help the test make more progress. This has been a longstanding problem with this test so this change makes a cleaner exit for an unlikely application which may also have the same problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From iklam at openjdk.java.net Tue Dec 1 22:31:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 22:31:56 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:44:09 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Tue Dec 1 23:05:01 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 23:05:01 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:04:43 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > src/hotspot/share/runtime/arguments.cpp line 612: > >> 610: { "TraceRedefineClasses", "-Xlog:redefine+class=", "info", "16.0" }, >> 611: { "PrintJNIResolving", "-Xlog:jni+resolve=", "debug", "16.0" }, >> 612: { NULL, NULL, NULL, NULL } > > I think if we wanted to give a message that the flag was obsolete and to suggest changing the command line, we should only do it for -XX:+TraceClassLoading and -XX:+TraceExceptions (I'd originally thought -XX:+TraceClassUnloading was important enough to release note but now I'm not so sure.) The rest of the flags should either go in the table that they're no longer recognized. Keeping the message for any flag requires keeping all the supporting code. I don't see the "big 3" are special. They have been deprecated since 9 and we have clearly told people this when they use them. We're also release-noting this for 16 (again - this was documented when UL was added). I don't think we have to pander to anyone who hasn't updated their launch scripts by now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From sspitsyn at openjdk.java.net Wed Dec 2 00:12:58 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Dec 2020 00:12:58 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() [v2] In-Reply-To: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> References: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> Message-ID: On Tue, 1 Dec 2020 14:19:15 GMT, Coleen Phillimore wrote: >> The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. >> >> There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. >> >> The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. > > Coleen Phillimore 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 commits since the last revision: > > - Merge branch 'master' into more-jvmti-table > - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to null out deleted entries. > - 8257140: Crash in JvmtiTagMap::flush_object_free_events() Hi Coleen, The JVMTI environment can be disposed with DisposeEnvironment: https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#DisposeEnvironment It seems to me that this operation is better to wait until posting is finished. Otherwise, the information is going to be lost in the report. Of course, we could blame the agent to call the DisposeEnvironment too early but then the agent needs a way to check if posting is finished. Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/1539 From sspitsyn at openjdk.java.net Wed Dec 2 00:45:03 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Dec 2020 00:45:03 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: <5r8K8_KQj2e17tkOarKyGAbCQmSgg9BK-jE-jiIQwEs=.d6dc4014-263e-4fee-9c28-86bf47bc554f@github.com> On Tue, 1 Dec 2020 14:16:14 GMT, Coleen Phillimore wrote: >> Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: >> >> `$ java -XX:+UseNewCode -version >> [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). >> >> There is insufficient memory for the Java Runtime Environment to continue. >> Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages >> An error report file with more information is saved as: >> /16mprotect/hs_err_pid30596.log` >> ` > > Coleen Phillimore 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 commits since the last revision: > > - Merge branch 'master' into mprotect > - Made resexhaused001.004 manual tests. You can't reliably run these tests. > - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 Hi Coleen, The fix looks good to me. I'm not sure how adding the jtreg 'manual' key to the tests is helping though. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1540 From sspitsyn at openjdk.java.net Wed Dec 2 01:12:59 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Dec 2020 01:12:59 GMT Subject: RFR: 8256808: com/sun/jdi/CatchAllTest.java failed with "NullPointerException: Cannot invoke "lib.jdb.Jdb.log(String)" because "this.jdb" is null" [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:05:12 GMT, Alex Menkov wrote: >> JdbTest can get exception before jdb field is initialized. >> As Jdb logging does not depend on the instance, made Jdb.log method static > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Updated accordingly feedback > > - made Jdb.log instance private method (I'd prefer to keep the method as a single point to logging); > - updated JdbTest to use System.out.println directly. Looks good ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1443 From dholmes at openjdk.java.net Wed Dec 2 02:04:05 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 02:04:05 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 14:16:14 GMT, Coleen Phillimore wrote: >> Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: >> >> `$ java -XX:+UseNewCode -version >> [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). >> >> There is insufficient memory for the Java Runtime Environment to continue. >> Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages >> An error report file with more information is saved as: >> /16mprotect/hs_err_pid30596.log` >> ` > > Coleen Phillimore 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 commits since the last revision: > > - Merge branch 'master' into mprotect > - Made resexhaused001.004 manual tests. You can't reliably run these tests. > - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 I'm okay with the functional change here, to do vm_exit_oom when guard page creation fails. I'm not sure about the test change. It was only problem-listed on Linux but now is "manual" on all platforms and so will now be excluded from automated testing on all platforms. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Wed Dec 2 02:13:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 02:13:56 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 23:01:51 GMT, David Holmes wrote: >> src/hotspot/share/runtime/arguments.cpp line 612: >> >>> 610: { "TraceRedefineClasses", "-Xlog:redefine+class=", "info", "16.0" }, >>> 611: { "PrintJNIResolving", "-Xlog:jni+resolve=", "debug", "16.0" }, >>> 612: { NULL, NULL, NULL, NULL } >> >> I think if we wanted to give a message that the flag was obsolete and to suggest changing the command line, we should only do it for -XX:+TraceClassLoading and -XX:+TraceExceptions (I'd originally thought -XX:+TraceClassUnloading was important enough to release note but now I'm not so sure.) The rest of the flags should either go in the table that they're no longer recognized. > > Keeping the message for any flag requires keeping all the supporting code. I don't see the "big 3" are special. They have been deprecated since 9 and we have clearly told people this when they use them. We're also release-noting this for 16 (again - this was documented when UL was added). I don't think we have to pander to anyone who hasn't updated their launch scripts by now. For these three, I kind of like the pandering. I'm not sure that the release note will reach people using these, especially -XX:+TraceExceptions. I guess they've been getting a deprecation message since 9 so maybe it won't be such a surprise. I never stand in the way of removing code that people won't need, if you think this is the case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From coleen.phillimore at oracle.com Wed Dec 2 02:16:46 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 1 Dec 2020 21:16:46 -0500 Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: <88a57523-9cea-36a3-a71c-3930389de982@oracle.com> including serviceability-dev. On 12/1/20 9:08 PM, Coleen Phillimore wrote: > > > On 12/1/20 9:04 PM, David Holmes wrote: >> On Tue, 1 Dec 2020 14:16:14 GMT, Coleen Phillimore >> wrote: >> >>>> Give an error message rather than logging the error and then >>>> crashing later because the JVM can't detect stack overflow.? In a >>>> resource exhausted situation, thread creation is also failing.? >>>> This is the vm_exit_out_of_memory message printed: >>>> >>>> `$ java -XX:+UseNewCode -version >>>> [0.003s][warning][os,thread] Attempt to protect stack guard pages >>>> failed (0x00007f606b249000-0x00007f606b24d000). >>>> >>>> ? There is insufficient memory for the Java Runtime Environment to >>>> continue. >>>> ? Native memory allocation (mprotect) failed to protect 16384 bytes >>>> for memory to guard stack pages >>>> ? An error report file with more information is saved as: >>>> ? /16mprotect/hs_err_pid30596.log` >>>> ` >>> Coleen Phillimore 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 commits since the last revision: >>> >>> ? - Merge branch 'master' into mprotect >>> ? - Made resexhaused001.004 manual tests.? You can't reliably run >>> these tests. >>> ? - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 >> I'm okay with the functional change here, to do vm_exit_oom when >> guard page creation fails. >> >> I'm not sure about the test change. It was only problem-listed on >> Linux but now is "manual" on all platforms and so will now be >> excluded from automated testing on all platforms. > > I didn't think these tests would be reliable anywhere, but maybe they > were on Windows.? What do you suggest? > Thanks for reviewing, > Coleen >> >> ------------- >> >> Marked as reviewed by dholmes (Reviewer). >> >> PR: https://git.openjdk.java.net/jdk/pull/1540 > From coleen.phillimore at oracle.com Wed Dec 2 02:17:07 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 1 Dec 2020 21:17:07 -0500 Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() [v2] In-Reply-To: <6e6287be-e9d0-2133-fd5b-f82de032154e@oracle.com> References: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> <6e6287be-e9d0-2133-fd5b-f82de032154e@oracle.com> Message-ID: <0b694c6b-cba6-1a41-05a8-c4449f63ebec@oracle.com> Including serviceability-dev. On 12/1/20 9:03 PM, Coleen Phillimore wrote: > > > On 12/1/20 7:12 PM, Serguei Spitsyn wrote: >> On Tue, 1 Dec 2020 14:19:15 GMT, Coleen Phillimore >> wrote: >> >>>> The JvmtiTagMap can be deleted while it is posting.? The JvmtiEnv >>>> is still on the list but the env is "disposed" of and the tag_map >>>> is deleted to save memory until the JvmtiEnv can be reclaimed at a >>>> safepoint and taken off the list. >>>> >>>> There's a check JvmtiEnvBase::check_for_periodic_clean_up() that >>>> determines whether the JvmtiEnv can be taken off the list and that >>>> check looks for whether threads are in the middle of >>>> JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count.? So >>>> this part is safe for the JvmtiTagMap changes. >>>> >>>> The fix is to clear the JvmtiTagMapTable of the entries inside the >>>> table lock to save memory but leave JvmtiTagMap intact so that we >>>> can load a valid pointer when iterating through JvmtiEnvIterator.? >>>> We could also not do this at all and let the JvmtiTagMap destructor >>>> delete the table when the JvmtiEnv is also deleted, but we don't >>>> know what customer situation led to this code in the first place. >>> Coleen Phillimore 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 commits since the last revision: >>> >>> ? - Merge branch 'master' into more-jvmti-table >>> ? - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to >>> null out deleted entries. >>> ? - 8257140: Crash in JvmtiTagMap::flush_object_free_events() >> Hi Coleen, >> >> The JVMTI environment can be disposed with DisposeEnvironment: >> https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#DisposeEnvironment >> It seems to me that this operation is better to wait until posting is >> finished. Otherwise, the information is going to be lost in the >> report. Of course, we could blame the agent to call the >> DisposeEnvironment too early but then the agent needs a way to check >> if posting is finished. > > When the event is disposed, it calls set_event_callbacks(), which > calls flush_object_free_events, which will flush the remaining object > free events for this environment.? So the events aren't lost.? The bug > was that after that, the JvmtiEnv is marked as DISPOSED but it's still > on the list of JvmtiEnvIterator events that we walk until the next > safepoint.? When the JvmtiEnv is disposed, it was deleting the tag_map > but leaving it on the list, so later calls to flush_object_free_events > was getting a bad tag_map pointer in the JvmtiEnv. > > Coleen > >> >> Thanks, >> Serguei >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/1539 > From coleenp at openjdk.java.net Wed Dec 2 02:17:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 02:17:01 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:44:09 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags I approve if you remove or leave the big 3 as aliases. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Wed Dec 2 02:44:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 02:44:58 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 02:11:35 GMT, Coleen Phillimore wrote: >> Keeping the message for any flag requires keeping all the supporting code. I don't see the "big 3" are special. They have been deprecated since 9 and we have clearly told people this when they use them. We're also release-noting this for 16 (again - this was documented when UL was added). I don't think we have to pander to anyone who hasn't updated their launch scripts by now. > > For these three, I kind of like the pandering. I'm not sure that the release note will reach people using these, especially -XX:+TraceExceptions. I guess they've been getting a deprecation message since 9 so maybe it won't be such a surprise. I never stand in the way of removing code that people won't need, if you think this is the case. I think we should remove them. There is a risk that the user might not notice the difference between the old and new messages and so not realize they don't actually have active logging any more (until they go to access the logs to diagnose a problem). ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Wed Dec 2 02:44:57 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 02:44:57 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:44:09 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags I'm still pushing for treating all flags the same and removing all the aliased-flag code. Coleen seems to be okay either way. :) Thanks, David ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From coleenp at openjdk.java.net Wed Dec 2 02:45:03 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 02:45:03 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: <4FfesCoTJvLcNiOv5zExVnGe7BM3O3NmuoxNwG10NTc=.73f23f82-b9a1-433a-a30b-00d2da70d70f@github.com> On Wed, 2 Dec 2020 02:01:41 GMT, David Holmes wrote: >> Coleen Phillimore 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 commits since the last revision: >> >> - Merge branch 'master' into mprotect >> - Made resexhaused001.004 manual tests. You can't reliably run these tests. >> - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 > > I'm okay with the functional change here, to do vm_exit_oom when guard page creation fails. > > I'm not sure about the test change. It was only problem-listed on Linux but now is "manual" on all platforms and so will now be excluded from automated testing on all platforms. // Check platform here (instead of @requires) as this test is also called from resexhausted004 if (Platform.isWindows()) { throw new SkippedException("Cannot get JVMTI_RESOURCE_EXHAUSTED_THREADS on Windows"); } The test is programmatically excluded on windows. There's also bug https://bugs.openjdk.java.net/browse/JDK-8244640 which shows that the uncommit_memory() sort of works on windows, but then stack overflow handling is then incorrect. This test, and test resexhausted004 are useful for testing JVMTI_RESOURCE_EXHAUSTED_THREADS, but not as part of our test system since it fails periodically for at least the last 10 years. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From sspitsyn at openjdk.java.net Wed Dec 2 04:03:59 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Dec 2020 04:03:59 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() [v2] In-Reply-To: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> References: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> Message-ID: <-PmF4wus3tQrE5laLSdXgiMZQWkOjb5-ORcRhuX9KvY=.444b2e07-c521-4c27-8e70-311147fcec84@github.com> On Tue, 1 Dec 2020 14:19:15 GMT, Coleen Phillimore wrote: >> The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. >> >> There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. >> >> The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. > > Coleen Phillimore 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 commits since the last revision: > > - Merge branch 'master' into more-jvmti-table > - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to null out deleted entries. > - 8257140: Crash in JvmtiTagMap::flush_object_free_events() This is reasonable. Thank you for the explanation! The fix looks good to me. > When the event is disposed, it calls set_event_callbacks()... You, probably meant "environment" is disposed, not "event". This correction is for other readers. :) ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1539 From lmesnik at openjdk.java.net Wed Dec 2 04:21:01 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Dec 2020 04:21:01 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: <___yf1Gd5MQWugSq_RZRaoHMB2ufD0ZYuvXyhn782q0=.20e07ef4-4a4a-4f4f-89ba-bd2a5bdb397c@github.com> On Tue, 1 Dec 2020 14:16:14 GMT, Coleen Phillimore wrote: >> Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: >> >> `$ java -XX:+UseNewCode -version >> [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). >> >> There is insufficient memory for the Java Runtime Environment to continue. >> Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages >> An error report file with more information is saved as: >> /16mprotect/hs_err_pid30596.log` >> ` > > Coleen Phillimore 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 commits since the last revision: > > - Merge branch 'master' into mprotect > - Made resexhaused001.004 manual tests. You can't reliably run these tests. > - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001/TestDescription.java line 41: > 39: * @library /vmTestbase > 40: * /test/lib > 41: * @run main/othervm/native/manual/timeout=240 What is the reason to make this test manual? ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From lmesnik at openjdk.java.net Wed Dec 2 04:52:01 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Dec 2020 04:52:01 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: <___yf1Gd5MQWugSq_RZRaoHMB2ufD0ZYuvXyhn782q0=.20e07ef4-4a4a-4f4f-89ba-bd2a5bdb397c@github.com> Message-ID: On Wed, 2 Dec 2020 04:48:08 GMT, Coleen Phillimore wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001/TestDescription.java line 41: >> >>> 39: * @library /vmTestbase >>> 40: * /test/lib >>> 41: * @run main/othervm/native/manual/timeout=240 >> >> What is the reason to make this test manual? > > These tests are unreliable. Sorry, I've missed the answer to the same question. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Wed Dec 2 04:52:00 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 04:52:00 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: <___yf1Gd5MQWugSq_RZRaoHMB2ufD0ZYuvXyhn782q0=.20e07ef4-4a4a-4f4f-89ba-bd2a5bdb397c@github.com> References: <___yf1Gd5MQWugSq_RZRaoHMB2ufD0ZYuvXyhn782q0=.20e07ef4-4a4a-4f4f-89ba-bd2a5bdb397c@github.com> Message-ID: On Wed, 2 Dec 2020 04:16:11 GMT, Leonid Mesnik wrote: >> Coleen Phillimore 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 commits since the last revision: >> >> - Merge branch 'master' into mprotect >> - Made resexhaused001.004 manual tests. You can't reliably run these tests. >> - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001/TestDescription.java line 41: > >> 39: * @library /vmTestbase >> 40: * /test/lib >> 41: * @run main/othervm/native/manual/timeout=240 > > What is the reason to make this test manual? These tests are unreliable. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Wed Dec 2 13:44:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 13:44:57 GMT Subject: Integrated: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:55:05 GMT, Coleen Phillimore wrote: > Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: > > `$ java -XX:+UseNewCode -version > [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). > > There is insufficient memory for the Java Runtime Environment to continue. > Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages > An error report file with more information is saved as: > /16mprotect/hs_err_pid30596.log` > ` This pull request has now been integrated. Changeset: cfb50a9c Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/cfb50a9c Stats: 15 lines in 6 files changed: 5 ins; 5 del; 5 mod 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 Reviewed-by: stuefe, sspitsyn, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Wed Dec 2 13:44:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 13:44:56 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: <___yf1Gd5MQWugSq_RZRaoHMB2ufD0ZYuvXyhn782q0=.20e07ef4-4a4a-4f4f-89ba-bd2a5bdb397c@github.com> Message-ID: On Wed, 2 Dec 2020 04:49:12 GMT, Leonid Mesnik wrote: >> These tests are unreliable and this change will simply give a better error message when they fail. > > Sorry, I've missed the answer to the same question. Thanks Leonid, I didn't really have a better thing to do with these tests because git made me take them off the problem list where they've been on and off for years. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Wed Dec 2 14:13:02 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 14:13:02 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() [v2] In-Reply-To: References: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> Message-ID: On Wed, 2 Dec 2020 14:07:31 GMT, Kim Barrett wrote: >> Coleen Phillimore 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 commits since the last revision: >> >> - Merge branch 'master' into more-jvmti-table >> - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to null out deleted entries. >> - 8257140: Crash in JvmtiTagMap::flush_object_free_events() > > Marked as reviewed by kbarrett (Reviewer). Thanks Serguei and Kim for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/1539 From kbarrett at openjdk.java.net Wed Dec 2 14:12:59 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 2 Dec 2020 14:12:59 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() [v2] In-Reply-To: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> References: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> Message-ID: On Tue, 1 Dec 2020 14:19:15 GMT, Coleen Phillimore wrote: >> The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. >> >> There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. >> >> The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. > > Coleen Phillimore 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 commits since the last revision: > > - Merge branch 'master' into more-jvmti-table > - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to null out deleted entries. > - 8257140: Crash in JvmtiTagMap::flush_object_free_events() Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1539 From coleenp at openjdk.java.net Wed Dec 2 14:13:03 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 14:13:03 GMT Subject: Integrated: 8257140: Crash in JvmtiTagMap::flush_object_free_events() In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:44:24 GMT, Coleen Phillimore wrote: > The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. > > There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. > > The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. This pull request has now been integrated. Changeset: 2508bc7c Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/2508bc7c Stats: 25 lines in 5 files changed: 17 ins; 0 del; 8 mod 8257140: Crash in JvmtiTagMap::flush_object_free_events() Reviewed-by: sspitsyn, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/1539 From hseigel at openjdk.java.net Wed Dec 2 18:44:08 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 2 Dec 2020 18:44:08 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8256718: Obsolete the long term deprecated and aliased Trace flags ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1525/files - new: https://git.openjdk.java.net/jdk/pull/1525/files/84e421f7..2c5bec9a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1525&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1525&range=01-02 Stats: 40 lines in 2 files changed: 3 ins; 36 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1525/head:pull/1525 PR: https://git.openjdk.java.net/jdk/pull/1525 From hseigel at openjdk.java.net Wed Dec 2 18:54:03 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 2 Dec 2020 18:54:03 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:02:57 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > src/hotspot/share/runtime/arguments.cpp line 617: > >> 615: #ifndef PRODUCT >> 616: // These options are removed in jdk9. Remove this code for jdk10. >> 617: static AliasedFlag const removed_develop_logging_flags[] = { > > I think this removed_develop_logging_flags infrastructure should be removed. done. ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From hseigel at openjdk.java.net Wed Dec 2 18:53:59 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 2 Dec 2020 18:53:59 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: <4H1k-dufXhXpZM-wIl6YTa4b8_6SGcOWOC6QG4LXXf0=.f54a8f80-b42a-4392-8c8e-88bd2b2c308e@github.com> On Wed, 2 Dec 2020 02:42:18 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > I'm still pushing for treating all flags the same and removing all the aliased-flag code. > > Coleen seems to be okay either way. :) > > Thanks, > David Please review this latest webrev. It removes all the aliasing code for the obsolete tracing flags and does not suggest logging alternatives in their obsolete flag messages. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From lmesnik at openjdk.java.net Wed Dec 2 19:19:05 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Dec 2020 19:19:05 GMT Subject: RFR: 8257623: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001/TestDescription.java shouldn't use timeout Message-ID: The test is manual and shouldn't use the timeout ------------- Commit messages: - 8257623: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001/TestDescription.java shoudln't use timeout Changes: https://git.openjdk.java.net/jdk/pull/1573/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1573&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257623 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1573.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1573/head:pull/1573 PR: https://git.openjdk.java.net/jdk/pull/1573 From sspitsyn at openjdk.java.net Wed Dec 2 19:25:57 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Dec 2020 19:25:57 GMT Subject: RFR: 8257623: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001/TestDescription.java shouldn't use timeout In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 19:13:50 GMT, Leonid Mesnik wrote: > The test is manual and shouldn't use the timeout Hi Leonid, It looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1573 From sspitsyn at openjdk.java.net Wed Dec 2 19:30:57 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Dec 2020 19:30:57 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 18:44:08 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags The update looks good to me. It is a nice simplification. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From dcubed at openjdk.java.net Wed Dec 2 19:38:55 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 2 Dec 2020 19:38:55 GMT Subject: RFR: 8257623: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001/TestDescription.java shouldn't use timeout In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 19:13:50 GMT, Leonid Mesnik wrote: > The test is manual and shouldn't use the timeout Thumbs up. This is a trivial change and does not need to wait 24 hours. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1573 From lmesnik at openjdk.java.net Wed Dec 2 20:18:54 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Dec 2020 20:18:54 GMT Subject: Integrated: 8257623: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001/TestDescription.java shouldn't use timeout In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 19:13:50 GMT, Leonid Mesnik wrote: > The test is manual and shouldn't use the timeout This pull request has now been integrated. Changeset: 3e89981d Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/3e89981d Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8257623: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001/TestDescription.java shouldn't use timeout Reviewed-by: sspitsyn, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/1573 From iklam at openjdk.java.net Wed Dec 2 21:13:58 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 2 Dec 2020 21:13:58 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 18:44:08 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Wed Dec 2 23:02:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 23:02:56 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 18:44:08 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags Looks good! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From pliden at openjdk.java.net Thu Dec 3 11:14:57 2020 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 3 Dec 2020 11:14:57 GMT Subject: Withdrawn: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: <8AXKoU5QZN1F-ZeqclS573nfppjfOw48k3VlUR0qVNU=.8832b6fc-44d0-49bc-856f-602f812bb0d4@github.com> On Fri, 20 Nov 2020 13:23:28 GMT, Per Liden wrote: > A number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests don't take this into account, and can hence get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is needed (but also note that the object could have been collected by the time we call `disableCollection()`). > > In addition, `SDEDebuggee::executeTestMethods()` creates class loaders, which shortly after dies (and potentially gets collected). This creates problems on the debugger side, since code locations in this (now potentially unloaded class/method) gets invalidated. We must ensure that these class loaders stay alive to avoid these problems. > > Normally, these problems are fairly hard to provoke, since you have to be unlucky and get the timing of a GC just right. However, it's fairly easy to provoke by forcing GC cycles to happen all the time (e.g. using ZGC with -XX:ZCollectionInterval=0.01) and/or inserting `Thread.sleep()` calls right after calls to `newInstance()`. > > This patch fixes all instances of this problem that I managed to find. > > Testing: All `vmTestbase/nsk/jdi/` tests now pass, even when using the above described measures to try to provoke the problem. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1348 From pliden at openjdk.java.net Thu Dec 3 11:14:56 2020 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 3 Dec 2020 11:14:56 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:33:31 GMT, Per Liden wrote: >>> Just a friendly ping. Still looking for reviewers for this fix. >> >> Until we resolve the discussion in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987), I don't think your suggested fix should be applied since it could be viewed as a workaround to a debug agent issue (not shutting down GC during `VM.suspendAll`) or as something that needs to be clarified in the JDI and JDWP specs (checking for `ObjectReference.disableCollection` failures, even when under `VM.suspendAll`, and retrying the allocation). I'd like to see the discussion resolved and follow-on bugs files. > > Sorry, I had missed your latest reply in the JDK-8255987. Let's continue the discussion there. As a result of the discussion in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987), I'm withdrawing this PR and will open a new PR with the alternative solution discussed in the bug report. ------------- PR: https://git.openjdk.java.net/jdk/pull/1348 From lzang at openjdk.java.net Thu Dec 3 12:13:04 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 3 Dec 2020 12:13:04 GMT Subject: RFR: 8257668: SA JMap - skip non-java thread stack dump for heap dump Message-ID: when use SA JMap dump commands, such as "jhsdb jmap --binaryheap" or "dump heap" with "jhsdb clhsdb", it keep printing "dumpStack: not java Thread.". Skip non-java thread stack dump to avoid printing the message. ------------- Commit messages: - 8257668: SA JMap - skip non-java thread stack dump for heap dump Changes: https://git.openjdk.java.net/jdk/pull/1593/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1593&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257668 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1593.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1593/head:pull/1593 PR: https://git.openjdk.java.net/jdk/pull/1593 From hseigel at openjdk.java.net Thu Dec 3 13:17:59 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 3 Dec 2020 13:17:59 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 23:00:03 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > Looks good! > > Thanks, > David Thanks Coleen, Ioi, Serguei, and David for all the reviews. Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From hseigel at openjdk.java.net Thu Dec 3 13:18:01 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 3 Dec 2020 13:18:01 GMT Subject: Integrated: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 21:13:05 GMT, Harold Seigel wrote: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold This pull request has now been integrated. Changeset: e4497c9e Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/e4497c9e Stats: 326 lines in 23 files changed: 16 ins; 289 del; 21 mod 8256718: Obsolete the long term deprecated and aliased Trace flags Reviewed-by: sspitsyn, iklam, dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From pliden at openjdk.java.net Thu Dec 3 13:19:00 2020 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 3 Dec 2020 13:19:00 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException Message-ID: This PR replaces the withdraw PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): > Going back to the spec, ObjectReference.disableCollection() says: > > "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" > > and > > "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." > > But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: > > "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." > > No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. Testing: - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. ------------- Commit messages: - 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException Changes: https://git.openjdk.java.net/jdk/pull/1595/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1595&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255987 Stats: 161 lines in 8 files changed: 132 ins; 0 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/1595.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1595/head:pull/1595 PR: https://git.openjdk.java.net/jdk/pull/1595 From shade at openjdk.java.net Thu Dec 3 18:34:08 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Dec 2020 18:34:08 GMT Subject: RFR: 8257708: Remove redundant unmodifiableSet wrapper from already immutable set returned by Collections.singleton In-Reply-To: References: Message-ID: On Sun, 29 Nov 2020 18:03:24 GMT, Turbanov Andrey wrote: > 8257708: Remove redundant unmodifiableSet wrapper from already immutable set returned by Collections.singleton Changes requested by shade (Reviewer). Submitted -- https://bugs.openjdk.java.net/browse/JDK-8257708, rename this PR to "8257708: Remove redundant unmodifiableSet wrapper from already immutable set returned by Collections.singleton" to get it hooked up. src/java.management/share/classes/java/lang/management/DefaultPlatformMBeanProvider.java line 60: > 58: private final Set classLoadingInterfaceNames = > 59: Collections.singleton( > 60: "java.lang.management.ClassLoadingMXBean"); Here and later, I think we can avoid awkward newlines: `Collections.singleton("java.lang...")` ------------- PR: https://git.openjdk.java.net/jdk/pull/1505 From github.com+741251+turbanoff at openjdk.java.net Thu Dec 3 18:34:07 2020 From: github.com+741251+turbanoff at openjdk.java.net (Turbanov Andrey) Date: Thu, 3 Dec 2020 18:34:07 GMT Subject: RFR: 8257708: Remove redundant unmodifiableSet wrapper from already immutable set returned by Collections.singleton Message-ID: 8257708: Remove redundant unmodifiableSet wrapper from already immutable set returned by Collections.singleton ------------- Commit messages: - 8257708: Remove redundant unmodifiableSet wrapper from already immutable set returned by Collections.singleton - [PATCH] Remove redundant unmodifiableSet wrapper from already immutable set returned by Collections.singleton Changes: https://git.openjdk.java.net/jdk/pull/1505/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1505&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257708 Stats: 26 lines in 2 files changed: 0 ins; 12 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1505/head:pull/1505 PR: https://git.openjdk.java.net/jdk/pull/1505 From sspitsyn at openjdk.java.net Thu Dec 3 20:54:55 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 3 Dec 2020 20:54:55 GMT Subject: RFR: 8257708: Remove redundant unmodifiableSet wrapper from already immutable set returned by Collections.singleton In-Reply-To: References: Message-ID: On Sun, 29 Nov 2020 18:03:24 GMT, Andrey Turbanov wrote: > 8257708: Remove redundant unmodifiableSet wrapper from already immutable set returned by Collections.singleton Hi Andrey, It looks good - nice simplification. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1505 From amenkov at openjdk.java.net Thu Dec 3 21:35:55 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 3 Dec 2020 21:35:55 GMT Subject: Integrated: 8256808: com/sun/jdi/CatchAllTest.java failed with "NullPointerException: Cannot invoke "lib.jdb.Jdb.log(String)" because "this.jdb" is null" In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 21:36:12 GMT, Alex Menkov wrote: > JdbTest can get exception before jdb field is initialized. > As Jdb logging does not depend on the instance, made Jdb.log method static This pull request has now been integrated. Changeset: c5b32b33 Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/c5b32b33 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod 8256808: com/sun/jdi/CatchAllTest.java failed with "NullPointerException: Cannot invoke "lib.jdb.Jdb.log(String)" because "this.jdb" is null" Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/1443 From mchung at openjdk.java.net Thu Dec 3 23:00:03 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Dec 2020 23:00:03 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` Message-ID: This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. ------------- Commit messages: - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo - 8256167: Convert JDK use of to - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo - minor cleanup - Merge branch 'refersto' of https://github.com/kimbarrett/openjdk-jdk into refersTo - improve refersTo0 descriptions - basic functional test - change referent access - expand test - ... and 2 more: https://git.openjdk.java.net/jdk/compare/f0b11940...b1e645b1 Changes: https://git.openjdk.java.net/jdk/pull/1609/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1609&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256167 Stats: 52 lines in 12 files changed: 7 ins; 10 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/1609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1609/head:pull/1609 PR: https://git.openjdk.java.net/jdk/pull/1609 From sspitsyn at openjdk.java.net Fri Dec 4 03:10:57 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 4 Dec 2020 03:10:57 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. Hi Mandy, Looks good. I guess, you are going to update the copyright comments before the push. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1609 From github.com+741251+turbanoff at openjdk.java.net Fri Dec 4 06:34:55 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 4 Dec 2020 06:34:55 GMT Subject: Integrated: 8257708: Remove redundant unmodifiableSet wrapper from already immutable set returned by Collections.singleton In-Reply-To: References: Message-ID: On Sun, 29 Nov 2020 18:03:24 GMT, Andrey Turbanov wrote: > 8257708: Remove redundant unmodifiableSet wrapper from already immutable set returned by Collections.singleton This pull request has now been integrated. Changeset: d08c612b Author: Andrey Turbanov Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/d08c612b Stats: 26 lines in 2 files changed: 0 ins; 12 del; 14 mod 8257708: Remove redundant unmodifiableSet wrapper from already immutable set returned by Collections.singleton Reviewed-by: shade, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/1505 From shade at openjdk.java.net Fri Dec 4 06:34:54 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 4 Dec 2020 06:34:54 GMT Subject: RFR: 8257708: Remove redundant unmodifiableSet wrapper from already immutable set returned by Collections.singleton In-Reply-To: References: Message-ID: On Sun, 29 Nov 2020 18:03:24 GMT, Andrey Turbanov wrote: > 8257708: Remove redundant unmodifiableSet wrapper from already immutable set returned by Collections.singleton Looks good now! ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1505 From shade at openjdk.java.net Fri Dec 4 09:25:00 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 4 Dec 2020 09:25:00 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. Replacements look fine to me. src/java.base/share/classes/java/util/WeakHashMap.java line 291: > 289: if (e.refersTo(key)) return true; > 290: > 291: // then checks for equality Obnoxiously minor nit: plurality is inconsistent. `check if the given entry...` above, and `then check[s] for equality`. Should be `...then check for equality`? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1609 From ihse at openjdk.java.net Fri Dec 4 10:28:30 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 4 Dec 2020 10:28:30 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module Message-ID: A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. ------------- Commit messages: - Update references in test - Step 2: Update references - First stage, move actual data files Changes: https://git.openjdk.java.net/jdk/pull/1611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257733 Stats: 78 lines in 1575 files changed: 3 ins; 1 del; 74 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Fri Dec 4 10:32:11 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 4 Dec 2020 10:32:11 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. To facilitate review, here is a list on how the different directories under make/data has moved. **To java.base:** * blacklistedcertsconverter * cacerts * characterdata * charsetmapping * cldr * currency * lsrdata * publicsuffixlist * tzdata * unicodedata **To java.desktop:** * dtdbuilder * fontconfig * macosxicons * x11wrappergen **To jdk.compiler:** * symbols **To jdk.jdi:** * jdwp **Remaining in make:** * bundle * docs-resources * macosxsigning * mainmanifest ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From dfuchs at openjdk.java.net Fri Dec 4 10:41:12 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 4 Dec 2020 10:41:12 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. Hi Mandy, This looks good to me. There are a few places where a single call to `Reference::get` is replaced by multiple calls to `Reference::refersTo`, allowing the reference to get cleared in between, but as far as I could see that doesn't affect the overall logic which is still sound. So LGTM! best regards, -- daniel ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1609 From alanb at openjdk.java.net Fri Dec 4 11:17:12 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 4 Dec 2020 11:17:12 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 10:29:48 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > To facilitate review, here is a list on how the different directories under make/data has moved. > > **To java.base:** > * blacklistedcertsconverter > * cacerts > * characterdata > * charsetmapping > * cldr > * currency > * lsrdata > * publicsuffixlist > * tzdata > * unicodedata > > **To java.desktop:** > * dtdbuilder > * fontconfig > * macosxicons > * x11wrappergen > > **To jdk.compiler:** > * symbols > > **To jdk.jdi:** > * jdwp > > **Remaining in make:** > * bundle > * docs-resources > * macosxsigning > * mainmanifest Are you proposing any text or guidelines to be added to JEP 201 as part of this? I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From alanb at openjdk.java.net Fri Dec 4 11:23:14 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 4 Dec 2020 11:23:14 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: <_AwUb5GoPBZ7J4zM9wbX6uojd8dXt14z22gyHCS-P-g=.2087d23c-a808-4ba1-819d-9dd843f21427@github.com> On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. Good to use this done in the same release as refersTo was added. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1609 From ihse at openjdk.java.net Fri Dec 4 11:42:15 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 4 Dec 2020 11:42:15 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: On Fri, 4 Dec 2020 11:37:41 GMT, Magnus Ihse Bursie wrote: >> Are you proposing any text or guidelines to be added to JEP 201 as part of this? >> >> I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module. > > @AlanBateman Well, I don't know about updating JEP 201. Do you mean that `data` should be added to the list `classes`, `native`, `conf`, `legal` as presented under the heading "New scheme"? That list does not seem to have been kept up to date anyway. A quick glance also shows that we now have at least `man` and `lib` as well in this place. So either we say there's precedence for not updating the list, in which case I will do nothing. Or we should bring JEP 201 up-to-date with current practices, which then of course should include `data` but also all other new directories that has been added since JEP 201 was written. > > I really don't care either way, but my personal opinion is that JEP 201 presented a view on how the plan was to re-organize things, given the knowledge and state of affairs at that time, but how we keep the source code organized and structured from there on, is a living, day-to-day engineering effort that is just hampered by having to update a formal document, that serves little purpose now that it has been implemented. And I can certainly move jdwp.spec to java.base instead. That's the reason I need input on this: All I know is that is definitely not the responsibility of the Build Group to maintain that document, and I made my best guess at where to place it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Fri Dec 4 11:42:15 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 4 Dec 2020 11:42:15 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: Message-ID: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> On Fri, 4 Dec 2020 11:14:49 GMT, Alan Bateman wrote: >> To facilitate review, here is a list on how the different directories under make/data has moved. >> >> **To java.base:** >> * blacklistedcertsconverter >> * cacerts >> * characterdata >> * charsetmapping >> * cldr >> * currency >> * lsrdata >> * publicsuffixlist >> * tzdata >> * unicodedata >> >> **To java.desktop:** >> * dtdbuilder >> * fontconfig >> * macosxicons >> * x11wrappergen >> >> **To jdk.compiler:** >> * symbols >> >> **To jdk.jdi:** >> * jdwp >> >> **Remaining in make:** >> * bundle >> * docs-resources >> * macosxsigning >> * mainmanifest > > Are you proposing any text or guidelines to be added to JEP 201 as part of this? > > I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module. @AlanBateman Well, I don't know about updating JEP 201. Do you mean that `data` should be added to the list `classes`, `native`, `conf`, `legal` as presented under the heading "New scheme"? That list does not seem to have been kept up to date anyway. A quick glance also shows that we now have at least `man` and `lib` as well in this place. So either we say there's precedence for not updating the list, in which case I will do nothing. Or we should bring JEP 201 up-to-date with current practices, which then of course should include `data` but also all other new directories that has been added since JEP 201 was written. I really don't care either way, but my personal opinion is that JEP 201 presented a view on how the plan was to re-organize things, given the knowledge and state of affairs at that time, but how we keep the source code organized and structured from there on, is a living, day-to-day engineering effort that is just hampered by having to update a formal document, that serves little purpose now that it has been implemented. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From alanb at openjdk.java.net Fri Dec 4 12:33:15 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 4 Dec 2020 12:33:15 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: On Fri, 4 Dec 2020 11:38:51 GMT, Magnus Ihse Bursie wrote: > And I can certainly move jdwp.spec to java.base instead. If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From erikj at openjdk.java.net Fri Dec 4 14:08:13 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 4 Dec 2020 14:08:13 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote: >> And I can certainly move jdwp.spec to java.base instead. That's the reason I need input on this: All I know is that is definitely not the responsibility of the Build Group to maintain that document, and I made my best guess at where to place it. > >> And I can certainly move jdwp.spec to java.base instead. > > If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol. My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From erikj at openjdk.java.net Fri Dec 4 14:08:13 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 4 Dec 2020 14:08:13 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: On Fri, 4 Dec 2020 14:03:08 GMT, Erik Joelsson wrote: >>> And I can certainly move jdwp.spec to java.base instead. >> >> If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol. > > My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs. Regarding the chosen layout. Did you consider following the existing pattern of src//{share,}/data? ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From hohensee at amazon.com Fri Dec 4 14:19:31 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 4 Dec 2020 14:19:31 +0000 Subject: RFR: 8257668: SA JMap - skip non-java thread stack dump for heap dump Message-ID: <6DFA1F0D-71EE-49F1-AB77-4A989F28FAF6@amazon.com> Imo this is good idea because it eliminates useless/voluminous output. It's a behavioral change nonetheless, so it would be great for others to weigh in. Code change is fine. Thanks, Paul ?-----Original Message----- From: serviceability-dev on behalf of Lin Zang Date: Thursday, December 3, 2020 at 4:16 AM To: "serviceability-dev at openjdk.java.net" Subject: RFR: 8257668: SA JMap - skip non-java thread stack dump for heap dump when use SA JMap dump commands, such as "jhsdb jmap --binaryheap" or "dump heap" with "jhsdb clhsdb", it keep printing "dumpStack: not java Thread.". Skip non-java thread stack dump to avoid printing the message. ------------- Commit messages: - 8257668: SA JMap - skip non-java thread stack dump for heap dump Changes: https://git.openjdk.java.net/jdk/pull/1593/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1593&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257668 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1593.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1593/head:pull/1593 PR: https://git.openjdk.java.net/jdk/pull/1593 From ihse at openjdk.java.net Fri Dec 4 15:20:14 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 4 Dec 2020 15:20:14 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: On Fri, 4 Dec 2020 14:05:54 GMT, Erik Joelsson wrote: >> My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs. > > Regarding the chosen layout. Did you consider following the existing pattern of src//{share,}/data? @erikj79 Good point, that makes much more sense. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From mchung at openjdk.java.net Fri Dec 4 18:12:17 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Dec 2020 18:12:17 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: <2VSYwnm42o5BZfPO2S9uk88siPje_jMx25x03t_xQuc=.a78bc191-7df4-4386-a3ac-4a118518def4@github.com> On Fri, 4 Dec 2020 09:19:23 GMT, Aleksey Shipilev wrote: >> This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. > > src/java.base/share/classes/java/util/WeakHashMap.java line 291: > >> 289: if (e.refersTo(key)) return true; >> 290: >> 291: // then checks for equality > > Obnoxiously minor nit: plurality is inconsistent. `check if the given entry...` above, and `then check[s] for equality`. Should be `...then check for equality`? OK. Fixed this grammatical nit. ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From kbarrett at openjdk.java.net Fri Dec 4 18:18:13 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 4 Dec 2020 18:18:13 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. src/java.base/share/classes/java/util/WeakHashMap.java line 293: > 291: // then checks for equality > 292: Object k = e.get(); > 293: return key == k || key.equals(k); I think `key == k` is already covered by refersTo. But k could be null; checking for that here might be useful, to skip the call to equals in that case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From cjplummer at openjdk.java.net Fri Dec 4 19:43:11 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 4 Dec 2020 19:43:11 GMT Subject: RFR: 8257668: SA JMap - skip non-java thread stack dump for heap dump In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 12:06:23 GMT, Lin Zang wrote: > when use SA JMap dump commands, such as "jhsdb jmap --binaryheap" or "dump heap" with "jhsdb clhsdb", it keep printing "dumpStack: not java Thread.". > Skip non-java thread stack dump to avoid printing the message. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1593 From plevart at openjdk.java.net Fri Dec 4 19:50:15 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 4 Dec 2020 19:50:15 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. src/java.management/share/classes/com/sun/jmx/mbeanserver/WeakIdentityHashMap.java line 127: > 125: T got = get(); > 126: return got != null && wr.refersTo(got); > 127: } Here you could pre-screen the get() with: if (this.refersTo(null) != wr.refersTo(null)) return false; In case one of the two WeakReference(s) is cleared and the other is not, they are not equal and you don't call this.get() in such case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From kcr at openjdk.java.net Fri Dec 4 20:08:16 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Dec 2020 20:08:16 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. You have a typo that will cause a compilation error. src/java.base/share/classes/java/util/WeakHashMap.java line 437: > 435: int index = indexFor(h, tab.length); > 436: Entry e = tab[index]; > 437: while (e != null && !(e.hash == h && matchesKey(e, k)) This doesn't compile, which is why the checks from the GitHub actions build failed. ------------- Changes requested by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/1609 From sspitsyn at openjdk.java.net Fri Dec 4 20:11:12 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 4 Dec 2020 20:11:12 GMT Subject: RFR: 8257668: SA JMap - skip non-java thread stack dump for heap dump In-Reply-To: References: Message-ID: <53dKM9xyD0NYA91Apsniv_32pwJ5vdQO0O4eVfPgIFg=.9c47947e-16f8-44dd-9b48-f304aee14b26@github.com> On Thu, 3 Dec 2020 12:06:23 GMT, Lin Zang wrote: > when use SA JMap dump commands, such as "jhsdb jmap --binaryheap" or "dump heap" with "jhsdb clhsdb", it keep printing "dumpStack: not java Thread.". > Skip non-java thread stack dump to avoid printing the message. Hi Lin, It looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1593 From mchung at openjdk.java.net Fri Dec 4 20:12:13 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Dec 2020 20:12:13 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 18:12:36 GMT, Kim Barrett wrote: >> This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. > > src/java.base/share/classes/java/util/WeakHashMap.java line 293: > >> 291: // then checks for equality >> 292: Object k = e.get(); >> 293: return key == k || key.equals(k); > > I think `key == k` is already covered by refersTo. But k could be null; checking for that here might be useful, to skip the call to equals in that case. Good point on checking k != null. A cleaner check: // then check for equality if the referent is not cleared Object k = e.get(); return k != null || key.equals(k); ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From cjplummer at openjdk.java.net Fri Dec 4 20:18:12 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 4 Dec 2020 20:18:12 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 12:55:04 GMT, Per Liden wrote: > This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. > > The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. > > However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): > >> Going back to the spec, ObjectReference.disableCollection() says: >> >> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >> >> and >> >> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >> >> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >> >> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >> >> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). > > Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. > > However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. > > This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. > > Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: > - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. > - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. > - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. > - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. > > Testing: > - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java line 194: > 192: debuggee.resume(); > 193: checkDebugeeAnswer_instances(className, baseInstances); > 194: debuggee.suspend(); Before the changes in this PR, what was triggering the (expected) collection of the objects? test/hotspot/jtreg/vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java line 85: > 83: array.disableCollection(); > 84: } catch (ObjectCollectedException e) { > 85: continue; Maybe add a comment: "Since the VM is not suspended, the object may have been collected before disableCollection() could be called on it. Just ignore and continue doing allocations until we run out of memory." ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From plevart at openjdk.java.net Fri Dec 4 20:20:11 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 4 Dec 2020 20:20:11 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 20:09:01 GMT, Mandy Chung wrote: >> src/java.base/share/classes/java/util/WeakHashMap.java line 293: >> >>> 291: // then checks for equality >>> 292: Object k = e.get(); >>> 293: return key == k || key.equals(k); >> >> I think `key == k` is already covered by refersTo. But k could be null; checking for that here might be useful, to skip the call to equals in that case. > > Good point on checking k != null. A cleaner check: > > // then check for equality if the referent is not cleared > Object k = e.get(); > return k != null || key.equals(k); You meant: `return k != null && key.equals(k);` right? ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From mchung at openjdk.java.net Fri Dec 4 20:20:14 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Dec 2020 20:20:14 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 19:47:17 GMT, Peter Levart wrote: >> This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. > > src/java.management/share/classes/com/sun/jmx/mbeanserver/WeakIdentityHashMap.java line 127: > >> 125: T got = get(); >> 126: return got != null && wr.refersTo(got); >> 127: } > > Here you could pre-screen the get() with: > > if (this.refersTo(null) != wr.refersTo(null)) return false; > > In case one of the two WeakReference(s) is cleared and the other is not, they are not equal and you don't call this.get() in such case. `expunge` is called at `get`, `put`, and `remove`. While there is a chance that a referent might be cleared, I will leave this as is and this patch simply replaces to use `refersTo`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From mchung at openjdk.java.net Fri Dec 4 20:20:16 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Dec 2020 20:20:16 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 20:05:23 GMT, Kevin Rushforth wrote: >> This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. > > src/java.base/share/classes/java/util/WeakHashMap.java line 437: > >> 435: int index = indexFor(h, tab.length); >> 436: Entry e = tab[index]; >> 437: while (e != null && !(e.hash == h && matchesKey(e, k)) > > This doesn't compile, which is why the checks from the GitHub actions build failed. I caught that and it's in my local repo that I haven't pushed the commit. Sorry for not syncing my branch for review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From plevart at openjdk.java.net Fri Dec 4 20:38:11 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 4 Dec 2020 20:38:11 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 20:16:14 GMT, Mandy Chung wrote: >> src/java.management/share/classes/com/sun/jmx/mbeanserver/WeakIdentityHashMap.java line 127: >> >>> 125: T got = get(); >>> 126: return got != null && wr.refersTo(got); >>> 127: } >> >> Here you could pre-screen the get() with: >> >> if (this.refersTo(null) != wr.refersTo(null)) return false; >> >> In case one of the two WeakReference(s) is cleared and the other is not, they are not equal and you don't call this.get() in such case. > > `expunge` is called at `get`, `put`, and `remove`. While there is a chance that a referent might be cleared, I will leave this as is and this patch simply replaces to use `refersTo`. You're right. Where it would matter is in expunge() where the Map keys that get polled off the reference queue are all already cleared and when HashMap.remove(key) is called with such cleared key, it is this cleared key that is the target of key.equals(other) method invocation (and not vice versa), so it doesn't matter if .get() is called on such key as it is already cleared. ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From cjplummer at openjdk.java.net Fri Dec 4 21:04:15 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 4 Dec 2020 21:04:15 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 12:55:04 GMT, Per Liden wrote: > This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. > > The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. > > However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): > >> Going back to the spec, ObjectReference.disableCollection() says: >> >> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >> >> and >> >> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >> >> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >> >> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >> >> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). > > Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. > > However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. > > This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. > > Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: > - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. > - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. > - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. > - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. > > Testing: > - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. src/jdk.jdwp.agent/share/native/libjdwp/commonRef.c line 632: > 630: if (weakRef == NULL) { > 631: EXIT_ERROR(AGENT_ERROR_NULL_POINTER,"NewWeakGlobalRef"); > 632: } I'm not so sure I agree that having a fatal error here is the right thing to do. The only other user of `weakenNode()` is `ObjectReference.disableCollection()`. It returns an error to the debugger if `weakenNode()` returns `NULL`. However, I'm not so sure that's a good thing to do here either, since it means the `VM.resume()` will need to fail. Possibly the error should just be ignored, and we live with the ref staying strong. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From cjplummer at openjdk.java.net Fri Dec 4 21:26:12 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 4 Dec 2020 21:26:12 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: <-2Yx99rM6jO7OHIzIlaHfdeojwgwwl7QthEqINqxiu4=.ae8922de-ea23-47c6-adff-3618cecd7eaf@github.com> On Fri, 4 Dec 2020 21:01:13 GMT, Chris Plummer wrote: >> This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. >> >> The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. >> >> However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): >> >>> Going back to the spec, ObjectReference.disableCollection() says: >>> >>> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >>> >>> and >>> >>> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >>> >>> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >>> >>> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >>> >>> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). >> >> Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. >> >> However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. >> >> This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. >> >> Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: >> - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. >> - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. >> - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. >> - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. >> >> Testing: >> - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. > > src/jdk.jdwp.agent/share/native/libjdwp/commonRef.c line 632: > >> 630: if (weakRef == NULL) { >> 631: EXIT_ERROR(AGENT_ERROR_NULL_POINTER,"NewWeakGlobalRef"); >> 632: } > > I'm not so sure I agree that having a fatal error here is the right thing to do. The only other user of `weakenNode()` is `ObjectReference.disableCollection()`. It returns an error to the debugger if `weakenNode()` returns `NULL`. However, I'm not so sure that's a good thing to do here either, since it means the `VM.resume()` will need to fail. Possibly the error should just be ignored, and we live with the ref staying strong. Another options is to save away the weakref in the node when strengthening. This would benefit `ObjectReference.disableCollection()` also, since it would no longer need to deal with a potential OOM. However, I'm not so sure it's actually worth doing. Trying to keep the debug session alive will having allocation errors is probably a fools errand. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From mchung at openjdk.java.net Fri Dec 4 22:07:14 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Dec 2020 22:07:14 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 20:14:13 GMT, Peter Levart wrote: >> Good point on checking k != null. A cleaner check: >> >> // then check for equality if the referent is not cleared >> Object k = e.get(); >> return k != null || key.equals(k); > > You meant: `return k != null && key.equals(k);` right? oops...yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From mchung at openjdk.java.net Fri Dec 4 22:38:24 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Dec 2020 22:38:24 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` [v2] In-Reply-To: References: Message-ID: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - revise matchsKey to check equality if the reference is not cleared - fix typo - update copyright end year and fixup grammatical nit - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo - 8256167: Convert JDK use of to - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo - minor cleanup - Merge branch 'refersto' of https://github.com/kimbarrett/openjdk-jdk into refersTo - improve refersTo0 descriptions - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d8ac76fa...72947eb3 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1609/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1609&range=01 Stats: 60 lines in 12 files changed: 7 ins; 11 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/1609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1609/head:pull/1609 PR: https://git.openjdk.java.net/jdk/pull/1609 From phh at openjdk.java.net Fri Dec 4 22:52:10 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Fri, 4 Dec 2020 22:52:10 GMT Subject: RFR: 8257668: SA JMap - skip non-java thread stack dump for heap dump In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 12:06:23 GMT, Lin Zang wrote: > when use SA JMap dump commands, such as "jhsdb jmap --binaryheap" or "dump heap" with "jhsdb clhsdb", it keep printing "dumpStack: not java Thread.". > Skip non-java thread stack dump to avoid printing the message. Marked as reviewed by phh (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1593 From lzang at openjdk.java.net Sat Dec 5 00:35:27 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Sat, 5 Dec 2020 00:35:27 GMT Subject: RFR: 8257668: SA JMap - skip non-java thread stack dump for heap dump [v2] In-Reply-To: References: Message-ID: > when use SA JMap dump commands, such as "jhsdb jmap --binaryheap" or "dump heap" with "jhsdb clhsdb", it keep printing "dumpStack: not java Thread.". > Skip non-java thread stack dump to avoid printing the message. Lin Zang has updated the pull request incrementally with one additional commit since the last revision: remove deadcode of println instead of change in HeapHprofBinWriter ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1593/files - new: https://git.openjdk.java.net/jdk/pull/1593/files/f4df6c53..f1361a68 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1593&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1593&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1593.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1593/head:pull/1593 PR: https://git.openjdk.java.net/jdk/pull/1593 From lzang at openjdk.java.net Sat Dec 5 00:35:28 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Sat, 5 Dec 2020 00:35:28 GMT Subject: RFR: 8257668: SA JMap - skip non-java thread stack dump for heap dump [v2] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 19:39:58 GMT, Chris Plummer wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> remove deadcode of println instead of change in HeapHprofBinWriter > > Marked as reviewed by cjplummer (Reviewer). @plummercj @phohensee @sspitsyn, Thanks a lot for your review, I have updated the pr to remove the deadcode as described in Chris'c comments. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/1593 From dlsmith at openjdk.java.net Sat Dec 5 01:52:21 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Sat, 5 Dec 2020 01:52:21 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal Message-ID: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> Integration of JEP 390, addressing the following issues: 8252180: [JEP 390] Deprecate wrapper class constructors for removal 8254047: [JEP 390] Revise "value-based class" & apply to wrappers 8252181: [JEP 390] Define & apply annotation jdk.internal.ValueBased 8252183: [JEP 390] Add 'lint' warning for @ValueBased classes 8257027: [JEP 390] Diagnose synchronization on @ValueBased classes See https://github.com/openjdk/valhalla/tree/jep390 for development history. ------------- Commit messages: - Merge - 8257776: [valhalla:jep390] Add disclaimer about future changes to value-based classes - 8254275: [valhalla/jep390] Revise "value-based class" & apply to wrappers - 8252182: [JEP 390] Diagnose synchronization on @ValueBased classes - Merge - 8256663: [test] Deprecated use of new Double in jshell ImportTest - 8253962: Add @ValueBased to unmodifable Collection implementation classes - 8256002: Cleanup of Wrapper changes - Merge - 8254271: Development to deprecate wrapper class constructors for removal - ... and 2 more: https://git.openjdk.java.net/jdk/compare/93b6ab56...7c5e5bfe Changes: https://git.openjdk.java.net/jdk/pull/1636/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1636&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252180 Stats: 902 lines in 114 files changed: 489 ins; 121 del; 292 mod Patch: https://git.openjdk.java.net/jdk/pull/1636.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1636/head:pull/1636 PR: https://git.openjdk.java.net/jdk/pull/1636 From kbarrett at openjdk.java.net Sat Dec 5 02:11:13 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 5 Dec 2020 02:11:13 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` [v2] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 22:38:24 GMT, Mandy Chung wrote: >> This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. > > Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - revise matchsKey to check equality if the reference is not cleared > - fix typo > - update copyright end year and fixup grammatical nit > - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo > - 8256167: Convert JDK use of to > - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo > - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo > - minor cleanup > - Merge branch 'refersto' of https://github.com/kimbarrett/openjdk-jdk into refersTo > - improve refersTo0 descriptions > - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d8ac76fa...72947eb3 Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From dlsmith at openjdk.java.net Sat Dec 5 03:07:11 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Sat, 5 Dec 2020 03:07:11 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> Message-ID: On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - Deprecate wrapper class constructors for removal > - Revise "value-based class" & apply to wrappers > - Define & apply annotation jdk.internal.ValueBased > - Add 'lint' warning for @ValueBased classes > - Diagnose synchronization on @ValueBased classes > > All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.) > > CSRs have also been completed or are nearly complete: > > - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation > - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class" > - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings > > Here's an overview of the files changed: > > - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes. > > - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance. > > - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation. > > - `src/java.management.rmi`: removing uses of wrapper class constructors. > > - `src/java.xml`: removing uses of wrapper class constructors. > > - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`. > > - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.) > > - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests > > - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics > > - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`. I've updated the description to provide an overview for those unfamiliar with this work. Reviewers are welcome, including those who have previously reviewed a subset of these changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/1636 From cjplummer at openjdk.java.net Sat Dec 5 03:12:14 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Sat, 5 Dec 2020 03:12:14 GMT Subject: RFR: 8257668: SA JMap - skip non-java thread stack dump for heap dump [v2] In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 00:35:27 GMT, Lin Zang wrote: >> when use SA JMap dump commands, such as "jhsdb jmap --binaryheap" or "dump heap" with "jhsdb clhsdb", it keep printing "dumpStack: not java Thread.". >> Skip non-java thread stack dump to avoid printing the message. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > remove deadcode of println instead of change in HeapHprofBinWriter Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1593 From redestad at openjdk.java.net Sat Dec 5 13:18:20 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Sat, 5 Dec 2020 13:18:20 GMT Subject: RFR: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() Message-ID: This moves the mirroring of vmSymbols in ciSymbols to a separate file, ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol namespace). In a few places code is moved from .hpp to .cpp to facilitate this. With PCH disabled, this reduces total includes from 276949 to 276332 ------------- Commit messages: - remote merge - Prepare for 1237 changes - Adjust includes after vmIntrinsic changes - Merge master - Outline is_call_site_target to remove include from ciField.hpp - Outline is_autobox_cache to remove include from ciField.hpp - Merge branch 'master' into ciSymbols - Fix bad definition - Define debug-only sid_ok in .cpp to avoid need to include vmSymbols.hpp in ciSymbol.hpp - Revert accidental include order swap - ... and 1 more: https://git.openjdk.java.net/jdk/compare/86b65756...b05957b8 Changes: https://git.openjdk.java.net/jdk/pull/1256/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1256&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256424 Stats: 174 lines in 32 files changed: 102 ins; 30 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/1256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1256/head:pull/1256 PR: https://git.openjdk.java.net/jdk/pull/1256 From phh at openjdk.java.net Sat Dec 5 19:15:12 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Sat, 5 Dec 2020 19:15:12 GMT Subject: RFR: 8257668: SA JMap - skip non-java thread stack dump for heap dump [v2] In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 00:35:27 GMT, Lin Zang wrote: >> when use SA JMap dump commands, such as "jhsdb jmap --binaryheap" or "dump heap" with "jhsdb clhsdb", it keep printing "dumpStack: not java Thread.". >> Skip non-java thread stack dump to avoid printing the message. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > remove deadcode of println instead of change in HeapHprofBinWriter Marked as reviewed by phh (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1593 From mchung at openjdk.java.net Sun Dec 6 00:11:14 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Sun, 6 Dec 2020 00:11:14 GMT Subject: Integrated: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. This pull request has now been integrated. Changeset: 972bc3b4 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/972bc3b4 Stats: 60 lines in 12 files changed: 7 ins; 11 del; 42 mod 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` Reviewed-by: sspitsyn, shade, dfuchs, alanb, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From lzang at openjdk.java.net Mon Dec 7 03:32:12 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 7 Dec 2020 03:32:12 GMT Subject: RFR: 8257668: SA JMap - skip non-java thread stack dump for heap dump [v2] In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 19:12:37 GMT, Paul Hohensee wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> remove deadcode of println instead of change in HeapHprofBinWriter > > Marked as reviewed by phh (Reviewer). Dear all, Thanks a lot for reviewing, may I ask your help pushing it? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1593 From lzang at openjdk.java.net Mon Dec 7 04:05:13 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 7 Dec 2020 04:05:13 GMT Subject: Integrated: 8257668: SA JMap - skip non-java thread stack dump for heap dump In-Reply-To: References: Message-ID: <9D22d2ip33eiwCIiVi1h00tkrpMqWPKqKoPoT5mCaJc=.2960fab0-358d-4b14-9b9a-c6229c184c2a@github.com> On Thu, 3 Dec 2020 12:06:23 GMT, Lin Zang wrote: > when use SA JMap dump commands, such as "jhsdb jmap --binaryheap" or "dump heap" with "jhsdb clhsdb", it keep printing "dumpStack: not java Thread.". > Skip non-java thread stack dump to avoid printing the message. This pull request has now been integrated. Changeset: 29a09c89 Author: Lin Zang Committer: David Holmes URL: https://git.openjdk.java.net/jdk/commit/29a09c89 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8257668: SA JMap - skip non-java thread stack dump for heap dump Reviewed-by: cjplummer, sspitsyn, phh ------------- PR: https://git.openjdk.java.net/jdk/pull/1593 From david.holmes at oracle.com Mon Dec 7 04:59:04 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2020 14:59:04 +1000 Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: <74bdc286-64be-1da1-e5df-a894f7912aff@oracle.com> Hi Per, On 3/12/2020 11:19 pm, Per Liden wrote: > This PR replaces the withdraw PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. > > The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. > > However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): > >> Going back to the spec, ObjectReference.disableCollection() says: >> >> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >> >> and >> >> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >> >> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >> >> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >> >> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). I think we can quite reasonably infer that "suspending a VM" means calling VirtualMachine.suspend to suspend all the threads of the target VM. > Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. You can imagine though that 25 years ago it was not an unreasonable assumption that GC only runs in response to (failed) allocation requests from running application threads - i.e. that it is a synchronous response to application code execution. Hence all threads suspended implies no allocation and thus no GC. (Someone can correct me if I'm wrong but way way back didn't running in JDI debug mode force use of SerialGC?) I'm somewhat surprised that it has taken this long to discover that our GC's are no longer operating in a way that JDI requires them to. > However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. I assume that the GC folk would be horrified if I were to suggest a global flag to enable/disable GC? ;-) Doing what is suggested sounds reasonable, from a functional perspective, to get the desired effect of not collecting any objects of interest. But I do have to wonder how many objects we are typically dealing with and what the performance impact of this might be if we have to iterate through each all the objects? Thanks, David ----- > This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. > > Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: > - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. > - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. > - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. > - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. > > Testing: > - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. > > ------------- > > Commit messages: > - 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException > > Changes: https://git.openjdk.java.net/jdk/pull/1595/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1595&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8255987 > Stats: 161 lines in 8 files changed: 132 ins; 0 del; 29 mod > Patch: https://git.openjdk.java.net/jdk/pull/1595.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1595/head:pull/1595 > > PR: https://git.openjdk.java.net/jdk/pull/1595 > From dholmes at openjdk.java.net Mon Dec 7 06:07:14 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Dec 2020 06:07:14 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 12:55:04 GMT, Per Liden wrote: > This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. > > The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. > > However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): > >> Going back to the spec, ObjectReference.disableCollection() says: >> >> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >> >> and >> >> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >> >> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >> >> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >> >> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). > > Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. > > However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. > > This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. > > Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: > - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. > - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. > - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. > - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. > > Testing: > - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. Overall seems okay. Some comments on tests as I think the existing test logic is quite confused in places. Thanks, David src/jdk.jdwp.agent/share/native/libjdwp/commonRef.c line 586: > 584: jobject strongRef; > 585: > 586: strongRef = strengthenNode(env, node); This can just be one line. src/jdk.jdwp.agent/share/native/libjdwp/commonRef.c line 629: > 627: jweak weakRef; > 628: > 629: weakRef = weakenNode(env, node); Again this can be a single line. src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 1560: > 1558: * garbage collected while the VM is suspended. > 1559: */ > 1560: commonRef_pinAll(); Can we have multiple VM.suspend calls? The suspendAllCount seems to suggest that. In which case shouldn't we only pin on the 0->1 transition, and only unpin on the 1->0 transition? ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From dholmes at openjdk.java.net Mon Dec 7 06:07:17 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Dec 2020 06:07:17 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: <0dKZv-rhWELcC1ig9H32zb_irP_ksIehm-dlY3njJP4=.94a95183-12f5-4443-8cc4-223a66111699@github.com> On Fri, 4 Dec 2020 20:12:11 GMT, Chris Plummer wrote: >> This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. >> >> The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. >> >> However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): >> >>> Going back to the spec, ObjectReference.disableCollection() says: >>> >>> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >>> >>> and >>> >>> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >>> >>> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >>> >>> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >>> >>> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). >> >> Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. >> >> However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. >> >> This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. >> >> Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: >> - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. >> - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. >> - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. >> - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. >> >> Testing: >> - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. > > test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java line 194: > >> 192: debuggee.resume(); >> 193: checkDebugeeAnswer_instances(className, baseInstances); >> 194: debuggee.suspend(); > > Before the changes in this PR, what was triggering the (expected) collection of the objects? These changes aren't making sense to me - but then this test is not making much sense to me either. The testArrayType logic is quite different to testClassType and now seems invalid. It suspends the VM, then calls disableCollection on all the object refs of interest, then later calls enableCollection and then resumes the VM. The calls to disableCollection/enableCollection seem pointless if GC is disabled while the VM is suspended. I suspect this was added because VM suspension was not in fact stopping the GC. The testClassType test is doing what? I can't tell what it expects to be checking with checkDebugeeAnswer_instances, but there's no VM suspension (presently) and no disableCollection calls. ??? ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From dholmes at openjdk.java.net Mon Dec 7 06:07:15 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Dec 2020 06:07:15 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: <-2Yx99rM6jO7OHIzIlaHfdeojwgwwl7QthEqINqxiu4=.ae8922de-ea23-47c6-adff-3618cecd7eaf@github.com> References: <-2Yx99rM6jO7OHIzIlaHfdeojwgwwl7QthEqINqxiu4=.ae8922de-ea23-47c6-adff-3618cecd7eaf@github.com> Message-ID: <_mg_tfWiVdggsrpKEDFeFAR1-22yUsy-tTe0foBDdC4=.191dc88a-df48-4127-805d-62fba59d2750@github.com> On Fri, 4 Dec 2020 21:22:53 GMT, Chris Plummer wrote: >> src/jdk.jdwp.agent/share/native/libjdwp/commonRef.c line 632: >> >>> 630: if (weakRef == NULL) { >>> 631: EXIT_ERROR(AGENT_ERROR_NULL_POINTER,"NewWeakGlobalRef"); >>> 632: } >> >> I'm not so sure I agree that having a fatal error here is the right thing to do. The only other user of `weakenNode()` is `ObjectReference.disableCollection()`. It returns an error to the debugger if `weakenNode()` returns `NULL`. However, I'm not so sure that's a good thing to do here either, since it means the `VM.resume()` will need to fail. Possibly the error should just be ignored, and we live with the ref staying strong. > > Another options is to save away the weakref in the node when strengthening. This would benefit `ObjectReference.disableCollection()` also, since it would no longer need to deal with a potential OOM. However, I'm not so sure it's actually worth doing. Trying to keep the debug session alive will having allocation errors is probably a fools errand. I agree a fatal error here seems excessive. Simply maintaining the strong ref seems reasonable. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From cjplummer at openjdk.java.net Mon Dec 7 06:30:15 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 7 Dec 2020 06:30:15 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 05:18:12 GMT, David Holmes wrote: >> This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. >> >> The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. >> >> However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): >> >>> Going back to the spec, ObjectReference.disableCollection() says: >>> >>> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >>> >>> and >>> >>> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >>> >>> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >>> >>> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >>> >>> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). >> >> Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. >> >> However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. >> >> This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. >> >> Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: >> - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. >> - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. >> - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. >> - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. >> >> Testing: >> - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. > > src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 1560: > >> 1558: * garbage collected while the VM is suspended. >> 1559: */ >> 1560: commonRef_pinAll(); > > Can we have multiple VM.suspend calls? The suspendAllCount seems to suggest that. In which case shouldn't we only pin on the 0->1 transition, and only unpin on the 1->0 transition? That was something I pointed out in the pre-review, and it has been addressed in `commonRef_pinAll/unpinAll`: `568 if (gdata->pinAllCount == 1) {` `618 if (gdata->pinAllCount == 0) {` ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From david.holmes at oracle.com Mon Dec 7 07:04:47 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2020 17:04:47 +1000 Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: <0eb7161b-278d-53f9-5072-9dd39273c31f@oracle.com> On 7/12/2020 4:30 pm, Chris Plummer wrote: > On Mon, 7 Dec 2020 05:18:12 GMT, David Holmes wrote: >>> 1558: * garbage collected while the VM is suspended. >>> 1559: */ >>> 1560: commonRef_pinAll(); >> >> Can we have multiple VM.suspend calls? The suspendAllCount seems to suggest that. In which case shouldn't we only pin on the 0->1 transition, and only unpin on the 1->0 transition? > > That was something I pointed out in the pre-review, and it has been addressed in `commonRef_pinAll/unpinAll`: > > `568 if (gdata->pinAllCount == 1) {` > `618 if (gdata->pinAllCount == 0) {` Okay. I would not have handled it at that level, but would have had pinAll/unpinAll operate unconditionally, but the calls to those methods being conditional based on the suspendAllCount. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1595 > From cjplummer at openjdk.java.net Mon Dec 7 07:44:14 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 7 Dec 2020 07:44:14 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 06:27:20 GMT, Chris Plummer wrote: >> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 1560: >> >>> 1558: * garbage collected while the VM is suspended. >>> 1559: */ >>> 1560: commonRef_pinAll(); >> >> Can we have multiple VM.suspend calls? The suspendAllCount seems to suggest that. In which case shouldn't we only pin on the 0->1 transition, and only unpin on the 1->0 transition? > > That was something I pointed out in the pre-review, and it has been addressed in `commonRef_pinAll/unpinAll`: > > `568 if (gdata->pinAllCount == 1) {` > `618 if (gdata->pinAllCount == 0) {` > Okay. I would not have handled it at that level, but would have had pinAll/unpinAll operate unconditionally, but the calls to those methods being conditional based on the suspendAllCount. > >David Well, that's assuming `pinAll()` will only ever be used by by `suspendAll()`. One could imaging a future use, such as if `VirtualMachine.disableCollection()` were ever to be added. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From rrich at openjdk.java.net Mon Dec 7 10:10:18 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 7 Dec 2020 10:10:18 GMT Subject: RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads Message-ID: This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused timeout failures when graal is enabled. The fix is to avoid suspending all threads when a breakpoint is reached and then resume just the main thread again. This pattern was used in the test case EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal threads remained suspended and, running with -Xbatch, the main thread waited (with timeout) for completion of compile tasks. The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only to the main test thread and all explicit resume calls apply to all java threads. Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is reduced from 30s to 10s. ------------- Commit messages: - 8255381: com/sun/jdi/EATests.java should not suspend graal threads Changes: https://git.openjdk.java.net/jdk/pull/1625/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1625&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255381 Stats: 91 lines in 2 files changed: 33 ins; 10 del; 48 mod Patch: https://git.openjdk.java.net/jdk/pull/1625.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1625/head:pull/1625 PR: https://git.openjdk.java.net/jdk/pull/1625 From pliden at openjdk.java.net Mon Dec 7 10:49:16 2020 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 7 Dec 2020 10:49:16 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 20:12:11 GMT, Chris Plummer wrote: >> This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. >> >> The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. >> >> However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): >> >>> Going back to the spec, ObjectReference.disableCollection() says: >>> >>> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >>> >>> and >>> >>> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >>> >>> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >>> >>> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >>> >>> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). >> >> Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. >> >> However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. >> >> This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. >> >> Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: >> - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. >> - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. >> - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. >> - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. >> >> Testing: >> - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. > > test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java line 194: > >> 192: debuggee.resume(); >> 193: checkDebugeeAnswer_instances(className, baseInstances); >> 194: debuggee.suspend(); > > Before the changes in this PR, what was triggering the (expected) collection of the objects? @plummercj Nothing was explicitly triggering collection of these objects. However, the test is explicitly checking the number of objects "reachable for the purposes of garbage collection" in `checkDebugeeAnswer_instances()`. The tests sets up a breakpoint (with SUSPEND_ALL), which suspends the VM. Then it creates a number of new instances and expects these to be weakly reachable. However, with this change, suspending the VM will make all objects "reachable for the purposes of garbage collection". So, to let the test continue to create objects which are weakly reachable we need to first resume the VM, create the new instances, and then suspend it again. @dholmes-ora I have no idea why these tests are so different. The VM suspend is implicit in the breakpoint in this test, which is set up using SUSPEND_ALL. > test/hotspot/jtreg/vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java line 85: > >> 83: array.disableCollection(); >> 84: } catch (ObjectCollectedException e) { >> 85: continue; > > Maybe add a comment: "Since the VM is not suspended, the object may have been collected before disableCollection() could be called on it. Just ignore and continue doing allocations until we run out of memory." Sounds good, will fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From pliden at openjdk.java.net Mon Dec 7 11:00:15 2020 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 7 Dec 2020 11:00:15 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: <_mg_tfWiVdggsrpKEDFeFAR1-22yUsy-tTe0foBDdC4=.191dc88a-df48-4127-805d-62fba59d2750@github.com> References: <-2Yx99rM6jO7OHIzIlaHfdeojwgwwl7QthEqINqxiu4=.ae8922de-ea23-47c6-adff-3618cecd7eaf@github.com> <_mg_tfWiVdggsrpKEDFeFAR1-22yUsy-tTe0foBDdC4=.191dc88a-df48-4127-805d-62fba59d2750@github.com> Message-ID: On Mon, 7 Dec 2020 05:14:36 GMT, David Holmes wrote: >> Another options is to save away the weakref in the node when strengthening. This would benefit `ObjectReference.disableCollection()` also, since it would no longer need to deal with a potential OOM. However, I'm not so sure it's actually worth doing. Trying to keep the debug session alive will having allocation errors is probably a fools errand. > > I agree a fatal error here seems excessive. Simply maintaining the strong ref seems reasonable. I was trying to mimic what we already do in `strengthenNode()`, i.e. it's a fatal error if we can't create a JNI ref. Here: strongRef = JNI_FUNC_PTR(env,NewGlobalRef)(env, node->ref); /* * NewGlobalRef on a weak ref will return NULL if the weak * reference has been collected or if out of memory. * It never throws OOM. * We need to distinguish those two occurrences. */ if ((strongRef == NULL) && !isSameObject(env, node->ref, NULL)) { EXIT_ERROR(AGENT_ERROR_NULL_POINTER,"NewGlobalRef"); } So it seems appropriate to do the same thing if we fail to create a JNI weak ref. Also, as @plummercj mentioned, if we can't create a JNI ref, continuing the debug session seems rather pointless as we're about to go down anyway (the next allocation in the JVM will be fatal). ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From pliden at openjdk.java.net Mon Dec 7 11:12:20 2020 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 7 Dec 2020 11:12:20 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 05:10:34 GMT, David Holmes wrote: >> This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. >> >> The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. >> >> However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): >> >>> Going back to the spec, ObjectReference.disableCollection() says: >>> >>> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >>> >>> and >>> >>> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >>> >>> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >>> >>> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >>> >>> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). >> >> Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. >> >> However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. >> >> This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. >> >> Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: >> - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. >> - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. >> - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. >> - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. >> >> Testing: >> - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. > > src/jdk.jdwp.agent/share/native/libjdwp/commonRef.c line 586: > >> 584: jobject strongRef; >> 585: >> 586: strongRef = strengthenNode(env, node); > > This can just be one line. I was actually trying to carefully to follow the coding style currently used in this file/library. If you have a quick look at this file you'll see the pattern above in multiple places, where as combined declaration+assignment style isn't used. So while I personally agree about this style question, I also think following the style already present in a file has precedence over introducing a new style. Don't you agree? ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From pliden at openjdk.java.net Mon Dec 7 11:22:30 2020 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 7 Dec 2020 11:22:30 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2] In-Reply-To: References: Message-ID: > This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. > > The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. > > However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): > >> Going back to the spec, ObjectReference.disableCollection() says: >> >> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >> >> and >> >> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >> >> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >> >> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >> >> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). > > Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. > > However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. > > This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. > > Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: > - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. > - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. > - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. > - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. > > Testing: > - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. Per Liden has updated the pull request incrementally with one additional commit since the last revision: Add comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1595/files - new: https://git.openjdk.java.net/jdk/pull/1595/files/5b32d271..8fe1e52d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1595&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1595&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1595.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1595/head:pull/1595 PR: https://git.openjdk.java.net/jdk/pull/1595 From pliden at openjdk.java.net Mon Dec 7 11:22:31 2020 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 7 Dec 2020 11:22:31 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 07:41:46 GMT, Chris Plummer wrote: >> That was something I pointed out in the pre-review, and it has been addressed in `commonRef_pinAll/unpinAll`: >> >> `568 if (gdata->pinAllCount == 1) {` >> `618 if (gdata->pinAllCount == 0) {` > >> Okay. I would not have handled it at that level, but would have had > pinAll/unpinAll operate unconditionally, but the calls to those methods > being conditional based on the suspendAllCount. >> >>David > > Well, that's assuming `pinAll()` will only ever be used by by `suspendAll()`. One could imaging a future use, such as if `VirtualMachine.disableCollection()` were ever to be added. I was also thinking `pinAll()/unpinAll()` should stand on their own, and not implicitly depend/rely on `suspendAllCount`. As @plummercj says, one could imagine we want to use these functions in other contexts in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From david.holmes at oracle.com Mon Dec 7 11:52:47 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2020 21:52:47 +1000 Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: <33061a53-2f7e-8b8c-6688-bc43aff2fb42@oracle.com> On 7/12/2020 5:44 pm, Chris Plummer wrote: > On Mon, 7 Dec 2020 06:27:20 GMT, Chris Plummer wrote: > >>> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 1560: >>> >>>> 1558: * garbage collected while the VM is suspended. >>>> 1559: */ >>>> 1560: commonRef_pinAll(); >>> >>> Can we have multiple VM.suspend calls? The suspendAllCount seems to suggest that. In which case shouldn't we only pin on the 0->1 transition, and only unpin on the 1->0 transition? >> >> That was something I pointed out in the pre-review, and it has been addressed in `commonRef_pinAll/unpinAll`: >> >> `568 if (gdata->pinAllCount == 1) {` >> `618 if (gdata->pinAllCount == 0) {` > >> Okay. I would not have handled it at that level, but would have had > pinAll/unpinAll operate unconditionally, but the calls to those methods > being conditional based on the suspendAllCount. >> >> David > > Well, that's assuming `pinAll()` will only ever be used by by `suspendAll()`. One could imaging a future use, such as if `VirtualMachine.disableCollection()` were ever to be added. Not really. I consider pinAll should pin-all as the name implies. The question of when to pin should be handled by the caller of pinAll. If there were ever to be a second reason to pinAll then you would have to decide what semantics that has: does it maintain a count, or is it like thread suspension. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1595 > From david.holmes at oracle.com Mon Dec 7 12:11:59 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2020 22:11:59 +1000 Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: <430200ec-5fc2-e76e-06bb-9248990aa19f@oracle.com> On 7/12/2020 9:12 pm, Per Liden wrote: > On Mon, 7 Dec 2020 05:10:34 GMT, David Holmes wrote: >>> 584: jobject strongRef; >>> 585: >>> 586: strongRef = strengthenNode(env, node); >> >> This can just be one line. > > I was actually trying to carefully to follow the coding style currently used in this file/library. If you have a quick look at this file you'll see the pattern above in multiple places, where as combined declaration+assignment style isn't used. So while I personally agree about this style question, I also think following the style already present in a file has precedence over introducing a new style. Don't you agree? This file uses an archaic C-style, so while I agree it would be inappropriate to over modernise the new code, this particular example stuck out because even in archaic C there is no reason to split this onto two lines. I didn't go looking to see if this mimicked existing code. :) Keep it or change it as you see fit. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1595 > From pliden at openjdk.java.net Mon Dec 7 13:10:14 2020 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 7 Dec 2020 13:10:14 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 06:04:36 GMT, David Holmes wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment > > Overall seems okay. Some comments on tests as I think the existing test logic is quite confused in places. > > Thanks, > David > Not really. I consider pinAll should pin-all as the name implies. The question of when to pin should be handled by the caller of pinAll. If there were ever to be a second reason to pinAll then you would have to decide what semantics that has: does it maintain a count, or is it like thread suspension. I would say that would not be in spirit of how the rest of this library is designed, with regards to nesting of calls. For example, `pin()/unpin()`, `suspend()/resume()`, `createNode()/deleteNode()`, etc. All these functions supports nesting, so they might just up/down a counter, instead of doing exactly what their name implies. The new `pinAll()/unpinAll()` follow the same model, which, to me, feels like the natural thing to do here. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From rriggs at openjdk.java.net Mon Dec 7 15:08:12 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 7 Dec 2020 15:08:12 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> Message-ID: On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - Deprecate wrapper class constructors for removal (rriggs) > - Revise "value-based class" & apply to wrappers (dlsmith) > - Define & apply annotation jdk.internal.ValueBased (rriggs) > - Add 'lint' warning for @ValueBased classes (sadayapalam) > - Diagnose synchronization on @ValueBased classes (lfoltan) > > All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.) > > CSRs have also been completed or are nearly complete: > > - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation > - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class" > - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings > > Here's an overview of the files changed: > > - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes. > > - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance. > > - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation. > > - `src/java.management.rmi`: removing uses of wrapper class constructors. > > - `src/java.xml`: removing uses of wrapper class constructors. > > - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`. > > - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.) > > - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests > > - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics > > - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`. For the core libraries parts looks ok. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1636 From hseigel at openjdk.java.net Mon Dec 7 15:53:14 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 7 Dec 2020 15:53:14 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> Message-ID: On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - Deprecate wrapper class constructors for removal (rriggs) > - Revise "value-based class" & apply to wrappers (dlsmith) > - Define & apply annotation jdk.internal.ValueBased (rriggs) > - Add 'lint' warning for @ValueBased classes (sadayapalam) > - Diagnose synchronization on @ValueBased classes (lfoltan) > > All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.) > > CSRs have also been completed or are nearly complete: > > - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation > - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class" > - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings > > Here's an overview of the files changed: > > - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes. > > - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance. > > - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation. > > - `src/java.management.rmi`: removing uses of wrapper class constructors. > > - `src/java.xml`: removing uses of wrapper class constructors. > > - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`. > > - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.) > > - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests > > - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics > > - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`. The hotspot changes look good. In a future change, could you add additional classes, such as ProcessHandle to test TestSyncOnValueBasedClassEvent. Currently, it only tests primitive classes. ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1636 From lfoltan at openjdk.java.net Mon Dec 7 16:25:13 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Mon, 7 Dec 2020 16:25:13 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> Message-ID: On Mon, 7 Dec 2020 15:50:55 GMT, Harold Seigel wrote: >> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). >> >> Development has been broken into 5 tasks, each with its own JBS issue: >> - Deprecate wrapper class constructors for removal (rriggs) >> - Revise "value-based class" & apply to wrappers (dlsmith) >> - Define & apply annotation jdk.internal.ValueBased (rriggs) >> - Add 'lint' warning for @ValueBased classes (sadayapalam) >> - Diagnose synchronization on @ValueBased classes (lfoltan) >> >> All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.) >> >> CSRs have also been completed or are nearly complete: >> >> - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation >> - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class" >> - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings >> >> Here's an overview of the files changed: >> >> - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes. >> >> - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`. >> >> - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance. >> >> - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. >> >> - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. >> >> - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation. >> >> - `src/java.management.rmi`: removing uses of wrapper class constructors. >> >> - `src/java.xml`: removing uses of wrapper class constructors. >> >> - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`. >> >> - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.) >> >> - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests >> >> - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics >> >> - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`. > > The hotspot changes look good. In a future change, could you add additional classes, such as ProcessHandle to test TestSyncOnValueBasedClassEvent. Currently, it only tests primitive classes. @hseigel thank you for the review. I have created https://bugs.openjdk.java.net/browse/JDK-8257836 as an RFE to address additional testing. Lois ------------- PR: https://git.openjdk.java.net/jdk/pull/1636 From sgehwolf at openjdk.java.net Mon Dec 7 17:55:18 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 7 Dec 2020 17:55:18 GMT Subject: RFR: 8253797: [cgroups v2] Account for the fact that swap accounting is disabled on some systems Message-ID: This has been implemented for cgroups v1 with [JDK-8250984](https://bugs.openjdk.java.net/browse/JDK-8250984) but was lacking some tooling support for cgroups v2. With podman 2.2.0 release this could now be implemented (and tested). The idea is the same as for the cgroups v1 fix. If we've got no swap limit capabilities, return the memory limit only. Note that for cgroups v2 doesn't implement CgroupV1Metrics (obviously) and, thus, doesn't have `getMemoryAndSwapFailCount()` and `getMemoryAndSwapMaxUsage()`. Testing: - [x] submit testing - [x] container tests on cgroups v2 with swapaccount=0. - [x] Manual container tests involving `-XshowSettings:system` on cgroups v2. Thoughts? ------------- Commit messages: - 8253797: [cgroups v2] Account for the fact that swap accounting is disabled on some systems Changes: https://git.openjdk.java.net/jdk/pull/1672/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1672&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253797 Stats: 45 lines in 2 files changed: 24 ins; 1 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/1672.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1672/head:pull/1672 PR: https://git.openjdk.java.net/jdk/pull/1672 From kvn at openjdk.java.net Mon Dec 7 20:31:14 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 7 Dec 2020 20:31:14 GMT Subject: RFR: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() In-Reply-To: References: Message-ID: <6_fPBwlMcGHF7KghOrnbyRCxlNFHirfBS4mdZ2hc3dM=.7a101fd1-1295-4e4e-a86f-41ed9287b572@github.com> On Tue, 17 Nov 2020 12:53:48 GMT, Claes Redestad wrote: > This moves the mirroring of vmSymbols in ciSymbols to a separate file, ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol namespace). In a few places code is moved from .hpp to .cpp to facilitate this. > > With PCH disabled, this reduces total includes from 276949 to 276332 Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1256 From cjplummer at openjdk.java.net Mon Dec 7 20:33:20 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 7 Dec 2020 20:33:20 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 10:44:56 GMT, Per Liden wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java line 194: >> >>> 192: debuggee.resume(); >>> 193: checkDebugeeAnswer_instances(className, baseInstances); >>> 194: debuggee.suspend(); >> >> Before the changes in this PR, what was triggering the (expected) collection of the objects? > > @plummercj Nothing was explicitly triggering collection of these objects. However, the test is explicitly checking the number of objects "reachable for the purposes of garbage collection" in `checkDebugeeAnswer_instances()`. The tests sets up a breakpoint (with SUSPEND_ALL), which suspends the VM. Then it creates a number of new instances and expects these to be weakly reachable. However, with this change, suspending the VM will make all objects "reachable for the purposes of garbage collection". So, to let the test continue to create objects which are weakly reachable we need to first resume the VM, create the new instances, and then suspend it again. > > @dholmes-ora I have no idea why these tests are so different. The VM suspend is implicit in the breakpoint in this test, which is set up using SUSPEND_ALL. Ok, I understand now. `ReferenceType.instances()` only counts objects "reachable for the purposes of garbage collection". This change in behavior does concern me a little bit. I think the expectation is that the instances created by `ClassType.newInstance()` will not show up in this count unless `disableCollection()` is called, even when under a "suspend all". Clearly that's the expectation of this test, so the question is whether or not it is a reasonable expectation. Note that `ClassType.newInstance()` says nothing about the state of the returned object w.r.t. GC. It makes no mention of the need to call `disableCollection()` before resuming the VM, so I guess this gives us some wiggle room. However, the argument against the object being strongly reachable is comes from user asking the question "who has the strong reference that makes it strongly reachable?". It's not obvious to the user why there is a strong reference, and why it seemingly goes a way once `VM.resumeAll()` is called. I still think overall this is the right approach (baring a better approach being presented), but we may need to include some spec clarifications, and be prepared for some push back if this breaks anything. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From cjplummer at openjdk.java.net Mon Dec 7 21:05:16 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 7 Dec 2020 21:05:16 GMT Subject: RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 15:30:15 GMT, Richard Reingruber wrote: > This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused > timeout failures when graal is enabled. > > The fix is to avoid suspending all threads when a breakpoint is reached and then resume > just the main thread again. This pattern was used in the test case > EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal > threads remained suspended and, running with -Xbatch, the main thread waited > (with timeout) for completion of compile tasks. > The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only > to the main test thread and all explicit resume calls apply to all java threads. > > Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is > reduced from 30s to 10s. test/jdk/com/sun/jdi/EATests.java line 1274: > 1272: o = getLocalRef(env.targetMainThread.frame(0), XYVAL_NAME, "xy"); > 1273: } catch (Exception e) { > 1274: msg("The local variable xy is out of scope because we suspended at the wrong bci. Resume and try again! (" + (++retryCount) + ")"); Please move the increment of retryCount to before the msg() call for clarify. test/jdk/com/sun/jdi/EATests.java line 1275: > 1273: } catch (Exception e) { > 1274: msg("The local variable xy is out of scope because we suspended at the wrong bci. Resume and try again! (" + (++retryCount) + ")"); > 1275: env.vm().resume(); You are calling `VM.resume()` in a loop, yet you are suspending using `ThreadReference.suspend()`. Although the it looks like this will work, it seems that calling `ThreadReference.resume()` would be more appropriate. ------------- PR: https://git.openjdk.java.net/jdk/pull/1625 From dholmes at openjdk.java.net Mon Dec 7 22:09:14 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Dec 2020 22:09:14 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 11:22:30 GMT, Per Liden wrote: >> This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. >> >> The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. >> >> However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): >> >>> Going back to the spec, ObjectReference.disableCollection() says: >>> >>> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >>> >>> and >>> >>> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >>> >>> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >>> >>> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >>> >>> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). >> >> Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. >> >> However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. >> >> This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. >> >> Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: >> - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. >> - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. >> - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. >> - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. >> >> Testing: >> - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Add comment I still have some reservations about the logic in some of the tests now (ie using disableCollection whilst the VM is suspended and reenabling also whilst suspended) but the logic was unclear in the first place. If necessary follow up cleanup issues could be filed here. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1595 From dholmes at openjdk.java.net Mon Dec 7 22:09:15 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Dec 2020 22:09:15 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2] In-Reply-To: References: <-2Yx99rM6jO7OHIzIlaHfdeojwgwwl7QthEqINqxiu4=.ae8922de-ea23-47c6-adff-3618cecd7eaf@github.com> <_mg_tfWiVdggsrpKEDFeFAR1-22yUsy-tTe0foBDdC4=.191dc88a-df48-4127-805d-62fba59d2750@github.com> Message-ID: On Mon, 7 Dec 2020 10:57:08 GMT, Per Liden wrote: >> I agree a fatal error here seems excessive. Simply maintaining the strong ref seems reasonable. > > I was trying to mimic what we already do in `strengthenNode()`, i.e. it's a fatal error if we can't create a JNI ref. Here: > > strongRef = JNI_FUNC_PTR(env,NewGlobalRef)(env, node->ref); > /* > * NewGlobalRef on a weak ref will return NULL if the weak > * reference has been collected or if out of memory. > * It never throws OOM. > * We need to distinguish those two occurrences. > */ > if ((strongRef == NULL) && !isSameObject(env, node->ref, NULL)) { > EXIT_ERROR(AGENT_ERROR_NULL_POINTER,"NewGlobalRef"); > } > > So it seems appropriate to do the same thing if we fail to create a JNI weak ref. Also, as @plummercj mentioned, if we can't create a JNI ref, continuing the debug session seems rather pointless as we're about to go down anyway (the next allocation in the JVM will be fatal). Okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From dholmes at openjdk.java.net Mon Dec 7 22:17:19 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Dec 2020 22:17:19 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 20:30:07 GMT, Chris Plummer wrote: >> @plummercj Nothing was explicitly triggering collection of these objects. However, the test is explicitly checking the number of objects "reachable for the purposes of garbage collection" in `checkDebugeeAnswer_instances()`. The tests sets up a breakpoint (with SUSPEND_ALL), which suspends the VM. Then it creates a number of new instances and expects these to be weakly reachable. However, with this change, suspending the VM will make all objects "reachable for the purposes of garbage collection". So, to let the test continue to create objects which are weakly reachable we need to first resume the VM, create the new instances, and then suspend it again. >> >> @dholmes-ora I have no idea why these tests are so different. The VM suspend is implicit in the breakpoint in this test, which is set up using SUSPEND_ALL. > > Ok, I understand now. `ReferenceType.instances()` only counts objects "reachable for the purposes of garbage collection". This change in behavior does concern me a little bit. I think the expectation is that the instances created by `ClassType.newInstance()` will not show up in this count unless `disableCollection()` is called, even when under a "suspend all". Clearly that's the expectation of this test, so the question is whether or not it is a reasonable expectation. > > Note that `ClassType.newInstance()` says nothing about the state of the returned object w.r.t. GC. It makes no mention of the need to call `disableCollection()` before resuming the VM, so I guess this gives us some wiggle room. However, the argument against the object being strongly reachable is comes from user asking the question "who has the strong reference that makes it strongly reachable?". It's not obvious to the user why there is a strong reference, and why it seemingly goes a way once `VM.resumeAll()` is called. > > I still think overall this is the right approach (baring a better approach being presented), but we may need to include some spec clarifications, and be prepared for some push back if this breaks anything. I don't follow your reasoning here Chris. All ObjectReferences can be GC'd at any time unless GC has been disallowed. So a reference create via newInstance is no different to any other reference. If it is currently reachable then instances() should return it. Are you treating "reachable for the purposes of garbage collection" as-if it said "strongly reachable"? It doesn't so I think you are reading too much into this. I think there is a lot of flexibility in this API in terms of what it may return regarding weak references. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From cjplummer at openjdk.java.net Mon Dec 7 23:37:16 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 7 Dec 2020 23:37:16 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2] In-Reply-To: References: Message-ID: <_W4lIt9BSy6C6rbh9fR97LKXaL2n6DOkJDCOoaoqzYw=.7c887352-cc1e-4b78-8436-e720ed8d656a@github.com> On Mon, 7 Dec 2020 22:14:28 GMT, David Holmes wrote: >> Ok, I understand now. `ReferenceType.instances()` only counts objects "reachable for the purposes of garbage collection". This change in behavior does concern me a little bit. I think the expectation is that the instances created by `ClassType.newInstance()` will not show up in this count unless `disableCollection()` is called, even when under a "suspend all". Clearly that's the expectation of this test, so the question is whether or not it is a reasonable expectation. >> >> Note that `ClassType.newInstance()` says nothing about the state of the returned object w.r.t. GC. It makes no mention of the need to call `disableCollection()` before resuming the VM, so I guess this gives us some wiggle room. However, the argument against the object being strongly reachable is comes from user asking the question "who has the strong reference that makes it strongly reachable?". It's not obvious to the user why there is a strong reference, and why it seemingly goes a way once `VM.resumeAll()` is called. >> >> I still think overall this is the right approach (baring a better approach being presented), but we may need to include some spec clarifications, and be prepared for some push back if this breaks anything. > > I don't follow your reasoning here Chris. All ObjectReferences can be GC'd at any time unless GC has been disallowed. So a reference create via newInstance is no different to any other reference. If it is currently reachable then instances() should return it. Are you treating "reachable for the purposes of garbage collection" as-if it said "strongly reachable"? It doesn't so I think you are reading too much into this. I think there is a lot of flexibility in this API in terms of what it may return regarding weak references. I read "reachable for the purposes of garbage collection" as not including objects reachable only via weak reference. So if the only reference to an object is a weak reference, which is normally what you have after calling `ClassType.newInstance()`, then the object is not considered reachable. At the very least, his is how `ReferenceType.instances()` is implemented, and is based on JVMTI [FollowReferences](https://docs.oracle.com/en/java/javase/14/docs/specs/jvmti.html#FollowReferences)(). So given that, the expectation would be that an object returned `ClassType.newInstance()` would not be counted by `ReferenceType.instances()` unless something is done to add a strong reference to the object, such as calling `ObjectReference.disableCollection()`. Now with Per's changes a strong reference is also created with doing a VM.suspend(). The test doesn't expect this behavior, and it's understandable why. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From iklam at openjdk.java.net Tue Dec 8 03:55:13 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Dec 2020 03:55:13 GMT Subject: RFR: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 12:53:48 GMT, Claes Redestad wrote: > This moves the mirroring of vmSymbols in ciSymbols to a separate file, ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol namespace). In a few places code is moved from .hpp to .cpp to facilitate this. > > With PCH disabled, this reduces total includes from 276949 to 276332 Changes requested by iklam (Reviewer). src/hotspot/share/ci/bcEscapeAnalyzer.hpp line 102: > 100: void compute_escape_info(); > 101: vmIntrinsicID known_intrinsic(); > 102: void compute_escape_for_intrinsic(vmIntrinsicID iid); I think the use of vmIntrinsics::ID in bcEscapeAnalyzer.cpp should also be changed to vmIntrinsicID for consistency, even though they are the same type. (The same for other hpp files such as ciMethod.hpp) src/hotspot/share/opto/library_call.cpp line 27: > 25: #include "precompiled.hpp" > 26: #include "asm/macroAssembler.hpp" > 27: #include "ci/ciSymbols.hpp" This file doesn't seem to use the exports from ciSymbols.hpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/1256 From sspitsyn at openjdk.java.net Tue Dec 8 10:01:19 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 8 Dec 2020 10:01:19 GMT Subject: RFR: JDK-8245446: =?UTF-8?B?dm1UZXN0YmFzZS9uc2svanZtdGkvUmVkZWZpbmVDbGFzc2VzL1N0cmVzc1JlZGVmaW5lL1Rlc3REZXNj4oCm?= Message-ID: The StressRedefine.java (base for redefine stress tests) defines 3 important constants: private static int staticMethodCallersNumber = 10; private static int nonstaticMethodCallersNumber = 10; private static int redefiningThreadsNumber = 40; The 1st is number of threads to call a static method from constantly redefined class. The 2nd is number of threads to call am instance method from constantly redefined class. The 3rd is number of threads to redefine the target class. The redefiningThreadsNumber=40 is unreasonably big for the StressRedefine test, and there is no chance with -Xcomp for one of the methods above to get resolved without a class redefinition. So, after 100 of non-successfull attempts we hit the guarantee in the open/src/hotspot/share/interpreter/interpreterRuntime.cpp:879 guarantee((retry_count++ < 100)) failed: Could not resolve to latest version of redefined method To avoid it, the test StressRedefine/TestDescription.java is tweaked to have redefiningThreadsNumber=4. The test StressRedefineWithoutBytecodeCorruption is worse as it fails even with redefiningThreadsNumber=1. So, a require is added to exclude the test with the -Xcomp flag. ------------- Commit messages: - 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently Changes: https://git.openjdk.java.net/jdk/pull/1692/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1692&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245446 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1692.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1692/head:pull/1692 PR: https://git.openjdk.java.net/jdk/pull/1692 From sspitsyn at openjdk.java.net Tue Dec 8 11:46:36 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 8 Dec 2020 11:46:36 GMT Subject: RFR: 8165276: Spec states that invoke the premain method in an agent =?UTF-8?B?Y2zigKY=?= Message-ID: This change have been already reviewed by Mandy, Alan and David. Now, the PR approval is needed. The push was postponed because the CSR was not approved at that time (it is now): https://bugs.openjdk.java.net/browse/JDK-8248189 Investigation of existing popular java agents was requested by Joe. ---------- The java.lang.instrument spec: https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html Summary: The java.lang.instrument spec clearly states: "The agent class must implement a public static premain method similar in principle to the main application entry point." Current implementation of sun/instrument/InstrumentationImpl.java allows the premain method be non-public which violates the spec. This fix aligns the implementation with the spec. Testing: A mach5 run of jdk_instrument tests is in progress. ------------- Commit messages: - JDK-8165276 Spec states that invoke the premain method in an agent class if it's public but implementation differs Changes: https://git.openjdk.java.net/jdk/pull/1694/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8165276 Stats: 356 lines in 26 files changed: 251 ins; 56 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/1694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1694/head:pull/1694 PR: https://git.openjdk.java.net/jdk/pull/1694 From redestad at openjdk.java.net Tue Dec 8 13:22:22 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Dec 2020 13:22:22 GMT Subject: RFR: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() [v2] In-Reply-To: References: Message-ID: <6vBVdKB9tom6dPkNDPpDe9fOmnIsXHhqAczxVZeDNJ0=.64c95d40-f532-441e-9a18-e5512d9eaef7@github.com> > This moves the mirroring of vmSymbols in ciSymbols to a separate file, ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol namespace). In a few places code is moved from .hpp to .cpp to facilitate this. > > With PCH disabled, this reduces total includes from 276949 to 276332 Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge branch 'master' into ciSymbols - @iklam reviews, additional cleanup - remote merge - Prepare for 1237 changes - Adjust includes after vmIntrinsic changes - Merge master - Outline is_call_site_target to remove include from ciField.hpp - Outline is_autobox_cache to remove include from ciField.hpp - Merge branch 'master' into ciSymbols - Fix bad definition - ... and 3 more: https://git.openjdk.java.net/jdk/compare/d0c52651...b8c485b9 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1256/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1256&range=01 Stats: 182 lines in 32 files changed: 101 ins; 30 del; 51 mod Patch: https://git.openjdk.java.net/jdk/pull/1256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1256/head:pull/1256 PR: https://git.openjdk.java.net/jdk/pull/1256 From rrich at openjdk.java.net Tue Dec 8 13:45:25 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 8 Dec 2020 13:45:25 GMT Subject: RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads [v2] In-Reply-To: References: Message-ID: <49rloCqa5b3ySoHjV3dRj9ujvcWEAN1_XijhC88f2fQ=.b84a531b-3a73-4639-9284-ee8c9b45bbca@github.com> > This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused > timeout failures when graal is enabled. > > The fix is to avoid suspending all threads when a breakpoint is reached and then resume > just the main thread again. This pattern was used in the test case > EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal > threads remained suspended and, running with -Xbatch, the main thread waited > (with timeout) for completion of compile tasks. > The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only > to the main test thread and all explicit resume calls apply to all java threads. > > Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is > reduced from 30s to 10s. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Changes based on Chris Plummer's feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1625/files - new: https://git.openjdk.java.net/jdk/pull/1625/files/39f5a1e9..8e4b301f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1625&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1625&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1625.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1625/head:pull/1625 PR: https://git.openjdk.java.net/jdk/pull/1625 From rrich at openjdk.java.net Tue Dec 8 13:45:26 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 8 Dec 2020 13:45:26 GMT Subject: RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 20:48:16 GMT, Chris Plummer wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes based on Chris Plummer's feedback. > > test/jdk/com/sun/jdi/EATests.java line 1274: > >> 1272: o = getLocalRef(env.targetMainThread.frame(0), XYVAL_NAME, "xy"); >> 1273: } catch (Exception e) { >> 1274: msg("The local variable xy is out of scope because we suspended at the wrong bci. Resume and try again! (" + (++retryCount) + ")"); > > Please move the increment of retryCount to before the msg() call for clarify. Sure. > test/jdk/com/sun/jdi/EATests.java line 1275: > >> 1273: } catch (Exception e) { >> 1274: msg("The local variable xy is out of scope because we suspended at the wrong bci. Resume and try again! (" + (++retryCount) + ")"); >> 1275: env.vm().resume(); > > You are calling `VM.resume()` in a loop, yet you are suspending using `ThreadReference.suspend()`. Although the it looks like this will work, it seems that calling `ThreadReference.resume()` would be more appropriate. Ok, that's probably better. (I wanted to follow the principle to always resume _all_ threads) ------------- PR: https://git.openjdk.java.net/jdk/pull/1625 From rrich at openjdk.java.net Tue Dec 8 14:00:25 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 8 Dec 2020 14:00:25 GMT Subject: RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads [v3] In-Reply-To: References: Message-ID: <7gm7Hc5kPM8P71GeIflDtxunU1WF8RtKQZ5Djz5plRI=.d4e646d8-a3b4-4d56-97d3-5c34aba1ed39@github.com> > This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused > timeout failures when graal is enabled. > > The fix is to avoid suspending all threads when a breakpoint is reached and then resume > just the main thread again. This pattern was used in the test case > EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal > threads remained suspended and, running with -Xbatch, the main thread waited > (with timeout) for completion of compile tasks. > The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only > to the main test thread and all explicit resume calls apply to all java threads. > > Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is > reduced from 30s to 10s. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Only main thread needs to be resumed in EARelockingObjectCurrentlyWaitingOn. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1625/files - new: https://git.openjdk.java.net/jdk/pull/1625/files/8e4b301f..ce12877f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1625&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1625&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1625.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1625/head:pull/1625 PR: https://git.openjdk.java.net/jdk/pull/1625 From pliden at openjdk.java.net Tue Dec 8 14:07:14 2020 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 8 Dec 2020 14:07:14 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2] In-Reply-To: <_W4lIt9BSy6C6rbh9fR97LKXaL2n6DOkJDCOoaoqzYw=.7c887352-cc1e-4b78-8436-e720ed8d656a@github.com> References: <_W4lIt9BSy6C6rbh9fR97LKXaL2n6DOkJDCOoaoqzYw=.7c887352-cc1e-4b78-8436-e720ed8d656a@github.com> Message-ID: On Mon, 7 Dec 2020 23:34:00 GMT, Chris Plummer wrote: >> I don't follow your reasoning here Chris. All ObjectReferences can be GC'd at any time unless GC has been disallowed. So a reference create via newInstance is no different to any other reference. If it is currently reachable then instances() should return it. Are you treating "reachable for the purposes of garbage collection" as-if it said "strongly reachable"? It doesn't so I think you are reading too much into this. I think there is a lot of flexibility in this API in terms of what it may return regarding weak references. > > I read "reachable for the purposes of garbage collection" as not including objects reachable only via weak reference. So if the only reference to an object is a weak reference, which is normally what you have after calling `ClassType.newInstance()`, then the object is not considered reachable. At the very least, his is how `ReferenceType.instances()` is implemented, and is based on JVMTI [FollowReferences](https://docs.oracle.com/en/java/javase/14/docs/specs/jvmti.html#FollowReferences)(). > > So given that, the expectation would be that an object returned `ClassType.newInstance()` would not be counted by `ReferenceType.instances()` unless something is done to add a strong reference to the object, such as calling `ObjectReference.disableCollection()`. Now with Per's changes a strong reference is also created with doing a VM.suspend(). The test doesn't expect this behavior, and it's understandable why. I think we're still within what the spec says, given that the wording is so loose. But it's hard to tell if this change will be problematic for some use case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From redestad at openjdk.java.net Tue Dec 8 16:22:44 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Dec 2020 16:22:44 GMT Subject: RFR: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() [v3] In-Reply-To: References: Message-ID: > This moves the mirroring of vmSymbols in ciSymbols to a separate file, ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol namespace). In a few places code is moved from .hpp to .cpp to facilitate this. > > With PCH disabled, this reduces total includes from 276949 to 276332 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: ciMethod needs classfile/vmIntrinsics.hpp after 8252505 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1256/files - new: https://git.openjdk.java.net/jdk/pull/1256/files/b8c485b9..2144b16f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1256&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1256&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1256/head:pull/1256 PR: https://git.openjdk.java.net/jdk/pull/1256 From iklam at openjdk.java.net Tue Dec 8 17:23:17 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Dec 2020 17:23:17 GMT Subject: RFR: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() [v3] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 16:22:44 GMT, Claes Redestad wrote: >> This moves the mirroring of vmSymbols in ciSymbols to a separate file, ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol namespace). In a few places code is moved from .hpp to .cpp to facilitate this. >> >> With PCH disabled, this reduces total includes from 276949 to 276332 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > ciMethod needs classfile/vmIntrinsics.hpp after 8252505 Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1256 From cjplummer at openjdk.java.net Tue Dec 8 19:25:41 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 8 Dec 2020 19:25:41 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2] In-Reply-To: References: <_W4lIt9BSy6C6rbh9fR97LKXaL2n6DOkJDCOoaoqzYw=.7c887352-cc1e-4b78-8436-e720ed8d656a@github.com> Message-ID: On Tue, 8 Dec 2020 14:04:33 GMT, Per Liden wrote: >> I read "reachable for the purposes of garbage collection" as not including objects reachable only via weak reference. So if the only reference to an object is a weak reference, which is normally what you have after calling `ClassType.newInstance()`, then the object is not considered reachable. At the very least, his is how `ReferenceType.instances()` is implemented, and is based on JVMTI [FollowReferences](https://docs.oracle.com/en/java/javase/14/docs/specs/jvmti.html#FollowReferences)(). >> >> So given that, the expectation would be that an object returned `ClassType.newInstance()` would not be counted by `ReferenceType.instances()` unless something is done to add a strong reference to the object, such as calling `ObjectReference.disableCollection()`. Now with Per's changes a strong reference is also created with doing a VM.suspend(). The test doesn't expect this behavior, and it's understandable why. > > I think we're still within what the spec says, given that the wording is so loose. But it's hard to tell if this change will be problematic for some use case. I'm ok with making the change and then seeing if there is any fallout from it. My guess is there won't be. I do think there is a need to cleanup the JDI and JDWP specs in a few areas w.r.t. object liveness. Another CR can be filed for that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From cjplummer at openjdk.java.net Tue Dec 8 19:28:38 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 8 Dec 2020 19:28:38 GMT Subject: RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads [v3] In-Reply-To: <7gm7Hc5kPM8P71GeIflDtxunU1WF8RtKQZ5Djz5plRI=.d4e646d8-a3b4-4d56-97d3-5c34aba1ed39@github.com> References: <7gm7Hc5kPM8P71GeIflDtxunU1WF8RtKQZ5Djz5plRI=.d4e646d8-a3b4-4d56-97d3-5c34aba1ed39@github.com> Message-ID: On Tue, 8 Dec 2020 14:00:25 GMT, Richard Reingruber wrote: >> This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused >> timeout failures when graal is enabled. >> >> The fix is to avoid suspending all threads when a breakpoint is reached and then resume >> just the main thread again. This pattern was used in the test case >> EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal >> threads remained suspended and, running with -Xbatch, the main thread waited >> (with timeout) for completion of compile tasks. >> The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only >> to the main test thread and all explicit resume calls apply to all java threads. >> >> Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is >> reduced from 30s to 10s. > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Only main thread needs to be resumed in EARelockingObjectCurrentlyWaitingOn. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1625 From alanb at openjdk.java.net Tue Dec 8 19:31:44 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Dec 2020 19:31:44 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 11:41:33 GMT, Serguei Spitsyn wrote: > This change have been already reviewed by Mandy, Alan and David. > Now, the PR approval is needed. > The push was postponed because the CSR was not approved at that time (it is now): > https://bugs.openjdk.java.net/browse/JDK-8248189 > Investigation of existing popular java agents was requested by Joe. > ---------- > > The java.lang.instrument spec: > https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html > > Summary: > The java.lang.instrument spec clearly states: > "The agent class must implement a public static premain method > similar in principle to the main application entry point." > Current implementation of sun/instrument/InstrumentationImpl.java > allows the premain method be non-public which violates the spec. > This fix aligns the implementation with the spec. > > Testing: > A mach5 run of jdk_instrument tests is in progress. src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java line 501: > 499: String msg = "method " + classname + "." + methodname + " must be declared public"; > 500: throw new IllegalAccessException(msg); > 501: } If canAccess fails then it means that javaAgentClass is not public or the premain method is not public. The invoke will fail but I agree eat explicit canAccess check means we get finer control on the exception message. (I can't help feeling that we should do a bit more cleanup here and not use getDeclaredMethod or be concerned with inheritance. This is because the Premain-Class is meant to specify the agent class. Also can't have a public static premain in super class and a non-public static premain in a sub-class). ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From cjplummer at openjdk.java.net Tue Dec 8 19:33:38 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 8 Dec 2020 19:33:38 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 22:05:04 GMT, David Holmes wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment > > I still have some reservations about the logic in some of the tests now (ie using disableCollection whilst the VM is suspended and reenabling also whilst suspended) but the logic was unclear in the first place. If necessary follow up cleanup issues could be filed here. > > Thanks, > David A number of files need copyright updates. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From cjplummer at openjdk.java.net Tue Dec 8 19:43:33 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 8 Dec 2020 19:43:33 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 11:41:33 GMT, Serguei Spitsyn wrote: > This change have been already reviewed by Mandy, Sundar, Alan and David. > Now, the PR approval is needed. Can you provide a link to the discussion? I'm mostly curious if there was some discussion as to why Instrument purposefully allowed non-public premain methods: // the premain method should not be required to be public, 508 // make it accessible so we can call it 509 // Note: The spec says the following: 510 // The agent class must implement a public static premain method... 511 setAccessible(m, true);``` ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From alanb at openjdk.java.net Tue Dec 8 19:54:34 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Dec 2020 19:54:34 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 19:40:32 GMT, Chris Plummer wrote: >> This change have been already reviewed by Mandy, Sundar, Alan and David. >> Now, the PR approval is needed. >> The push was postponed because the CSR was not approved at that time (it is now): >> https://bugs.openjdk.java.net/browse/JDK-8248189 >> Investigation of existing popular java agents was requested by Joe. >> ---------- >> >> The java.lang.instrument spec: >> https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html >> >> Summary: >> The java.lang.instrument spec clearly states: >> "The agent class must implement a public static premain method >> similar in principle to the main application entry point." >> Current implementation of sun/instrument/InstrumentationImpl.java >> allows the premain method be non-public which violates the spec. >> This fix aligns the implementation with the spec. >> >> Testing: >> A mach5 run of jdk_instrument tests is in progress. > >> This change have been already reviewed by Mandy, Sundar, Alan and David. >> Now, the PR approval is needed. > > Can you provide a link to the discussion? I'm mostly curious if there was some discussion as to why Instrument purposefully allowed non-public premain methods: > > // the premain method should not be required to be public, > 508 // make it accessible so we can call it > 509 // Note: The spec says the following: > 510 // The agent class must implement a public static premain method... > 511 setAccessible(m, true);``` All the discussion is in the bug and CSR: https://bugs.openjdk.java.net/browse/JDK-8165276 https://bugs.openjdk.java.net/browse/JDK-8248189 We messed up in JDK-5070281 (JDK 6) and it came to light in JDK 9 when auditing the use of setAccessible in the JDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From rrich at openjdk.java.net Tue Dec 8 19:56:35 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 8 Dec 2020 19:56:35 GMT Subject: RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads [v3] In-Reply-To: References: <7gm7Hc5kPM8P71GeIflDtxunU1WF8RtKQZ5Djz5plRI=.d4e646d8-a3b4-4d56-97d3-5c34aba1ed39@github.com> Message-ID: On Tue, 8 Dec 2020 19:25:30 GMT, Chris Plummer wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Only main thread needs to be resumed in EARelockingObjectCurrentlyWaitingOn. > > Marked as reviewed by cjplummer (Reviewer). Thanks for the review @plummercj ------------- PR: https://git.openjdk.java.net/jdk/pull/1625 From sspitsyn at openjdk.java.net Tue Dec 8 20:08:41 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 8 Dec 2020 20:08:41 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 19:51:48 GMT, Alan Bateman wrote: >>> This change have been already reviewed by Mandy, Sundar, Alan and David. >>> Now, the PR approval is needed. >> >> Can you provide a link to the discussion? I'm mostly curious if there was some discussion as to why Instrument purposefully allowed non-public premain methods: >> >> // the premain method should not be required to be public, >> 508 // make it accessible so we can call it >> 509 // Note: The spec says the following: >> 510 // The agent class must implement a public static premain method... >> 511 setAccessible(m, true);``` > > All the discussion is in the bug and CSR: > https://bugs.openjdk.java.net/browse/JDK-8165276 > https://bugs.openjdk.java.net/browse/JDK-8248189 > We messed up in JDK-5070281 (JDK 6) and it came to light in JDK 9 when auditing the use of setAccessible in the JDK. Chris, I've added link to the jdk 15 review thread to the PR description. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From cjplummer at openjdk.java.net Tue Dec 8 21:09:35 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 8 Dec 2020 21:09:35 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 09:53:36 GMT, Serguei Spitsyn wrote: > The StressRedefine.java (base for redefine stress tests) defines 3 important constants: > private static int staticMethodCallersNumber = 10; > private static int nonstaticMethodCallersNumber = 10; > private static int redefiningThreadsNumber = 40; > > The 1st is number of threads to call a static method from constantly redefined class. > The 2nd is number of threads to call am instance method from constantly redefined class. > The 3rd is number of threads to redefine the target class. > The redefiningThreadsNumber=40 is unreasonably big for the StressRedefine test, and there is no chance with -Xcomp for one of the methods above to get resolved without a class redefinition. So, after 100 of non-successfull attempts we hit the guarantee in the open/src/hotspot/share/interpreter/interpreterRuntime.cpp:879 > guarantee((retry_count++ < 100)) failed: Could not resolve to latest version of redefined method > To avoid it, the test StressRedefine/TestDescription.java is tweaked to have redefiningThreadsNumber=4. > > The test StressRedefineWithoutBytecodeCorruption is worse as it fails even with redefiningThreadsNumber=1. So, a require is added to exclude the test with the -Xcomp flag. Marked as reviewed by cjplummer (Reviewer). test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java line 39: > 37: * nsk.jvmti.RedefineClasses.StressRedefine > 38: * ./bin > 39: * -redefiningThreadsNumber 4 So `-redefiningThreadsNumber` has always been an allowed option to `StressRedefine`, yet this is the first time it's ever been used? Not an issue. Just a bit odd that the option was already there for you to use. ------------- PR: https://git.openjdk.java.net/jdk/pull/1692 From lmesnik at openjdk.java.net Tue Dec 8 21:21:38 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 8 Dec 2020 21:21:38 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 09:53:36 GMT, Serguei Spitsyn wrote: > The StressRedefine.java (base for redefine stress tests) defines 3 important constants: > private static int staticMethodCallersNumber = 10; > private static int nonstaticMethodCallersNumber = 10; > private static int redefiningThreadsNumber = 40; > > The 1st is number of threads to call a static method from constantly redefined class. > The 2nd is number of threads to call am instance method from constantly redefined class. > The 3rd is number of threads to redefine the target class. > The redefiningThreadsNumber=40 is unreasonably big for the StressRedefine test, and there is no chance with -Xcomp for one of the methods above to get resolved without a class redefinition. So, after 100 of non-successfull attempts we hit the guarantee in the open/src/hotspot/share/interpreter/interpreterRuntime.cpp:879 > guarantee((retry_count++ < 100)) failed: Could not resolve to latest version of redefined method > To avoid it, the test StressRedefine/TestDescription.java is tweaked to have redefiningThreadsNumber=4. > > The test StressRedefineWithoutBytecodeCorruption is worse as it fails even with redefiningThreadsNumber=1. So, a require is added to exclude the test with the -Xcomp flag. looks good. ------------- Marked as reviewed by lmesnik (Committer). PR: https://git.openjdk.java.net/jdk/pull/1692 From sspitsyn at openjdk.java.net Tue Dec 8 21:21:39 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 8 Dec 2020 21:21:39 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: <0kp8X1ijfeyiT0_JXjPBiGXE_PL2iVLIHl0qryeVlpA=.c9996922-ec76-4cac-9f68-2484933f14b0@github.com> On Tue, 8 Dec 2020 21:01:07 GMT, Chris Plummer wrote: >> The StressRedefine.java (base for redefine stress tests) defines 3 important constants: >> private static int staticMethodCallersNumber = 10; >> private static int nonstaticMethodCallersNumber = 10; >> private static int redefiningThreadsNumber = 40; >> >> The 1st is number of threads to call a static method from constantly redefined class. >> The 2nd is number of threads to call am instance method from constantly redefined class. >> The 3rd is number of threads to redefine the target class. >> The redefiningThreadsNumber=40 is unreasonably big for the StressRedefine test, and there is no chance with -Xcomp for one of the methods above to get resolved without a class redefinition. So, after 100 of non-successfull attempts we hit the guarantee in the open/src/hotspot/share/interpreter/interpreterRuntime.cpp:879 >> guarantee((retry_count++ < 100)) failed: Could not resolve to latest version of redefined method >> To avoid it, the test StressRedefine/TestDescription.java is tweaked to have redefiningThreadsNumber=4. >> >> The test StressRedefineWithoutBytecodeCorruption is worse as it fails even with redefiningThreadsNumber=1. So, a require is added to exclude the test with the -Xcomp flag. > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java line 39: > >> 37: * nsk.jvmti.RedefineClasses.StressRedefine >> 38: * ./bin >> 39: * -redefiningThreadsNumber 4 > > So `-redefiningThreadsNumber` has always been an allowed option to `StressRedefine`, yet this is the first time it's ever been used? Not an issue. Just a bit odd that the option was already there for you to use. The StressRedefine class seems to be designed as a base for more advanced stress testing. My guess is there was a plan to add more test cases to it but it did not happen. ------------- PR: https://git.openjdk.java.net/jdk/pull/1692 From pliden at openjdk.java.net Tue Dec 8 21:29:51 2020 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 8 Dec 2020 21:29:51 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v3] In-Reply-To: References: Message-ID: <-7O_R4ZOVdbm3fvNcMb3xRiIQ6i8fGpTeHYtkvFZnvY=.2e67bf61-3df2-400c-9b28-c9def5bf7d13@github.com> > This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. > > The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. > > However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): > >> Going back to the spec, ObjectReference.disableCollection() says: >> >> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >> >> and >> >> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >> >> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >> >> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >> >> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). > > Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. > > However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. > > This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. > > Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: > - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. > - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. > - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. > - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. > > Testing: > - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. Per Liden has updated the pull request incrementally with one additional commit since the last revision: Fix copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1595/files - new: https://git.openjdk.java.net/jdk/pull/1595/files/8fe1e52d..55cd2462 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1595&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1595&range=01-02 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1595.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1595/head:pull/1595 PR: https://git.openjdk.java.net/jdk/pull/1595 From pliden at openjdk.java.net Tue Dec 8 21:29:51 2020 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 8 Dec 2020 21:29:51 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 19:30:44 GMT, Chris Plummer wrote: >> I still have some reservations about the logic in some of the tests now (ie using disableCollection whilst the VM is suspended and reenabling also whilst suspended) but the logic was unclear in the first place. If necessary follow up cleanup issues could be filed here. >> >> Thanks, >> David > > A number of files need copyright updates. @plummercj Copyright fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From pliden at openjdk.java.net Tue Dec 8 21:44:35 2020 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 8 Dec 2020 21:44:35 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v3] In-Reply-To: References: <_W4lIt9BSy6C6rbh9fR97LKXaL2n6DOkJDCOoaoqzYw=.7c887352-cc1e-4b78-8436-e720ed8d656a@github.com> Message-ID: On Tue, 8 Dec 2020 19:22:41 GMT, Chris Plummer wrote: >> I think we're still within what the spec says, given that the wording is so loose. But it's hard to tell if this change will be problematic for some use case. > > I'm ok with making the change and then seeing if there is any fallout from it. My guess is there won't be. I do think there is a need to cleanup the JDI and JDWP specs in a few areas w.r.t. object liveness. Another CR can be filed for that. I filed https://bugs.openjdk.java.net/browse/JDK-8257921. Feel free to extend/improve the description. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From dholmes at openjdk.java.net Tue Dec 8 22:31:36 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Dec 2020 22:31:36 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v3] In-Reply-To: <-7O_R4ZOVdbm3fvNcMb3xRiIQ6i8fGpTeHYtkvFZnvY=.2e67bf61-3df2-400c-9b28-c9def5bf7d13@github.com> References: <-7O_R4ZOVdbm3fvNcMb3xRiIQ6i8fGpTeHYtkvFZnvY=.2e67bf61-3df2-400c-9b28-c9def5bf7d13@github.com> Message-ID: On Tue, 8 Dec 2020 21:29:51 GMT, Per Liden wrote: >> This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. >> >> The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. >> >> However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): >> >>> Going back to the spec, ObjectReference.disableCollection() says: >>> >>> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >>> >>> and >>> >>> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >>> >>> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >>> >>> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >>> >>> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). >> >> Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. >> >> However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. >> >> This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. >> >> Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: >> - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. >> - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. >> - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. >> - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. >> >> Testing: >> - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From cjplummer at openjdk.java.net Tue Dec 8 22:39:38 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 8 Dec 2020 22:39:38 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v3] In-Reply-To: <-7O_R4ZOVdbm3fvNcMb3xRiIQ6i8fGpTeHYtkvFZnvY=.2e67bf61-3df2-400c-9b28-c9def5bf7d13@github.com> References: <-7O_R4ZOVdbm3fvNcMb3xRiIQ6i8fGpTeHYtkvFZnvY=.2e67bf61-3df2-400c-9b28-c9def5bf7d13@github.com> Message-ID: <3r_aQU9A4Vu5QCcVxk4xpb2rGZoA7BjPGSpRz3OEg2c=.4165ab02-964f-4873-a8fc-7d36b95357a6@github.com> On Tue, 8 Dec 2020 21:29:51 GMT, Per Liden wrote: >> This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. >> >> The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. >> >> However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): >> >>> Going back to the spec, ObjectReference.disableCollection() says: >>> >>> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >>> >>> and >>> >>> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >>> >>> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >>> >>> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >>> >>> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). >> >> Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. >> >> However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. >> >> This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. >> >> Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: >> - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. >> - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. >> - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. >> - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. >> >> Testing: >> - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From cjplummer at openjdk.java.net Tue Dec 8 22:39:38 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 8 Dec 2020 22:39:38 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v3] In-Reply-To: References: <_W4lIt9BSy6C6rbh9fR97LKXaL2n6DOkJDCOoaoqzYw=.7c887352-cc1e-4b78-8436-e720ed8d656a@github.com> Message-ID: <8_3bIAI5yDF79HSbQVGGsbr3xcoBpQd9cJXONYT_X1w=.f577f007-13eb-4d73-af48-19143a5c4403@github.com> On Tue, 8 Dec 2020 21:42:11 GMT, Per Liden wrote: >> I'm ok with making the change and then seeing if there is any fallout from it. My guess is there won't be. I do think there is a need to cleanup the JDI and JDWP specs in a few areas w.r.t. object liveness. Another CR can be filed for that. > > I filed https://bugs.openjdk.java.net/browse/JDK-8257921. Feel free to extend/improve the description. Thanks. I'll add some suggestions to the CR based on some of our recent discussions. ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From coleenp at openjdk.java.net Wed Dec 9 00:29:33 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Dec 2020 00:29:33 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: <0wToQw4Jn72nDvNk-YCpp6SeCSFUg17Ta3lrUchYenQ=.378b0e0d-9e3c-42aa-baa2-68857654b990@github.com> On Tue, 8 Dec 2020 21:17:16 GMT, Leonid Mesnik wrote: >> The StressRedefine.java (base for redefine stress tests) defines 3 important constants: >> private static int staticMethodCallersNumber = 10; >> private static int nonstaticMethodCallersNumber = 10; >> private static int redefiningThreadsNumber = 40; >> >> The 1st is number of threads to call a static method from constantly redefined class. >> The 2nd is number of threads to call am instance method from constantly redefined class. >> The 3rd is number of threads to redefine the target class. >> The redefiningThreadsNumber=40 is unreasonably big for the StressRedefine test, and there is no chance with -Xcomp for one of the methods above to get resolved without a class redefinition. So, after 100 of non-successfull attempts we hit the guarantee in the open/src/hotspot/share/interpreter/interpreterRuntime.cpp:879 >> guarantee((retry_count++ < 100)) failed: Could not resolve to latest version of redefined method >> To avoid it, the test StressRedefine/TestDescription.java is tweaked to have redefiningThreadsNumber=4. >> >> The test StressRedefineWithoutBytecodeCorruption is worse as it fails even with redefiningThreadsNumber=1. So, a require is added to exclude the test with the -Xcomp flag. > > looks good. I don't get serviceability-dev mail anymore because it was being duplicated with hotspot-runtime-dev most of the time. I don't think this fixes the problem, it only makes the test less stressful. Both of these tests find a lot of real bugs in redefinition, like this one. ------------- PR: https://git.openjdk.java.net/jdk/pull/1692 From sspitsyn at openjdk.java.net Wed Dec 9 01:33:33 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 9 Dec 2020 01:33:33 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: <0wToQw4Jn72nDvNk-YCpp6SeCSFUg17Ta3lrUchYenQ=.378b0e0d-9e3c-42aa-baa2-68857654b990@github.com> References: <0wToQw4Jn72nDvNk-YCpp6SeCSFUg17Ta3lrUchYenQ=.378b0e0d-9e3c-42aa-baa2-68857654b990@github.com> Message-ID: On Wed, 9 Dec 2020 00:26:38 GMT, Coleen Phillimore wrote: >> looks good. > > I don't get serviceability-dev mail anymore because it was being duplicated with hotspot-runtime-dev most of the time. I don't think this fixes the problem, it only makes the test less stressful. Both of these tests find a lot of real bugs in redefinition, like this one. We had a private slack chat with Coleen. Coleen suggested a nice fix in the InterpreterRuntime::resolve_invoke which I like. My mach5 job with Coleen's patch doing 100 StressRedefine tests runs is passed. So, most likely, I'll withdraw this PR and hand this bug over to Coleen. I'm still waiting for reply from Coleen. ------------- PR: https://git.openjdk.java.net/jdk/pull/1692 From sspitsyn at openjdk.java.net Wed Dec 9 06:44:35 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 9 Dec 2020 06:44:35 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 19:28:29 GMT, Alan Bateman wrote: >> This change have been already reviewed by Mandy, Sundar, Alan and David. >> Please, see the jdk 15 review thread: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html >> >> Now, the PR approval is needed. >> The push was postponed because the CSR was not approved at that time (it is now): >> https://bugs.openjdk.java.net/browse/JDK-8248189 >> Investigation of existing popular java agents was requested by Joe. >> ---------- >> >> The java.lang.instrument spec: >> https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html >> >> Summary: >> The java.lang.instrument spec clearly states: >> "The agent class must implement a public static premain method >> similar in principle to the main application entry point." >> Current implementation of sun/instrument/InstrumentationImpl.java >> allows the premain method be non-public which violates the spec. >> This fix aligns the implementation with the spec. >> >> Testing: >> A mach5 run of jdk_instrument tests is in progress. > > src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java line 501: > >> 499: String msg = "method " + classname + "." + methodname + " must be declared public"; >> 500: throw new IllegalAccessException(msg); >> 501: } > > If canAccess fails then it means that javaAgentClass is not public or the premain method is not public. The invoke will fail but I agree eat explicit canAccess check means we get finer control on the exception message. > > (I can't help feeling that we should do a bit more cleanup here and not use getDeclaredMethod or be concerned with inheritance. This is because the Premain-Class is meant to specify the agent class. Also can't have a public static premain in super class and a non-public static premain in a sub-class). My gut feeling is that it should be possible to get rid of the getDeclaredMethod calls with the reasoning you provided above. The canAccess check is not really needed in such a case as the getMethod returns public methods only (is my understanding correct?). This would simplify the implementation. Two disadvantages of this approach are: - less fine control on the exception message: NoSuchMethodException instead of IllegalAccessException for non-public premain methods - some compatibility risk is involved (most of agents define premain method correctly, so the only java agents that define premain methods with unusual tricks are impacted) ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From github.com+16932759+shqking at openjdk.java.net Wed Dec 9 07:16:44 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Wed, 9 Dec 2020 07:16:44 GMT Subject: RFR: 8257928: Test image build failure with clang-10 due to -Wmisleading-indentation Message-ID: Flag '-Wmisleading-indentation' was introduced since clang-10 [1] and gcc-6 [2]. Putting the code with proper indentations would suppress this warning. The main reason why test image build with gcc succeeds is that, clang and gcc might behave differently for some corner cases under '-Wmisleading-indentation'. The following code snippet is crafted based on this build failure, where each statement with improper indentation (line A and line B) follows an if-statement. The key difference between foo() and bar() lies in that there exists an extra comment, i.e. "/* comment 2 */", between statement at line A and the if-statement. int foo(int num) { /* comment 1 */ if (num > 1) return 0; /* comment 2 */ num = num + 1; // line A return num; } int bar(int val) { /* comment 3 */ if (val > 1) return 0; val = val + 1; // line B return val; } It's worth noting that foo() is quite similar to the erroneous code in this build failure. Clang-10 would emit misleading indentation warnings for both foo() and bar(), whereas gcc-6 or higher considers foo() free of problems. [3] This patch is a complement to JDK-8253892. In JDK-8253892, flag '-Wmisleading-indentation' is disabled for both clang and gcc when building JRE and JDK images. This patch does not disable the flag for test image building, but just fixes the code, becasue: - only a small number of warnings are produced and it's easy to fix them one by one. - inconsistent warning behaviors between gcc and clang are triggered by this case and simply disabling the flag does not work. Note that AArch64 is NOT tested because test image build still fails after this bug is fixed due to another runtime error (See JDK-8257936), which is not related to this patch. [1] https://releases.llvm.org/10.0.0/tools/clang/docs/DiagnosticsReference.html [2] https://gcc.gnu.org/onlinedocs/gcc-6.5.0/gcc/Warning-Options.html#Warning-Options [3] https://godbolt.org/z/xs6xWv --------------------- We have tested with this patch, the test image can be built successfully with clang-10 on X86 machine. ------------- Commit messages: - 8257928: Test image build failure with clang-10 due to -Wmisleading-indentation Changes: https://git.openjdk.java.net/jdk/pull/1709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1709&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257928 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1709/head:pull/1709 PR: https://git.openjdk.java.net/jdk/pull/1709 From pliden at openjdk.java.net Wed Dec 9 07:49:36 2020 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 9 Dec 2020 07:49:36 GMT Subject: Integrated: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 12:55:04 GMT, Per Liden wrote: > This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests. > > The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed. > > However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987): > >> Going back to the spec, ObjectReference.disableCollection() says: >> >> "By default all ObjectReference values returned by JDI may be collected at any time the target VM is running" >> >> and >> >> "Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended." >> >> But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says: >> >> "Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended." >> >> No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection(). > > Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not. > > However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again. > > This patch introduces the needed functions in `libjdwp` to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of `VirtualMachine.suspend()` and `VirtualMachine.resume()` to implement the behaviour described above. > > Note that there are still a few tests that needed adjustments to guard against `ObjectCollectionException`. These are: > - *vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java* - This test seems to have been forgotten by [JDK-8203174](https://bugs.openjdk.java.net/browse/JDK-8203174), which did a similar fix in the other `ArrayType/newinstance` tests. > - *vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java* - We just want to allocate as much as we can, so catching an ignoring `ObjectCollectedException` seems reasonable here. > - *vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java* - We still want to prevent `TestClassLoader` from being unloaded to avoid invalidating code locations. > - *vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java* - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't. > > Testing: > - More than 50 iterations of the `vmTestbase/nsk/jdi` and `vmTestbase/nsk/jdwp` test suites, using various GC, both in mach5 and locally. This pull request has now been integrated. Changeset: 79f1dfb8 Author: Per Liden URL: https://git.openjdk.java.net/jdk/commit/79f1dfb8 Stats: 168 lines in 8 files changed: 135 ins; 0 del; 33 mod 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException Reviewed-by: dholmes, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From pliden at openjdk.java.net Wed Dec 9 07:49:34 2020 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 9 Dec 2020 07:49:34 GMT Subject: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v3] In-Reply-To: <3r_aQU9A4Vu5QCcVxk4xpb2rGZoA7BjPGSpRz3OEg2c=.4165ab02-964f-4873-a8fc-7d36b95357a6@github.com> References: <-7O_R4ZOVdbm3fvNcMb3xRiIQ6i8fGpTeHYtkvFZnvY=.2e67bf61-3df2-400c-9b28-c9def5bf7d13@github.com> <3r_aQU9A4Vu5QCcVxk4xpb2rGZoA7BjPGSpRz3OEg2c=.4165ab02-964f-4873-a8fc-7d36b95357a6@github.com> Message-ID: <2RwHa1kbWXQiOkndL3Enlpr9Adn9Pr3qw5pd6TowN9g=.e68376c5-af4f-43a1-8dfa-63be68d55012@github.com> On Tue, 8 Dec 2020 22:37:13 GMT, Chris Plummer wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyright > > Marked as reviewed by cjplummer (Reviewer). Thanks for reviewing, @plummercj and @dholmes-ora! ------------- PR: https://git.openjdk.java.net/jdk/pull/1595 From lzang at openjdk.java.net Wed Dec 9 09:03:41 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 9 Dec 2020 09:03:41 GMT Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap dump Message-ID: 8257234 : Add gz option to SA jmap to write a gzipped heap dump ------------- Commit messages: - 8257234 : Add gz option to SA jmap to write a gzipped heap dump Changes: https://git.openjdk.java.net/jdk/pull/1712/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257234 Stats: 327 lines in 4 files changed: 292 ins; 2 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/1712.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1712/head:pull/1712 PR: https://git.openjdk.java.net/jdk/pull/1712 From coleenp at openjdk.java.net Wed Dec 9 13:25:33 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Dec 2020 13:25:33 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: <0wToQw4Jn72nDvNk-YCpp6SeCSFUg17Ta3lrUchYenQ=.378b0e0d-9e3c-42aa-baa2-68857654b990@github.com> Message-ID: On Wed, 9 Dec 2020 01:31:16 GMT, Serguei Spitsyn wrote: >> I don't get serviceability-dev mail anymore because it was being duplicated with hotspot-runtime-dev most of the time. I don't think this fixes the problem, it only makes the test less stressful. Both of these tests find a lot of real bugs in redefinition, like this one. > > We had a private slack chat with Coleen. > Coleen suggested a nice fix in the InterpreterRuntime::resolve_invoke which I like. > My mach5 job with Coleen's patch doing 100 StressRedefine tests runs is passed. > So, most likely, I'll withdraw this PR and hand this bug over to Coleen. > I'm still waiting for reply from Coleen. I'm doing some final tests with my patch to make sure I can reproduce the original path through the code. Thanks for the command line, Serguei. I can take this bug and send out a PR if all goes well. ------------- PR: https://git.openjdk.java.net/jdk/pull/1692 From coleenp at openjdk.java.net Wed Dec 9 16:39:39 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Dec 2020 16:39:39 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently Message-ID: This change handles redefinition during method resolution, but returning the new method. It's not needed to reresolve the invocation. See the bug for more information. Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. ------------- Commit messages: - 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently Changes: https://git.openjdk.java.net/jdk/pull/1717/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1717&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245446 Stats: 22 lines in 1 file changed: 2 ins; 12 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1717.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1717/head:pull/1717 PR: https://git.openjdk.java.net/jdk/pull/1717 From sspitsyn at openjdk.java.net Wed Dec 9 17:17:33 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 9 Dec 2020 17:17:33 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: <0wToQw4Jn72nDvNk-YCpp6SeCSFUg17Ta3lrUchYenQ=.378b0e0d-9e3c-42aa-baa2-68857654b990@github.com> Message-ID: On Wed, 9 Dec 2020 13:22:58 GMT, Coleen Phillimore wrote: >> We had a private slack chat with Coleen. >> Coleen suggested a nice fix in the InterpreterRuntime::resolve_invoke which I like. >> My mach5 job with Coleen's patch doing 100 StressRedefine tests runs is passed. >> So, most likely, I'll withdraw this PR and hand this bug over to Coleen. >> I'm still waiting for reply from Coleen. > > I'm doing some final tests with my patch to make sure I can reproduce the original path through the code. Thanks for the command line, Serguei. I can take this bug and send out a PR if all goes well. This PR is withdrawn as Coleen created new one. ------------- PR: https://git.openjdk.java.net/jdk/pull/1692 From sspitsyn at openjdk.java.net Wed Dec 9 17:17:34 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 9 Dec 2020 17:17:34 GMT Subject: Withdrawn: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 09:53:36 GMT, Serguei Spitsyn wrote: > The StressRedefine.java (base for redefine stress tests) defines 3 important constants: > private static int staticMethodCallersNumber = 10; > private static int nonstaticMethodCallersNumber = 10; > private static int redefiningThreadsNumber = 40; > > The 1st is number of threads to call a static method from constantly redefined class. > The 2nd is number of threads to call am instance method from constantly redefined class. > The 3rd is number of threads to redefine the target class. > The redefiningThreadsNumber=40 is unreasonably big for the StressRedefine test, and there is no chance with -Xcomp for one of the methods above to get resolved without a class redefinition. So, after 100 of non-successfull attempts we hit the guarantee in the open/src/hotspot/share/interpreter/interpreterRuntime.cpp:879 > guarantee((retry_count++ < 100)) failed: Could not resolve to latest version of redefined method > To avoid it, the test StressRedefine/TestDescription.java is tweaked to have redefiningThreadsNumber=4. > > The test StressRedefineWithoutBytecodeCorruption is worse as it fails even with redefiningThreadsNumber=1. So, a require is added to exclude the test with the -Xcomp flag. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1692 From sspitsyn at openjdk.java.net Wed Dec 9 17:23:33 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 9 Dec 2020 17:23:33 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 16:33:22 GMT, Coleen Phillimore wrote: > This change handles redefinition during method resolution, but returning the new method. It's not needed to reresolve the invocation. See the bug for more information. > > Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. Hi Coleen, I like this fix and looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1717 From coleenp at openjdk.java.net Wed Dec 9 18:25:52 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Dec 2020 18:25:52 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 17:21:16 GMT, Serguei Spitsyn wrote: >> This change handles redefinition during method resolution, by returning the new method. It's not needed to reresolve the invocation. See the bug for more information. >> >> Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. >> >> I don't now why it can't link to the issue: >> https://bugs.openjdk.java.net/browse/JDK-8245446 > > Hi Coleen, > I like this fix and looks good. > Thanks, > Serguei Thanks Serguei for the fast review and discussion about this bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/1717 From mchung at openjdk.java.net Wed Dec 9 18:33:36 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Dec 2020 18:33:36 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 06:40:25 GMT, Serguei Spitsyn wrote: >> src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java line 501: >> >>> 499: String msg = "method " + classname + "." + methodname + " must be declared public"; >>> 500: throw new IllegalAccessException(msg); >>> 501: } >> >> If canAccess fails then it means that javaAgentClass is not public or the premain method is not public. The invoke will fail but I agree eat explicit canAccess check means we get finer control on the exception message. >> >> (I can't help feeling that we should do a bit more cleanup here and not use getDeclaredMethod or be concerned with inheritance. This is because the Premain-Class is meant to specify the agent class. Also can't have a public static premain in super class and a non-public static premain in a sub-class). > > My gut feeling is that it should be possible to get rid of the getDeclaredMethod calls with the reasoning you provided above. The canAccess check is not really needed in such a case as the getMethod returns public methods only (is my understanding correct?). This would simplify the implementation. Two disadvantages of this approach are: > - less fine control on the exception message: NoSuchMethodException instead of IllegalAccessException for non-public premain methods > - some compatibility risk is involved (most of agents define premain method correctly, so the only java agents that define premain methods with unusual tricks are impacted) If the java agent class declares a non-public premain method but its superclass declares a public premain method, what should be the expected behavior? The proposed fix will choose the java agent class's non-public premain and therefore it will fail to load the agent class with IAE. If we get rid of the `getDeclaredMethod` call and find premain using `getMethod`, it will choose the public premain method defined directly in the java agent class or indirectly in its superclass. As Alan stated, `Premain-Class` attribute is meant to specify the agent class. Also specified in the package spec of `java.lang.instrument', the agent class must implement a public static premain method similar in principle to the main application entry point. Also under "Manifest Attributes" section, Premain-Class When an agent is specified at JVM launch time this attribute specifies the agent class. That is, the class containing the premain method. It expects that there is a public premain method declared in the agent class, not in its superclass. So I think it's best to fix this as well in this PR by dropping line 469-495 (i.e. keep `getDeclaredMethod` case and not search for inherited premain). Throw if the premain method is not found or it is not accessible. This needs to update the CSR for behavioral change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From hseigel at openjdk.java.net Wed Dec 9 18:47:38 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 9 Dec 2020 18:47:38 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 16:33:22 GMT, Coleen Phillimore wrote: > This change handles redefinition during method resolution, by returning the new method. It's not needed to reresolve the invocation. See the bug for more information. > > Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. > > I don't now why it can't link to the issue: > https://bugs.openjdk.java.net/browse/JDK-8245446 The changes look good! ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1717 From coleenp at openjdk.java.net Wed Dec 9 20:20:37 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Dec 2020 20:20:37 GMT Subject: RFR: 8257993: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: <_0dKUIp1fWZXTUq_TJJha3XhR21nIkp0TOzAtCv1cSY=.4c6cea7f-936f-4487-ad80-fd8ed9d13cb6@github.com> On Wed, 9 Dec 2020 18:44:37 GMT, Harold Seigel wrote: >> This change handles redefinition during method resolution, by returning the new method. It's not needed to reresolve the invocation. See the bug for more information. >> >> Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. > > The changes look good! Thank you Harold! ------------- PR: https://git.openjdk.java.net/jdk/pull/1717 From dholmes at openjdk.java.net Wed Dec 9 23:13:32 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 9 Dec 2020 23:13:32 GMT Subject: RFR: 8257993: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 16:33:22 GMT, Coleen Phillimore wrote: > This change handles redefinition during method resolution, by returning the new method. It's not needed to reresolve the invocation. See the bug for more information. > > Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. Looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1717 From coleenp at openjdk.java.net Wed Dec 9 23:13:32 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Dec 2020 23:13:32 GMT Subject: RFR: 8257993: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: <8iH1btiJXh6bSEgZ02snEfnXSI1mNEhYX9xHgsJIANU=.457564db-87e4-4323-a6b2-3ea9751bcdcb@github.com> On Wed, 9 Dec 2020 23:06:38 GMT, David Holmes wrote: >> This change handles redefinition during method resolution, by returning the new method. It's not needed to reresolve the invocation. See the bug for more information. >> >> Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. > > Looks good. > Thanks, > David Thanks David. ------------- PR: https://git.openjdk.java.net/jdk/pull/1717 From coleenp at openjdk.java.net Wed Dec 9 23:13:33 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Dec 2020 23:13:33 GMT Subject: Integrated: 8257993: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: <9MYa0NE3pM_ytBR-YvDvO19ET4mxHRuCX4kQIAyaSN0=.5fdda13e-7598-4f95-93e0-c26f8d50e7e3@github.com> On Wed, 9 Dec 2020 16:33:22 GMT, Coleen Phillimore wrote: > This change handles redefinition during method resolution, by returning the new method. It's not needed to reresolve the invocation. See the bug for more information. > > Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. This pull request has now been integrated. Changeset: 0a3e446a Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/0a3e446a Stats: 22 lines in 1 file changed: 2 ins; 12 del; 8 mod 8257993: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently Reviewed-by: sspitsyn, hseigel, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1717 From sspitsyn at openjdk.java.net Thu Dec 10 00:37:14 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 10 Dec 2020 00:37:14 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v2] In-Reply-To: References: Message-ID: > This change have been already reviewed by Mandy, Sundar, Alan and David. > Please, see the jdk 15 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html > > Now, the PR approval is needed. > The push was postponed because the CSR was not approved at that time (it is now): > https://bugs.openjdk.java.net/browse/JDK-8248189 > Investigation of existing popular java agents was requested by Joe. > ---------- > > The java.lang.instrument spec: > https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html > > Summary: > The java.lang.instrument spec clearly states: > "The agent class must implement a public static premain method > similar in principle to the main application entry point." > Current implementation of sun/instrument/InstrumentationImpl.java > allows the premain method be non-public which violates the spec. > This fix aligns the implementation with the spec. > > Testing: > A mach5 run of jdk_instrument tests is in progress. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: removed lookup for inherited premain/agentmain methods ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1694/files - new: https://git.openjdk.java.net/jdk/pull/1694/files/471f7bf7..2da0ac02 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=00-01 Stats: 240 lines in 7 files changed: 180 ins; 60 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1694/head:pull/1694 PR: https://git.openjdk.java.net/jdk/pull/1694 From sspitsyn at openjdk.java.net Thu Dec 10 00:54:35 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 10 Dec 2020 00:54:35 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs In-Reply-To: References: Message-ID: <_i4J-RBRVfOjiBXaZadxxxlhJfMUtl6YZjqrDcz6cwY=.d16534e8-ea17-44d1-b82a-7241020dd12b@github.com> On Tue, 8 Dec 2020 20:05:24 GMT, Serguei Spitsyn wrote: >> All the discussion is in the bug and CSR: >> https://bugs.openjdk.java.net/browse/JDK-8165276 >> https://bugs.openjdk.java.net/browse/JDK-8248189 >> We messed up in JDK-5070281 (JDK 6) and it came to light in JDK 9 when auditing the use of setAccessible in the JDK. > > Chris, I've added link to the jdk 15 review thread to the PR description. Alan, Mandy and Chris, Thank you for your comments! I've committed and pushed an update which implements the suggestion from Mandy to get rid of inherited premain/agentmain methods. I also had to fix 3 tests (InheritAgent0100, InheritAgent1000 and InheritAgent1100) which started to fail with this update as they are relying on the inherited premain methods. I've refactored them to negative tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From sspitsyn at openjdk.java.net Thu Dec 10 02:11:36 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 10 Dec 2020 02:11:36 GMT Subject: RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads [v3] In-Reply-To: <7gm7Hc5kPM8P71GeIflDtxunU1WF8RtKQZ5Djz5plRI=.d4e646d8-a3b4-4d56-97d3-5c34aba1ed39@github.com> References: <7gm7Hc5kPM8P71GeIflDtxunU1WF8RtKQZ5Djz5plRI=.d4e646d8-a3b4-4d56-97d3-5c34aba1ed39@github.com> Message-ID: On Tue, 8 Dec 2020 14:00:25 GMT, Richard Reingruber wrote: >> This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused >> timeout failures when graal is enabled. >> >> The fix is to avoid suspending all threads when a breakpoint is reached and then resume >> just the main thread again. This pattern was used in the test case >> EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal >> threads remained suspended and, running with -Xbatch, the main thread waited >> (with timeout) for completion of compile tasks. >> The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only >> to the main test thread and all explicit resume calls apply to all java threads. >> >> Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is >> reduced from 30s to 10s. > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Only main thread needs to be resumed in EARelockingObjectCurrentlyWaitingOn. Hi Richard, The fix looks okay to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1625 From lzang at openjdk.java.net Thu Dec 10 02:25:48 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 10 Dec 2020 02:25:48 GMT Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap dump [v2] In-Reply-To: References: Message-ID: > 8257234 : Add gz option to SA jmap to write a gzipped heap dump Lin Zang has updated the pull request incrementally with one additional commit since the last revision: refine comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1712/files - new: https://git.openjdk.java.net/jdk/pull/1712/files/a915f067..909ee247 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=00-01 Stats: 18 lines in 1 file changed: 1 ins; 3 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1712.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1712/head:pull/1712 PR: https://git.openjdk.java.net/jdk/pull/1712 From lzang at openjdk.java.net Thu Dec 10 03:08:48 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 10 Dec 2020 03:08:48 GMT Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap dump [v3] In-Reply-To: References: Message-ID: > 8257234 : Add gz option to SA jmap to write a gzipped heap dump Lin Zang has updated the pull request incrementally with one additional commit since the last revision: delete unnecessary print ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1712/files - new: https://git.openjdk.java.net/jdk/pull/1712/files/909ee247..ef353ac3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1712.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1712/head:pull/1712 PR: https://git.openjdk.java.net/jdk/pull/1712 From rrich at openjdk.java.net Thu Dec 10 08:29:35 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 10 Dec 2020 08:29:35 GMT Subject: RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads [v3] In-Reply-To: References: <7gm7Hc5kPM8P71GeIflDtxunU1WF8RtKQZ5Djz5plRI=.d4e646d8-a3b4-4d56-97d3-5c34aba1ed39@github.com> Message-ID: On Thu, 10 Dec 2020 02:08:38 GMT, Serguei Spitsyn wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Only main thread needs to be resumed in EARelockingObjectCurrentlyWaitingOn. > > Hi Richard, > The fix looks okay to me. > Thanks, > Serguei Hi Serguei, thanks a lot for reviewing this. Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/1625 From hseigel at openjdk.java.net Thu Dec 10 16:31:33 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 10 Dec 2020 16:31:33 GMT Subject: RFR: 8253797: [cgroups v2] Account for the fact that swap accounting is disabled on some systems In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 17:48:01 GMT, Severin Gehwolf wrote: > This has been implemented for cgroups v1 with [JDK-8250984](https://bugs.openjdk.java.net/browse/JDK-8250984) but was lacking some tooling support for cgroups v2. With podman 2.2.0 release this could now be implemented (and tested). The idea is the same as for the cgroups v1 fix. If we've got no swap limit capabilities, return the memory limit only. > > Note that for cgroups v2 doesn't implement CgroupV1Metrics (obviously) and, thus, doesn't have `getMemoryAndSwapFailCount()` and `getMemoryAndSwapMaxUsage()`. > > Testing: > - [x] submit testing > - [x] container tests on cgroups v2 with swapaccount=0. > - [x] Manual container tests involving `-XshowSettings:system` on cgroups v2. > > Thoughts? The changes look good. Thanks for doing this. Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1672 From sgehwolf at openjdk.java.net Thu Dec 10 16:48:31 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 10 Dec 2020 16:48:31 GMT Subject: RFR: 8253797: [cgroups v2] Account for the fact that swap accounting is disabled on some systems In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 16:28:59 GMT, Harold Seigel wrote: > The changes look good. Thanks for doing this. Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1672 From sgehwolf at openjdk.java.net Thu Dec 10 16:51:59 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 10 Dec 2020 16:51:59 GMT Subject: Integrated: 8253797: [cgroups v2] Account for the fact that swap accounting is disabled on some systems In-Reply-To: References: Message-ID: <7xEphGBTI5a0xuHWOk4FJqu1PXqcvJUfNFjef3f23hI=.7e7a7528-3caa-4a3b-8c12-a329871c215e@github.com> On Mon, 7 Dec 2020 17:48:01 GMT, Severin Gehwolf wrote: > This has been implemented for cgroups v1 with [JDK-8250984](https://bugs.openjdk.java.net/browse/JDK-8250984) but was lacking some tooling support for cgroups v2. With podman 2.2.0 release this could now be implemented (and tested). The idea is the same as for the cgroups v1 fix. If we've got no swap limit capabilities, return the memory limit only. > > Note that for cgroups v2 doesn't implement CgroupV1Metrics (obviously) and, thus, doesn't have `getMemoryAndSwapFailCount()` and `getMemoryAndSwapMaxUsage()`. > > Testing: > - [x] submit testing > - [x] container tests on cgroups v2 with swapaccount=0. > - [x] Manual container tests involving `-XshowSettings:system` on cgroups v2. > > Thoughts? This pull request has now been integrated. Changeset: 66936111 Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/66936111 Stats: 45 lines in 2 files changed: 24 ins; 1 del; 20 mod 8253797: [cgroups v2] Account for the fact that swap accounting is disabled on some systems Reviewed-by: hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/1672 From redestad at openjdk.java.net Thu Dec 10 17:26:00 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 10 Dec 2020 17:26:00 GMT Subject: Integrated: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 12:53:48 GMT, Claes Redestad wrote: > This moves the mirroring of vmSymbols in ciSymbols to a separate file, ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol namespace). In a few places code is moved from .hpp to .cpp to facilitate this. > > With PCH disabled, this reduces total includes from 276949 to 276332 This pull request has now been integrated. Changeset: f5740561 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/f5740561 Stats: 183 lines in 32 files changed: 102 ins; 30 del; 51 mod 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() Reviewed-by: kvn, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/1256 From mchung at openjdk.java.net Fri Dec 11 00:00:59 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Dec 2020 00:00:59 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v2] In-Reply-To: References: Message-ID: <-fyWPj4741U2W9GxiYM8mtRldluxWOG4ghGQr62-bbU=.b0d364ea-1289-4081-bdb3-8a91f0184c4e@github.com> On Thu, 10 Dec 2020 00:37:14 GMT, Serguei Spitsyn wrote: >> This change have been already reviewed by Mandy, Sundar, Alan and David. >> Please, see the jdk 15 review thread: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html >> >> Now, the PR approval is needed. >> The push was postponed because the CSR was not approved at that time (it is now): >> https://bugs.openjdk.java.net/browse/JDK-8248189 >> Investigation of existing popular java agents was requested by Joe. >> ---------- >> >> The java.lang.instrument spec: >> https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html >> >> Summary: >> The java.lang.instrument spec clearly states: >> "The agent class must implement a public static premain method >> similar in principle to the main application entry point." >> Current implementation of sun/instrument/InstrumentationImpl.java >> allows the premain method be non-public which violates the spec. >> This fix aligns the implementation with the spec. >> >> Testing: >> A mach5 run of jdk_instrument tests is in progress. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > removed lookup for inherited premain/agentmain methods Please update @bug in the tests to include this bug ID. All InheritAgentXXX tests are updated to have the InheritAgentXXX class public. However, I think you need to go through them individually for this behavioral change. The existing comments may not be applicable and please update them where appropriate. For example InheritAgent0100 previously verifies the invocation of the premain in its superclass. Does the modified test ensure that this fails to load? Per the comment in the new InheritAgent0100Super class, it expects the superclass' premain should be called. src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java line 499: > 497: // reject non-public premain or agentmain method > 498: if (!m.canAccess(null)) { > 499: String msg = "method " + classname + "." + methodname + " must be declared public"; The comments in line 429-443 need to be updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From rrich at openjdk.java.net Fri Dec 11 08:45:55 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 11 Dec 2020 08:45:55 GMT Subject: RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads [v3] In-Reply-To: References: <7gm7Hc5kPM8P71GeIflDtxunU1WF8RtKQZ5Djz5plRI=.d4e646d8-a3b4-4d56-97d3-5c34aba1ed39@github.com> Message-ID: On Tue, 8 Dec 2020 19:25:30 GMT, Chris Plummer wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Only main thread needs to be resumed in EARelockingObjectCurrentlyWaitingOn. > > Marked as reviewed by cjplummer (Reviewer). @plummercj, @sspitsyn, thanks again for the review. I would like to bring the fix to jdk16. According to https://openjdk.java.net/jeps/3 this is possible in RDP1 for test bug fixes without approval. I'll try to open a PR against jdk16. Would be great if you could review that one too. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/1625 From rrich at openjdk.java.net Fri Dec 11 09:24:05 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 11 Dec 2020 09:24:05 GMT Subject: [jdk16] RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads Message-ID: This is a clone of https://github.com/openjdk/jdk/pull/1625 which was reviewed but not integrated before RDP1 The change is a test bug fix which can be integrated during RDP1 according to https://openjdk.java.net/jeps/3 --- Original Synopsis This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused timeout failures when graal is enabled. The fix is to avoid suspending all threads when a breakpoint is reached and then resume just the main thread again. This pattern was used in the test case EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal threads remained suspended and, running with -Xbatch, the main thread waited (with timeout) for completion of compile tasks. The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only to the main test thread and all explicit resume calls apply to all java threads. Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is reduced from 30s to 10s. ------------- Commit messages: - Only main thread needs to be resumed in EARelockingObjectCurrentlyWaitingOn. - Changes based on Chris Plummer's feedback. - 8255381: com/sun/jdi/EATests.java should not suspend graal threads Changes: https://git.openjdk.java.net/jdk16/pull/7/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=7&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255381 Stats: 90 lines in 2 files changed: 34 ins; 10 del; 46 mod Patch: https://git.openjdk.java.net/jdk16/pull/7.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/7/head:pull/7 PR: https://git.openjdk.java.net/jdk16/pull/7 From rrich at openjdk.java.net Fri Dec 11 09:40:55 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 11 Dec 2020 09:40:55 GMT Subject: [jdk16] RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads In-Reply-To: References: Message-ID: <9-6Z4ygKeEbeO_Ntla2GMG2osrOKzNMlW-gK_evKOHA=.e0a58e3d-8f11-4228-a96d-f371db8ffcb0@github.com> On Fri, 11 Dec 2020 09:03:44 GMT, Richard Reingruber wrote: > This is a clone of https://github.com/openjdk/jdk/pull/1625 which was reviewed but not integrated before RDP1 > > The change is a test bug fix which can be integrated during RDP1 according to https://openjdk.java.net/jeps/3 > > --- Original Synopsis > > This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused > timeout failures when graal is enabled. > > The fix is to avoid suspending all threads when a breakpoint is reached and then resume > just the main thread again. This pattern was used in the test case > EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal > threads remained suspended and, running with -Xbatch, the main thread waited > (with timeout) for completion of compile tasks. > The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only > to the main test thread and all explicit resume calls apply to all java threads. > > Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is > reduced from 30s to 10s. @plummercj, @sspitsyn, I would like to bring this test bug fix to jdk16. It is identical to openjdk/jdk#1625. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk16/pull/7 From pchilanomate at openjdk.java.net Fri Dec 11 17:47:02 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 11 Dec 2020 17:47:02 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings Message-ID: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> Hi, Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. Without the patch I can consistently reproduce the issue. With the patch the test always passes. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.java.net/jdk/pull/1749/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1749&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258057 Stats: 20 lines in 2 files changed: 18 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1749.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1749/head:pull/1749 PR: https://git.openjdk.java.net/jdk/pull/1749 From sspitsyn at openjdk.java.net Fri Dec 11 18:08:58 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 11 Dec 2020 18:08:58 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v2] In-Reply-To: <-fyWPj4741U2W9GxiYM8mtRldluxWOG4ghGQr62-bbU=.b0d364ea-1289-4081-bdb3-8a91f0184c4e@github.com> References: <-fyWPj4741U2W9GxiYM8mtRldluxWOG4ghGQr62-bbU=.b0d364ea-1289-4081-bdb3-8a91f0184c4e@github.com> Message-ID: On Thu, 10 Dec 2020 23:57:46 GMT, Mandy Chung wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> removed lookup for inherited premain/agentmain methods > > Please update @bug in the tests to include this bug ID. > > All InheritAgentXXX tests are updated to have the InheritAgentXXX class public. However, I think you need to go through them individually for this behavioral change. The existing comments may not be applicable and please update them where appropriate. For example InheritAgent0100 previously verifies the invocation of the premain in its superclass. Does the modified test ensure that this fails to load? Per the comment in the new InheritAgent0100Super class, it expects the superclass' premain should be called. Mandy, thank you for comments. You are right, the comments at 429-443 tests need some updates. I'm working on it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From sspitsyn at openjdk.java.net Fri Dec 11 19:03:27 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 11 Dec 2020 19:03:27 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v3] In-Reply-To: References: Message-ID: > This change have been already reviewed by Mandy, Sundar, Alan and David. > Please, see the jdk 15 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html > > Now, the PR approval is needed. > The push was postponed because the CSR was not approved at that time (it is now): > https://bugs.openjdk.java.net/browse/JDK-8248189 > Investigation of existing popular java agents was requested by Joe. > ---------- > > The java.lang.instrument spec: > https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html > > Summary: > The java.lang.instrument spec clearly states: > "The agent class must implement a public static premain method > similar in principle to the main application entry point." > Current implementation of sun/instrument/InstrumentationImpl.java > allows the premain method be non-public which violates the spec. > This fix aligns the implementation with the spec. > > Testing: > A mach5 run of jdk_instrument tests is in progress. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: (1)Fix comment in InstrumentationImpl; (2) Update agent super classes in tests with new expectations that premain methods in supers should non be called ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1694/files - new: https://git.openjdk.java.net/jdk/pull/1694/files/2da0ac02..095d96b0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=01-02 Stats: 19 lines in 4 files changed: 3 ins; 10 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1694/head:pull/1694 PR: https://git.openjdk.java.net/jdk/pull/1694 From amenkov at openjdk.java.net Fri Dec 11 20:32:56 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 11 Dec 2020 20:32:56 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings In-Reply-To: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> Message-ID: On Fri, 11 Dec 2020 17:25:33 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. > > I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. > > Without the patch I can consistently reproduce the issue. With the patch the test always passes. > > Thanks, > Patricio Pumpers created by ProcessTools.startProcess() log the process stdout/stderr. It's quite useful for failure analysis. ------------- PR: https://git.openjdk.java.net/jdk/pull/1749 From cjplummer at openjdk.java.net Fri Dec 11 20:50:54 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 11 Dec 2020 20:50:54 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings In-Reply-To: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> Message-ID: On Fri, 11 Dec 2020 17:25:33 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. > > I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. > > Without the patch I can consistently reproduce the issue. With the patch the test always passes. > > Thanks, > Patricio >From what I can tell (after a bit of possibly inaccurate grepping) this is the only test that uses `PrcoessTools.startProcess()` in combination with `out.stderrShouldBeEmtpyIgnoreWarnings()`, so I assume this issue of split stderr output is unique to this test. However, it seems like that could easily be stumbled into again, and I pity anyone who has to debug this again (and commend you and getting to the root of the issue). I have to admit I don't understanding all the ramifications of moving from `ProcessTools.startProcess()` to just calling `pb.Start()`. Clearly `startProcess()` has some value add. Does not using it affect the test in any negative way? It's also not clear to me what the guidelines are for avoiding this issue in the future. Is it that `startProcess()` + `OutputAnalyzer` on the same process is forbidden, or at least forbidden if the `OutputAnalyzer` is used for anything more than checking the exit value? ------------- PR: https://git.openjdk.java.net/jdk/pull/1749 From cjplummer at openjdk.java.net Fri Dec 11 20:50:54 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 11 Dec 2020 20:50:54 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings In-Reply-To: References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> Message-ID: <9x5PIifhS5s4sQ7RVM_VVdtFa97xhVRCFRv5wXA7twk=.9a1d4730-fcbe-4485-b66b-55144dd82ab4@github.com> On Fri, 11 Dec 2020 20:46:42 GMT, Chris Plummer wrote: >> Hi, >> >> Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. >> >> I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. >> >> Without the patch I can consistently reproduce the issue. With the patch the test always passes. >> >> Thanks, >> Patricio > > From what I can tell (after a bit of possibly inaccurate grepping) this is the only test that uses `PrcoessTools.startProcess()` in combination with `out.stderrShouldBeEmtpyIgnoreWarnings()`, so I assume this issue of split stderr output is unique to this test. However, it seems like that could easily be stumbled into again, and I pity anyone who has to debug this again (and commend you and getting to the root of the issue). > > I have to admit I don't understanding all the ramifications of moving from `ProcessTools.startProcess()` to just calling `pb.Start()`. Clearly `startProcess()` has some value add. Does not using it affect the test in any negative way? > > It's also not clear to me what the guidelines are for avoiding this issue in the future. Is it that `startProcess()` + `OutputAnalyzer` on the same process is forbidden, or at least forbidden if the `OutputAnalyzer` is used for anything more than checking the exit value? > Pumpers created by ProcessTools.startProcess() log the process stdout/stderr. > It's quite useful for failure analysis. This was the type of thing I was hinting at when I asked if there were any possible negative side affects to the change. Sorry I didn't see your post before asking my question. ------------- PR: https://git.openjdk.java.net/jdk/pull/1749 From cjplummer at openjdk.java.net Fri Dec 11 20:55:56 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 11 Dec 2020 20:55:56 GMT Subject: [jdk16] RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 09:03:44 GMT, Richard Reingruber wrote: > This is a clone of https://github.com/openjdk/jdk/pull/1625 which was reviewed but not integrated before RDP1 > > The change is a test bug fix which can be integrated during RDP1 according to https://openjdk.java.net/jeps/3 > > --- Original Synopsis > > This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused > timeout failures when graal is enabled. > > The fix is to avoid suspending all threads when a breakpoint is reached and then resume > just the main thread again. This pattern was used in the test case > EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal > threads remained suspended and, running with -Xbatch, the main thread waited > (with timeout) for completion of compile tasks. > The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only > to the main test thread and all explicit resume calls apply to all java threads. > > Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is > reduced from 30s to 10s. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/7 From pchilanomate at openjdk.java.net Fri Dec 11 21:49:59 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 11 Dec 2020 21:49:59 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings In-Reply-To: <9x5PIifhS5s4sQ7RVM_VVdtFa97xhVRCFRv5wXA7twk=.9a1d4730-fcbe-4485-b66b-55144dd82ab4@github.com> References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> <9x5PIifhS5s4sQ7RVM_VVdtFa97xhVRCFRv5wXA7twk=.9a1d4730-fcbe-4485-b66b-55144dd82ab4@github.com> Message-ID: On Fri, 11 Dec 2020 20:48:23 GMT, Chris Plummer wrote: >> From what I can tell (after a bit of possibly inaccurate grepping) this is the only test that uses `PrcoessTools.startProcess()` in combination with `out.stderrShouldBeEmtpyIgnoreWarnings()`, so I assume this issue of split stderr output is unique to this test. However, it seems like that could easily be stumbled into again, and I pity anyone who has to debug this again (and commend you and getting to the root of the issue). >> >> I have to admit I don't understanding all the ramifications of moving from `ProcessTools.startProcess()` to just calling `pb.Start()`. Clearly `startProcess()` has some value add. Does not using it affect the test in any negative way? >> >> It's also not clear to me what the guidelines are for avoiding this issue in the future. Is it that `startProcess()` + `OutputAnalyzer` on the same process is forbidden, or at least forbidden if the `OutputAnalyzer` is used for anything more than checking the exit value? > >> Pumpers created by ProcessTools.startProcess() log the process stdout/stderr. >> It's quite useful for failure analysis. > > This was the type of thing I was hinting at when I asked if there were any possible negative side affects to the change. Sorry I didn't see your post before asking my question. Hi Alex, > Pumpers created by ProcessTools.startProcess() log the process stdout/stderr. > It's quite useful for failure analysis. But we are still printing the stdout and stderr of the jcmd with the log statement in runJCmd(). ------------- PR: https://git.openjdk.java.net/jdk/pull/1749 From pchilanomate at openjdk.java.net Fri Dec 11 21:56:54 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 11 Dec 2020 21:56:54 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings In-Reply-To: References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> <9x5PIifhS5s4sQ7RVM_VVdtFa97xhVRCFRv5wXA7twk=.9a1d4730-fcbe-4485-b66b-55144dd82ab4@github.com> Message-ID: On Fri, 11 Dec 2020 21:47:33 GMT, Patricio Chilano Mateo wrote: >>> Pumpers created by ProcessTools.startProcess() log the process stdout/stderr. >>> It's quite useful for failure analysis. >> >> This was the type of thing I was hinting at when I asked if there were any possible negative side affects to the change. Sorry I didn't see your post before asking my question. > > Hi Alex, > >> Pumpers created by ProcessTools.startProcess() log the process stdout/stderr. >> It's quite useful for failure analysis. > But we are still printing the stdout and stderr of the jcmd with the log statement in runJCmd(). Hi Chris, > From what I can tell (after a bit of possibly inaccurate grepping) this is the only test that uses `PrcoessTools.startProcess()` in combination with `out.stderrShouldBeEmtpyIgnoreWarnings()`, so I assume this issue of split stderr output is unique to this test. However, it seems like that could easily be stumbled into again, and I pity anyone who has to debug this again (and commend you and getting to the root of the issue). > I also did a search and the other serviceability tests I found using stderrShouldBeEmtpyIgnoreWarnings() execute the process with ProcessBuilder::start(). > I have to admit I don't understanding all the ramifications of moving from `ProcessTools.startProcess()` to just calling `pb.Start()`. Clearly `startProcess()` has some value add. Does not using it affect the test in any negative way? > Looking at ProcessTools.startProcess(), it just calls ProcessBuilder::start() and then executes all the other StreamPumper logic. > It's also not clear to me what the guidelines are for avoiding this issue in the future. Is it that `startProcess()` + `OutputAnalyzer` on the same process is forbidden, or at least forbidden if the `OutputAnalyzer` is used for anything more than checking the exit value? > Right. Otherwise we have a race and the output of the launched process will be split between the two StreamPumpers in an unpredictable way. ------------- PR: https://git.openjdk.java.net/jdk/pull/1749 From sspitsyn at openjdk.java.net Sat Dec 12 01:29:28 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Sat, 12 Dec 2020 01:29:28 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: Message-ID: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> > This change have been already reviewed by Mandy, Sundar, Alan and David. > Please, see the jdk 15 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html > > Now, the PR approval is needed. > The push was postponed because the CSR was not approved at that time (it is now): > https://bugs.openjdk.java.net/browse/JDK-8248189 > Investigation of existing popular java agents was requested by Joe. > ---------- > > The java.lang.instrument spec: > https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html > > Summary: > The java.lang.instrument spec clearly states: > "The agent class must implement a public static premain method > similar in principle to the main application entry point." > Current implementation of sun/instrument/InstrumentationImpl.java > allows the premain method be non-public which violates the spec. > This fix aligns the implementation with the spec. > > Testing: > A mach5 run of jdk_instrument tests is in progress. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: added 8165276 to @bug list of impacted tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1694/files - new: https://git.openjdk.java.net/jdk/pull/1694/files/095d96b0..877ce70b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=02-03 Stats: 22 lines in 20 files changed: 1 ins; 4 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/1694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1694/head:pull/1694 PR: https://git.openjdk.java.net/jdk/pull/1694 From sspitsyn at openjdk.java.net Sat Dec 12 01:33:57 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Sat, 12 Dec 2020 01:33:57 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v2] In-Reply-To: References: <-fyWPj4741U2W9GxiYM8mtRldluxWOG4ghGQr62-bbU=.b0d364ea-1289-4081-bdb3-8a91f0184c4e@github.com> Message-ID: On Fri, 11 Dec 2020 18:06:08 GMT, Serguei Spitsyn wrote: >> Please update @bug in the tests to include this bug ID. >> >> All InheritAgentXXX tests are updated to have the InheritAgentXXX class public. However, I think you need to go through them individually for this behavioral change. The existing comments may not be applicable and please update them where appropriate. For example InheritAgent0100 previously verifies the invocation of the premain in its superclass. Does the modified test ensure that this fails to load? Per the comment in the new InheritAgent0100Super class, it expects the superclass' premain should be called. > > Mandy, thank you for comments. > You are right, the comments at 429-443 and tests need some updates. > I've updated the tests which were converted to be negative: > InheritAgent0100, InheritAgent1000 and InheritAgent1100 > These are the only tests that needed update with new expectations. I've updated the **@bug** in the tests to include this bug ID. All the comments from Mandy have been addressed now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From alanb at openjdk.java.net Sat Dec 12 09:50:58 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 12 Dec 2020 09:50:58 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On Sat, 12 Dec 2020 01:29:28 GMT, Serguei Spitsyn wrote: >> This change have been already reviewed by Mandy, Sundar, Alan and David. >> Please, see the jdk 15 review thread: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html >> >> Now, the PR approval is needed. >> The push was postponed because the CSR was not approved at that time (it is now): >> https://bugs.openjdk.java.net/browse/JDK-8248189 >> Investigation of existing popular java agents was requested by Joe. >> ---------- >> >> The java.lang.instrument spec: >> https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html >> >> Summary: >> The java.lang.instrument spec clearly states: >> "The agent class must implement a public static premain method >> similar in principle to the main application entry point." >> Current implementation of sun/instrument/InstrumentationImpl.java >> allows the premain method be non-public which violates the spec. >> This fix aligns the implementation with the spec. >> >> Testing: >> A mach5 run of jdk_instrument tests is in progress. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > added 8165276 to @bug list of impacted tests src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java line 468: > 466: String msg = "method " + classname + "." + methodname + " must be declared public"; > 467: throw new IllegalAccessException(msg); > 468: } I think the updated patch looks much better. If the agent class doesn't declare a premain then NoSuchMethodException will be thrown. The only thing that I'm wondering about now is the exception message when the agent class is not public. If I read the changes correctly it means that IllegalAccessException will be thrown saying that .premain should be public. Is that correct? We might need to adjust to the exception message to make it clear, or put in an explicit then to ensure to test that the agent class is public. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From dholmes at openjdk.java.net Mon Dec 14 02:42:00 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Dec 2020 02:42:00 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On Sat, 12 Dec 2020 01:29:28 GMT, Serguei Spitsyn wrote: >> This change have been already reviewed by Mandy, Sundar, Alan and David. >> Please, see the jdk 15 review thread: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html >> >> Now, the PR approval is needed. >> The push was postponed because the CSR was not approved at that time (it is now): >> https://bugs.openjdk.java.net/browse/JDK-8248189 >> Investigation of existing popular java agents was requested by Joe. >> ---------- >> >> The java.lang.instrument spec: >> https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html >> >> Summary: >> The java.lang.instrument spec clearly states: >> "The agent class must implement a public static premain method >> similar in principle to the main application entry point." >> Current implementation of sun/instrument/InstrumentationImpl.java >> allows the premain method be non-public which violates the spec. >> This fix aligns the implementation with the spec. >> >> Testing: >> A mach5 run of jdk_instrument tests is in progress. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > added 8165276 to @bug list of impacted tests Changes requested by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From dholmes at openjdk.java.net Mon Dec 14 02:42:01 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Dec 2020 02:42:01 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On Sat, 12 Dec 2020 09:48:27 GMT, Alan Bateman wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> added 8165276 to @bug list of impacted tests > > src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java line 468: > >> 466: String msg = "method " + classname + "." + methodname + " must be declared public"; >> 467: throw new IllegalAccessException(msg); >> 468: } > > I think the updated patch looks much better. > > If the agent class doesn't declare a premain then NoSuchMethodException will be thrown. > > The only thing that I'm wondering about now is the exception message when the agent class is not public. If I read the changes correctly it means that IllegalAccessException will be thrown saying that .premain should be public. Is that correct? We might need to adjust to the exception message to make it clear, or put in an explicit then to ensure to test that the agent class is public. I think an explicit check for a public premain method is better to disambiguate the cases and provide appropriate error messages. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From sgehwolf at openjdk.java.net Mon Dec 14 12:50:19 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 14 Dec 2020 12:50:19 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v2] In-Reply-To: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> Message-ID: > This is an enhancement which solves two issues: > > 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot). > 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place. > > * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass. Severin Gehwolf 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 two additional commits since the last revision: - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics - 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1393/files - new: https://git.openjdk.java.net/jdk/pull/1393/files/1832b70f..fd55ffd7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1393&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1393&range=00-01 Stats: 142480 lines in 1880 files changed: 116851 ins; 13097 del; 12532 mod Patch: https://git.openjdk.java.net/jdk/pull/1393.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1393/head:pull/1393 PR: https://git.openjdk.java.net/jdk/pull/1393 From mdoerr at openjdk.java.net Mon Dec 14 18:00:59 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 14 Dec 2020 18:00:59 GMT Subject: [jdk16] RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 09:03:44 GMT, Richard Reingruber wrote: > This is a clone of https://github.com/openjdk/jdk/pull/1625 which was reviewed but not integrated before RDP1 > > The change is a test bug fix which can be integrated during RDP1 according to https://openjdk.java.net/jeps/3 > > --- Original Synopsis > > This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused > timeout failures when graal is enabled. > > The fix is to avoid suspending all threads when a breakpoint is reached and then resume > just the main thread again. This pattern was used in the test case > EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal > threads remained suspended and, running with -Xbatch, the main thread waited > (with timeout) for completion of compile tasks. > The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only > to the main test thread and all explicit resume calls apply to all java threads. > > Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is > reduced from 30s to 10s. Marked as reviewed by mdoerr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/7 From sspitsyn at openjdk.java.net Mon Dec 14 19:09:00 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 14 Dec 2020 19:09:00 GMT Subject: [jdk16] RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 09:03:44 GMT, Richard Reingruber wrote: > This is a clone of https://github.com/openjdk/jdk/pull/1625 which was reviewed but not integrated before RDP1 > > The change is a test bug fix which can be integrated during RDP1 according to https://openjdk.java.net/jeps/3 > > --- Original Synopsis > > This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused > timeout failures when graal is enabled. > > The fix is to avoid suspending all threads when a breakpoint is reached and then resume > just the main thread again. This pattern was used in the test case > EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal > threads remained suspended and, running with -Xbatch, the main thread waited > (with timeout) for completion of compile tasks. > The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only > to the main test thread and all explicit resume calls apply to all java threads. > > Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is > reduced from 30s to 10s. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/7 From bchristi at openjdk.java.net Mon Dec 14 19:41:05 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Mon, 14 Dec 2020 19:41:05 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh Message-ID: This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). Here are the changes covering core libraries code and tests. Terms were changed as follows: 1. grandfathered -> legacy 2. blacklist -> filter or reject 3. whitelist -> allow or accept 4. master -> coordinator 5. slave -> worker Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. ------------- Commit messages: - Terminology Cleanup - corelibs terminology refresh - bchristi Changes: https://git.openjdk.java.net/jdk/pull/1771/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253497 Stats: 82 lines in 15 files changed: 1 ins; 0 del; 81 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771 From amenkov at openjdk.java.net Mon Dec 14 19:42:01 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Mon, 14 Dec 2020 19:42:01 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings In-Reply-To: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> Message-ID: On Fri, 11 Dec 2020 17:25:33 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. > > I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. > > Without the patch I can consistently reproduce the issue. With the patch the test always passes. > > Thanks, > Patricio Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1749 From naoto at openjdk.java.net Mon Dec 14 20:29:56 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 14 Dec 2020 20:29:56 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh In-Reply-To: References: Message-ID: <6mGHyzJFxdntyaLG6CFPBw87a3I7caQuhWGz8hpLneY=.44f01fb2-a150-42e6-a3b0-853d72d24a1b@github.com> On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Looks good to me. test/jdk/java/lang/ClassLoader/Assert.java line 65: > 63: > 64: int switchSource = 0; > 65: if (args.length == 0) { // This is the coordinator version Extra space between "is" and "the." ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1771 From kcr at openjdk.java.net Mon Dec 14 20:38:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Dec 2020 20:38:58 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Marked as reviewed by kcr (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From joehw at openjdk.java.net Mon Dec 14 21:15:58 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 14 Dec 2020 21:15:58 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh In-Reply-To: References: Message-ID: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Marked as reviewed by joehw (Reviewer). src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 135: > 133: * The pattern must be in same format as used in > 134: * {@link java.io.ObjectInputFilter.Config#createFilter}. > 135: * It may define an accept-list of permitted classes, a reject-list of should accept-list be allow-list to be consistent with the other two RMI classes and ObjectInputFilter.Status#ALLOWED? src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152: > 150: *

> 151: * Care must be taken when defining such a filter, as defining > 152: * an accept-list too restrictive or a too-wide reject-list may would "an allow-list too restrictive or a reject-list too wide" read better? ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From rriggs at openjdk.java.net Mon Dec 14 21:15:56 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 14 Dec 2020 21:15:56 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Marked as reviewed by rriggs (Reviewer). src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 135: > 133: * The pattern must be in same format as used in > 134: * {@link java.io.ObjectInputFilter.Config#createFilter}. > 135: * It may define an accept-list of permitted classes, a reject-list of accept -> allow for consistency src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152: > 150: *

> 151: * Care must be taken when defining such a filter, as defining > 152: * an accept-list too restrictive or a too-wide reject-list may accept -> allow for consistency ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From cjplummer at openjdk.java.net Mon Dec 14 21:28:57 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 14 Dec 2020 21:28:57 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings In-Reply-To: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> Message-ID: On Fri, 11 Dec 2020 17:25:33 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. > > I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. > > Without the patch I can consistently reproduce the issue. With the patch the test always passes. > > Thanks, > Patricio Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1749 From sspitsyn at openjdk.java.net Mon Dec 14 22:47:56 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 14 Dec 2020 22:47:56 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On Mon, 14 Dec 2020 02:39:30 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> added 8165276 to @bug list of impacted tests > > Changes requested by dholmes (Reviewer). Alan, David and Many, thank you for the comments! I'll prepare an update according to the recent requests from you. One question is if I need to clone this PR to the JDK 16 fork: https://github.com/openjdk/jdk16 It depends on our chances to finalize this before RDP2. An alternate approach would be to continue reviewing this PR until all comment are resolved and then clone it to jdk16. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From amenkov at openjdk.java.net Tue Dec 15 00:01:57 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 15 Dec 2020 00:01:57 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings In-Reply-To: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> Message-ID: On Fri, 11 Dec 2020 17:25:33 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. > > I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. > > Without the patch I can consistently reproduce the issue. With the patch the test always passes. > > Thanks, > Patricio Changes requested by amenkov (Reviewer). test/hotspot/jtreg/serviceability/attach/RemovingUnixDomainSocketTest.java line 70: > 68: > 69: out.shouldHaveExitValue(0); > 70: out.stderrShouldBeEmptyIgnoreDeprecatedWarnings(); Looked at the fix one more time. I suppose this new method is not needed as a the message about deprecation is VM warning and should be handled by stderrShouldBeEmptyIgnoreVMWarnings. Also this new method will fails if jcmd prints some other VM warning ------------- PR: https://git.openjdk.java.net/jdk/pull/1749 From mandy.chung at oracle.com Tue Dec 15 00:13:53 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Dec 2020 16:13:53 -0800 Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On 12/14/20 2:47 PM, Serguei Spitsyn wrote: > On Mon, 14 Dec 2020 02:39:30 GMT, David Holmes wrote: > >>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >>> >>> added 8165276 to @bug list of impacted tests >> Changes requested by dholmes (Reviewer). > Alan, David and Many, thank you for the comments! > I'll prepare an update according to the recent requests from you. > One question is if I need to clone this PR to the JDK 16 fork: > https://github.com/openjdk/jdk16 > It depends on our chances to finalize this before RDP2. > An alternate approach would be to continue reviewing this PR until all comment are resolved and then clone it to jdk16. Since this already passes RDP1, this can be retarget to JDK 17 and continue with this PR to openjdk/jdk master.? I see no urgency to fix this in JDK 16. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Dec 15 00:19:11 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2020 10:19:11 +1000 Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings In-Reply-To: References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> Message-ID: On 15/12/2020 10:01 am, Alex Menkov wrote: > On Fri, 11 Dec 2020 17:25:33 GMT, Patricio Chilano Mateo wrote: > >> Hi, >> >> Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. >> >> I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. >> >> Without the patch I can consistently reproduce the issue. With the patch the test always passes. >> >> Thanks, >> Patricio > > Changes requested by amenkov (Reviewer). > > test/hotspot/jtreg/serviceability/attach/RemovingUnixDomainSocketTest.java line 70: > >> 68: >> 69: out.shouldHaveExitValue(0); >> 70: out.stderrShouldBeEmptyIgnoreDeprecatedWarnings(); > > Looked at the fix one more time. > > I suppose this new method is not needed as a the message about deprecation is VM warning and should be handled by stderrShouldBeEmptyIgnoreVMWarnings. > Also this new method will fails if jcmd prints some other VM warning I think that is the point of the new method. We know deprecation warnings are harmless and can be ignored. But other warnings may indicate an issue that needs investigating. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1749 > From bchristi at openjdk.java.net Tue Dec 15 01:38:59 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Dec 2020 01:38:59 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh In-Reply-To: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> References: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> Message-ID: On Mon, 14 Dec 2020 21:08:35 GMT, Joe Wang wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152: > >> 150: *

>> 151: * Care must be taken when defining such a filter, as defining >> 152: * an accept-list too restrictive or a too-wide reject-list may > > would "an allow-list too restrictive or a reject-list too wide" read better? I agree that there is room for improvement here. How about: "...an allow-list too restrictively, or a reject-list too broadly, may..." ? ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From bchristi at openjdk.java.net Tue Dec 15 01:46:08 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Dec 2020 01:46:08 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: References: Message-ID: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: updates, per code review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1771/files - new: https://git.openjdk.java.net/jdk/pull/1771/files/4efa5d43..29525f05 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771 From joehw at openjdk.java.net Tue Dec 15 01:46:09 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 15 Dec 2020 01:46:09 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: References: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> Message-ID: On Tue, 15 Dec 2020 01:36:27 GMT, Brent Christian wrote: >> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152: >> >>> 150: *

>>> 151: * Care must be taken when defining such a filter, as defining >>> 152: * an accept-list too restrictive or a too-wide reject-list may >> >> would "an allow-list too restrictive or a reject-list too wide" read better? > > I agree that there is room for improvement here. How about: > "...an allow-list too restrictively, or a reject-list too broadly, may..." > ? That sounds good to me ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From alanb at openjdk.java.net Tue Dec 15 07:36:57 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 15 Dec 2020 07:36:57 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: References: Message-ID: <-neClWA41LmYuPXJnPDfdxEplCuopdn8ze3V3GZQ-YU=.d6c7045b-a6c9-49e6-97f9-a0fa84185ffe@github.com> On Tue, 15 Dec 2020 01:46:08 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > updates, per code review test/jdk/java/nio/channels/SocketChannel/CloseRegisteredChannel.java line 45: > 43: SocketChannel client = SocketChannel.open (); > 44: client.connect (new InetSocketAddress (InetAddress.getLoopbackAddress(), port)); > 45: SocketChannel channel = server.accept (); Can you rename this to "peer" instead? (we can remove the spurious space after accept while we are there). ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From rrich at openjdk.java.net Tue Dec 15 08:41:59 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 15 Dec 2020 08:41:59 GMT Subject: [jdk16] Integrated: 8255381: com/sun/jdi/EATests.java should not suspend graal threads In-Reply-To: References: Message-ID: <-at6XrV9SPjkzYvw9BMOVZcBhalCp2hz0cP7OcfUdtY=.c66b4f3d-d2b3-4319-8880-afc332f6e4df@github.com> On Fri, 11 Dec 2020 09:03:44 GMT, Richard Reingruber wrote: > This is a clone of https://github.com/openjdk/jdk/pull/1625 which was reviewed but not integrated before RDP1 > > The change is a test bug fix which can be integrated during RDP1 according to https://openjdk.java.net/jeps/3 > > --- Original Synopsis > > This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused > timeout failures when graal is enabled. > > The fix is to avoid suspending all threads when a breakpoint is reached and then resume > just the main thread again. This pattern was used in the test case > EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal > threads remained suspended and, running with -Xbatch, the main thread waited > (with timeout) for completion of compile tasks. > The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only > to the main test thread and all explicit resume calls apply to all java threads. > > Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is > reduced from 30s to 10s. This pull request has now been integrated. Changeset: 09e8675f Author: Richard Reingruber URL: https://git.openjdk.java.net/jdk16/commit/09e8675f Stats: 90 lines in 2 files changed: 34 ins; 10 del; 46 mod 8255381: com/sun/jdi/EATests.java should not suspend graal threads Reviewed-by: cjplummer, mdoerr, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk16/pull/7 From rrich at openjdk.java.net Tue Dec 15 08:41:58 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 15 Dec 2020 08:41:58 GMT Subject: [jdk16] RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 20:53:37 GMT, Chris Plummer wrote: >> This is a clone of https://github.com/openjdk/jdk/pull/1625 which was reviewed but not integrated before RDP1 >> >> The change is a test bug fix which can be integrated during RDP1 according to https://openjdk.java.net/jeps/3 >> >> --- Original Synopsis >> >> This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused >> timeout failures when graal is enabled. >> >> The fix is to avoid suspending all threads when a breakpoint is reached and then resume >> just the main thread again. This pattern was used in the test case >> EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal >> threads remained suspended and, running with -Xbatch, the main thread waited >> (with timeout) for completion of compile tasks. >> The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only >> to the main test thread and all explicit resume calls apply to all java threads. >> >> Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is >> reduced from 30s to 10s. > > Marked as reviewed by cjplummer (Reviewer). Thanks for the reviews @plummercj, @sspitsyn, @TheRealMDoerr! ------------- PR: https://git.openjdk.java.net/jdk16/pull/7 From rrich at openjdk.java.net Tue Dec 15 08:44:55 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 15 Dec 2020 08:44:55 GMT Subject: RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads [v3] In-Reply-To: References: <7gm7Hc5kPM8P71GeIflDtxunU1WF8RtKQZ5Djz5plRI=.d4e646d8-a3b4-4d56-97d3-5c34aba1ed39@github.com> Message-ID: On Fri, 11 Dec 2020 08:43:16 GMT, Richard Reingruber wrote: >> Marked as reviewed by cjplummer (Reviewer). > > @plummercj, @sspitsyn, thanks again for the review. > > I would like to bring the fix to jdk16. According to https://openjdk.java.net/jeps/3 this is possible in RDP1 for test bug fixes without approval. > > I'll try to open a PR against jdk16. Would be great if you could review that one too. > > Thanks, Richard. I'm closing this PR since the change was integrated in jdk16 with openjdk/jdk16#7 ------------- PR: https://git.openjdk.java.net/jdk/pull/1625 From rrich at openjdk.java.net Tue Dec 15 08:44:56 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 15 Dec 2020 08:44:56 GMT Subject: Withdrawn: 8255381: com/sun/jdi/EATests.java should not suspend graal threads In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 15:30:15 GMT, Richard Reingruber wrote: > This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused > timeout failures when graal is enabled. > > The fix is to avoid suspending all threads when a breakpoint is reached and then resume > just the main thread again. This pattern was used in the test case > EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal > threads remained suspended and, running with -Xbatch, the main thread waited > (with timeout) for completion of compile tasks. > The fix was applied to all breakpoints in the test. All explicit suspend calls now apply only > to the main test thread and all explicit resume calls apply to all java threads. > > Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn is > reduced from 30s to 10s. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1625 From ihse at openjdk.java.net Tue Dec 15 09:19:56 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Dec 2020 09:19:56 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: References: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> Message-ID: <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com> On Tue, 15 Dec 2020 01:41:07 GMT, Joe Wang wrote: >> I agree that there is room for improvement here. How about: >> "...an allow-list too restrictively, or a reject-list too broadly, may..." >> ? > > Your call, I'm not a native English speaker :-) It felt to me it's 'restrictive' than 'restrictively', an adj placed after the noun, e.g. a restrictive allow-list. It's an adverb, since it's the act of 'defining' that is being done too restrictively or broadly. If you want to have an adjective you would need to rephrase it so it applies to the noun, like 'defining a too restrictive accept-list'. My non-native English vibes would still prefer the former. ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From sgehwolf at openjdk.java.net Tue Dec 15 13:00:00 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 15 Dec 2020 13:00:00 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection In-Reply-To: References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> Message-ID: On Mon, 23 Nov 2020 19:58:20 GMT, Severin Gehwolf wrote: >>> With respect to JDK-8255908, the changes look good to me. >> >> Thanks! > > @bobvandette Please review when you've got some cycles to spare. Much appreciated! Ping? Anyone? ------------- PR: https://git.openjdk.java.net/jdk/pull/1393 From pchilanomate at openjdk.java.net Tue Dec 15 15:45:56 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 15 Dec 2020 15:45:56 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings In-Reply-To: References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> Message-ID: On Mon, 14 Dec 2020 23:58:43 GMT, Alex Menkov wrote: >> Hi, >> >> Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. >> >> I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. >> >> Without the patch I can consistently reproduce the issue. With the patch the test always passes. >> >> Thanks, >> Patricio > > Changes requested by amenkov (Reviewer). > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [serviceability-dev](mailto:serviceability-dev at openjdk.java.net):_ > > On 15/12/2020 10:01 am, Alex Menkov wrote: > > > On Fri, 11 Dec 2020 17:25:33 GMT, Patricio Chilano Mateo wrote: > > > Hi, > > > Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. > > > I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. > > > Without the patch I can consistently reproduce the issue. With the patch the test always passes. > > > Thanks, > > > Patricio > > > > > > Changes requested by amenkov (Reviewer). > > test/hotspot/jtreg/serviceability/attach/RemovingUnixDomainSocketTest.java line 70: > > > 68: > > > 69: out.shouldHaveExitValue(0); > > > 70: out.stderrShouldBeEmptyIgnoreDeprecatedWarnings(); > > > > > > Looked at the fix one more time. > > I suppose this new method is not needed as a the message about deprecation is VM warning and should be handled by stderrShouldBeEmptyIgnoreVMWarnings. > > Also this new method will fails if jcmd prints some other VM warning > > I think that is the point of the new method. We know deprecation > warnings are harmless and can be ignored. But other warnings may > indicate an issue that needs investigating. > > Cheers, > David Right, as David pointed out the purpose is to only ignore deprecation warnings. Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/1749 From coleenp at openjdk.java.net Tue Dec 15 17:32:03 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 17:32:03 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option Message-ID: See bug for details. Tested: $ java -XX:+StressLdcRewrite -version Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. Error: The unlock option must precede 'StressLdcRewrite'. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version openjdk version "16-internal" 2021-03-16 OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. ------------- Commit messages: - 8257726: Make -XX:+StressLdcRewrite option a diagnostic option - 8257726: Make -XX:+StressLdcRewrite option a diagnostic option Changes: https://git.openjdk.java.net/jdk/pull/1783/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1783&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257726 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1783.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1783/head:pull/1783 PR: https://git.openjdk.java.net/jdk/pull/1783 From lfoltan at openjdk.java.net Tue Dec 15 17:41:54 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Tue, 15 Dec 2020 17:41:54 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option In-Reply-To: References: Message-ID: <87wL9V1rsGxYFAap1lQsYtmcZJ5wbT28lcRma4HjIlk=.abb73ef7-86c8-4785-b063-622efc3accf7@github.com> On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote: > See bug for details. Tested: > > $ java -XX:+StressLdcRewrite -version > Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. > Error: The unlock option must precede 'StressLdcRewrite'. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version > openjdk version "16-internal" 2021-03-16 > OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) > OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) > > Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. Looks good Coleen. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1783 From stuefe at openjdk.java.net Tue Dec 15 17:56:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 15 Dec 2020 17:56:55 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote: > See bug for details. Tested: > > $ java -XX:+StressLdcRewrite -version > Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. > Error: The unlock option must precede 'StressLdcRewrite'. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version > openjdk version "16-internal" 2021-03-16 > OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) > OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) > > Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. Looks right to me, and trivial. This should not be a product option. I cannot believe anyone uses this option in earnest in production. Still, out of sheer fascination I googled but did not find any serious usage. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1783 From bchristi at openjdk.java.net Tue Dec 15 18:50:56 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Dec 2020 18:50:56 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: <-neClWA41LmYuPXJnPDfdxEplCuopdn8ze3V3GZQ-YU=.d6c7045b-a6c9-49e6-97f9-a0fa84185ffe@github.com> References: <-neClWA41LmYuPXJnPDfdxEplCuopdn8ze3V3GZQ-YU=.d6c7045b-a6c9-49e6-97f9-a0fa84185ffe@github.com> Message-ID: <8p4RRf4ltO4wlaOuBRdmlMA-EFGqomUwl2Oat9RwOzw=.95ea6210-d252-4d7a-b316-0384c14b4490@github.com> On Tue, 15 Dec 2020 07:32:12 GMT, Alan Bateman wrote: >> Brent Christian has updated the pull request incrementally with one additional commit since the last revision: >> >> updates, per code review > > test/jdk/java/nio/channels/SocketChannel/CloseRegisteredChannel.java line 45: > >> 43: SocketChannel client = SocketChannel.open (); >> 44: client.connect (new InetSocketAddress (InetAddress.getLoopbackAddress(), port)); >> 45: SocketChannel channel = server.accept (); > > Can you rename this to "peer" instead? (we can remove the spurious space after accept while we are there). Yes, I will name it, "peer", and remove the extra space on the affected lines. ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From coleenp at openjdk.java.net Tue Dec 15 20:42:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 20:42:57 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 17:54:05 GMT, Thomas Stuefe wrote: > I cannot believe anyone uses this option in earnest in production. Still, out of sheer fascination I googled but did not find any serious usage. I discussed this with @dcubed-ojdk who added this for a customer situation and this was his request. Thanks for the code review. Coleen ------------- PR: https://git.openjdk.java.net/jdk/pull/1783 From amenkov at openjdk.java.net Tue Dec 15 20:54:55 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 15 Dec 2020 20:54:55 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings In-Reply-To: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> Message-ID: On Fri, 11 Dec 2020 17:25:33 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. > > I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. > > Without the patch I can consistently reproduce the issue. With the patch the test always passes. > > Thanks, > Patricio Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1749 From minqi at openjdk.java.net Tue Dec 15 21:18:02 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 15 Dec 2020 21:18:02 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option In-Reply-To: References: Message-ID: <37HcgNwgzId0EjrtwwFP3FXaGMPgVoRF1WLDsFgu8ok=.6db8f6f1-2da2-4120-bfa2-364410bed549@github.com> On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote: > See bug for details. Tested: > > $ java -XX:+StressLdcRewrite -version > Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. > Error: The unlock option must precede 'StressLdcRewrite'. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version > openjdk version "16-internal" 2021-03-16 > OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) > OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) > > Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. jvmtiRedfineClasses.cpp use it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1783 From bpb at openjdk.java.net Tue Dec 15 22:00:05 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 15 Dec 2020 22:00:05 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 01:46:08 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > updates, per code review test/jdk/java/lang/ClassLoader/Assert.java line 65: > 63: > 64: int switchSource = 0; > 65: if (args.length == 0) { // This is the coordinator version Perhaps s/coordinator/controller/? ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From lancea at openjdk.java.net Tue Dec 15 22:04:59 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 15 Dec 2020 22:04:59 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 21:57:17 GMT, Brian Burkhalter wrote: >> Brent Christian has updated the pull request incrementally with one additional commit since the last revision: >> >> updates, per code review > > test/jdk/java/lang/ClassLoader/Assert.java line 65: > >> 63: >> 64: int switchSource = 0; >> 65: if (args.length == 0) { // This is the coordinator version > > Perhaps s/coordinator/controller/? Let's change it to: // This is the controller ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From bchristi at openjdk.java.net Tue Dec 15 22:05:00 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Dec 2020 22:05:00 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:02:00 GMT, Lance Andersen wrote: >> test/jdk/java/lang/ClassLoader/Assert.java line 65: >> >>> 63: >>> 64: int switchSource = 0; >>> 65: if (args.length == 0) { // This is the coordinator version >> >> Perhaps s/coordinator/controller/? > > Let's change it to: > > // This is the controller Will do. ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From smarks at openjdk.java.net Tue Dec 15 22:16:57 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 15 Dec 2020 22:16:57 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com> References: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com> Message-ID: On Tue, 15 Dec 2020 09:17:03 GMT, Magnus Ihse Bursie wrote: >> Your call, I'm not a native English speaker :-) It felt to me it's 'restrictive' than 'restrictively', an adj placed after the noun, e.g. a restrictive allow-list. > > It's an adverb, since it's the act of 'defining' that is being done too restrictively or broadly. If you want to have an adjective you would need to rephrase it so it applies to the noun, like 'defining a too restrictive accept-list'. My non-native English vibes would still prefer the former. I'd suggest `... as defining an allow-list that is too narrow or a reject-list that is too-wide may prevent ...`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From bchristi at openjdk.java.net Tue Dec 15 22:21:12 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Dec 2020 22:21:12 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v3] In-Reply-To: References: Message-ID: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Brent Christian has updated the pull request incrementally with three additional commits since the last revision: - This is the controller - use 'controller' in Assert.java - use 'peer' in CloseRegisteredChannel.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1771/files - new: https://git.openjdk.java.net/jdk/pull/1771/files/29525f05..b8cd8b6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771 From bpb at openjdk.java.net Tue Dec 15 22:46:59 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 15 Dec 2020 22:46:59 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v3] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:21:12 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with three additional commits since the last revision: > > - This is the controller > - use 'controller' in Assert.java > - use 'peer' in CloseRegisteredChannel.java Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From rriggs at openjdk.java.net Tue Dec 15 22:46:58 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 15 Dec 2020 22:46:58 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v3] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:21:12 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with three additional commits since the last revision: > > - This is the controller > - use 'controller' in Assert.java > - use 'peer' in CloseRegisteredChannel.java Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From bchristi at openjdk.java.net Tue Dec 15 23:09:55 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Dec 2020 23:09:55 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v3] In-Reply-To: References: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com> Message-ID: On Tue, 15 Dec 2020 22:13:58 GMT, Stuart Marks wrote: >> It's an adverb, since it's the act of 'defining' that is being done too restrictively or broadly. If you want to have an adjective you would need to rephrase it so it applies to the noun, like 'defining a too restrictive accept-list'. My non-native English vibes would still prefer the former. > > I'd suggest `... as defining an allow-list that is too narrow or a reject-list that is too wide may prevent ...`. > > (edited to remove hyphen from "too-wide") Even better! ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From bchristi at openjdk.java.net Tue Dec 15 23:14:14 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Dec 2020 23:14:14 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v4] In-Reply-To: References: Message-ID: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: improve SERIAL_FILTER_PATTERN comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1771/files - new: https://git.openjdk.java.net/jdk/pull/1771/files/b8cd8b6d..ba586413 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771 From smarks at openjdk.java.net Tue Dec 15 23:36:58 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 15 Dec 2020 23:36:58 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v4] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 23:14:14 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > improve SERIAL_FILTER_PATTERN comment Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From dcubed at openjdk.java.net Tue Dec 15 23:43:54 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 15 Dec 2020 23:43:54 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote: > See bug for details. Tested: > > $ java -XX:+StressLdcRewrite -version > Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. > Error: The unlock option must precede 'StressLdcRewrite'. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version > openjdk version "16-internal" 2021-03-16 > OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) > OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) > > Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. Thumbs up! ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1783 From coleenp at openjdk.java.net Tue Dec 15 23:57:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 23:57:57 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 23:41:31 GMT, Daniel D. Daugherty wrote: >> See bug for details. Tested: >> >> $ java -XX:+StressLdcRewrite -version >> Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. >> Error: The unlock option must precede 'StressLdcRewrite'. >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version >> openjdk version "16-internal" 2021-03-16 >> OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) >> OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) >> >> Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. > > Thumbs up! Thanks Lois, Thomas and Dan. ------------- PR: https://git.openjdk.java.net/jdk/pull/1783 From coleenp at openjdk.java.net Tue Dec 15 23:57:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 23:57:58 GMT Subject: Integrated: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option In-Reply-To: References: Message-ID: <6ULIw61aH0yasVbStN371CTQd0xy8LiK8fgYj0Zv8bw=.558bc893-e181-4e65-8fe6-4fc49752e534@github.com> On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote: > See bug for details. Tested: > > $ java -XX:+StressLdcRewrite -version > Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. > Error: The unlock option must precede 'StressLdcRewrite'. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version > openjdk version "16-internal" 2021-03-16 > OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) > OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) > > Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. This pull request has now been integrated. Changeset: 4d6f3181 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/4d6f3181 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod 8257726: Make -XX:+StressLdcRewrite option a diagnostic option Reviewed-by: lfoltan, stuefe, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/1783 From sspitsyn at openjdk.java.net Wed Dec 16 00:17:56 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 16 Dec 2020 00:17:56 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On Mon, 14 Dec 2020 22:45:26 GMT, Serguei Spitsyn wrote: >> Changes requested by dholmes (Reviewer). > > Alan, David and Many, thank you for the comments! > I'll prepare an update according to the recent requests from you. > One question is if I need to clone this PR to the JDK 16 fork: > https://github.com/openjdk/jdk16 > It depends on our chances to finalize this before RDP2. > An alternate approach would be to continue reviewing this PR until all comment are resolved and then clone it to jdk16. Mandy, thank you for the suggestion. I'll retarget the bug and CSR to jdk 17 as nobody is objecting. Also, wanted to make it clear about Exception messages that are provided for two different cases. The test java/lang/instrument/NonPublicPremainAgent.java defines a non-public premain method: ` static void premain(String agentArgs, Instrumentation inst) {` With the m.canAccess check the following message is provided (it looks right): ` Exception in thread "main" java.lang.IllegalAccessException: method NonPublicPremainAgent.premain must be declared public ` Without this check the message was (not sure, it is good enough): ` Exception in thread "main" java.lang.IllegalAccessException: class sun.instrument.InstrumentationImpl (in module java.instrument) cannot access a member of class NonPublicPremainAgent with modifiers "static"` Also, I've added a new test java/lang/instrument/NonPublicAgent.java which defines a non-public agent class with a public premain method. With the m.canAccess check the following message is provided (it does not look right): ` Exception in thread "main" java.lang.IllegalAccessException: method NonPublicPremainAgent.premain must be declared public ` Without this check the message is (it looks pretty confusing): ` Exception in thread "main" java.lang.IllegalAccessException: class sun.instrument.InstrumentationImpl (in module java.instrument) cannot access a member of class NonPublicAgent with modifiers "public static"` So, it seems we also need an explicit check for agent class being public with a right message provided. Please, let me know what you think. I've done some tests refactoring motivated by some private requests from Mandy. Will publish the update as soon as it is ready. Hopefully, today. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From dholmes at openjdk.java.net Wed Dec 16 00:52:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 16 Dec 2020 00:52:56 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On Wed, 16 Dec 2020 00:15:36 GMT, Serguei Spitsyn wrote: >> Alan, David and Many, thank you for the comments! >> I'll prepare an update according to the recent requests from you. >> One question is if I need to clone this PR to the JDK 16 fork: >> https://github.com/openjdk/jdk16 >> It depends on our chances to finalize this before RDP2. >> An alternate approach would be to continue reviewing this PR until all comment are resolved and then clone it to jdk16. > > Mandy, thank you for the suggestion. > I'll retarget the bug and CSR to jdk 17 as nobody is objecting. > > Also, wanted to make it clear about Exception messages that are provided for two different cases. > > The test java/lang/instrument/NonPublicPremainAgent.java defines a non-public premain method: > ` static void premain(String agentArgs, Instrumentation inst) {` > > With the m.canAccess check the following message is provided (it looks right): > ` Exception in thread "main" java.lang.IllegalAccessException: method NonPublicPremainAgent.premain must be declared public ` > > Without this check the message was (not sure, it is good enough): > ` Exception in thread "main" java.lang.IllegalAccessException: class sun.instrument.InstrumentationImpl (in module java.instrument) cannot access a member of class NonPublicPremainAgent with modifiers "static"` > > Also, I've added a new test java/lang/instrument/NonPublicAgent.java which defines a non-public agent class with a public premain method. > > With the m.canAccess check the following message is provided (it does not look right): > ` Exception in thread "main" java.lang.IllegalAccessException: method NonPublicPremainAgent.premain must be declared public ` > > Without this check the message is (it looks pretty confusing): > ` Exception in thread "main" java.lang.IllegalAccessException: class sun.instrument.InstrumentationImpl (in module java.instrument) cannot access a member of class NonPublicAgent with modifiers "public static"` > > So, it seems we also need an explicit check for agent class being public with a right message provided. > I've added the following check: > @@ -426,6 +426,12 @@ public class InstrumentationImpl implements Instrumentation { > NoSuchMethodException firstExc = null; > boolean twoArgAgent = false; > > + // reject non-public owner agent class of premain or agentmain method > + if ((javaAgentClass.getModifiers() & java.lang.reflect.Modifier.PUBLIC) == 0) { > + String msg = "agent class of method " + classname + "." + methodname + " must be declared public"; > + throw new IllegalAccessException(msg); > + } > + > // The agent class must have a premain or agentmain method that > // has 1 or 2 arguments. We check in the following order: > // > > With the check above the message is: > ` Exception in thread "main" java.lang.IllegalAccessException: agent class of method NonPublicAgent.premain must be declared public` > > Please, let me know what you think. > > I've done some tests refactoring motivated by some private requests from Mandy. Will publish the update as soon as it is ready. Hopefully, today. The agent class doesn't have to be public it just has to be accessible. The premain method should be queried for public modifier rather than just relying on a failed invocation request. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From dholmes at openjdk.java.net Wed Dec 16 01:24:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 16 Dec 2020 01:24:56 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings In-Reply-To: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> Message-ID: <7m0k5-ugaD1RwS-8VJNngGyDF-suLk-YBkGa-MTHYCE=.168d9ee3-a897-4f19-bf05-18b3e7d28999@github.com> On Fri, 11 Dec 2020 17:25:33 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. > > I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. > > Without the patch I can consistently reproduce the issue. With the patch the test always passes. > > Thanks, > Patricio Changes requested by dholmes (Reviewer). test/lib/jdk/test/lib/process/OutputAnalyzer.java line 43: > 41: private static final String jvmwarningmsg = ".* VM warning:.*"; > 42: > 43: private static final String deprecatedmsg = ".* deprecated.*"; This might be too generic, perhaps combine it with "VM warning" so we don't get accidental hits on other deprecation output eg from javac? Also I'm not sure if only deprecation warnings should be handled but I guess we can adjust if that need arises. ------------- PR: https://git.openjdk.java.net/jdk/pull/1749 From sspitsyn at openjdk.java.net Wed Dec 16 01:35:56 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 16 Dec 2020 01:35:56 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On Wed, 16 Dec 2020 00:50:04 GMT, David Holmes wrote: >> Mandy, thank you for the suggestion. >> I'll retarget the bug and CSR to jdk 17 as nobody is objecting. >> >> Also, wanted to make it clear about Exception messages that are provided for two different cases. >> >> The test java/lang/instrument/NonPublicPremainAgent.java defines a non-public premain method: >> ` static void premain(String agentArgs, Instrumentation inst) {` >> >> With the m.canAccess check the following message is provided (it looks right): >> ` Exception in thread "main" java.lang.IllegalAccessException: method NonPublicPremainAgent.premain must be declared public ` >> >> Without this check the message was (not sure, it is good enough): >> ` Exception in thread "main" java.lang.IllegalAccessException: class sun.instrument.InstrumentationImpl (in module java.instrument) cannot access a member of class NonPublicPremainAgent with modifiers "static"` >> >> Also, I've added a new test java/lang/instrument/NonPublicAgent.java which defines a non-public agent class with a public premain method. >> >> With the m.canAccess check the following message is provided (it does not look right): >> ` Exception in thread "main" java.lang.IllegalAccessException: method NonPublicPremainAgent.premain must be declared public ` >> >> Without this check the message is (it looks pretty confusing): >> ` Exception in thread "main" java.lang.IllegalAccessException: class sun.instrument.InstrumentationImpl (in module java.instrument) cannot access a member of class NonPublicAgent with modifiers "public static"` >> >> So, it seems we also need an explicit check for agent class being public with a right message provided. >> I've added the following check: >> @@ -426,6 +426,12 @@ public class InstrumentationImpl implements Instrumentation { >> NoSuchMethodException firstExc = null; >> boolean twoArgAgent = false; >> >> + // reject non-public owner agent class of premain or agentmain method >> + if ((javaAgentClass.getModifiers() & java.lang.reflect.Modifier.PUBLIC) == 0) { >> + String msg = "agent class of method " + classname + "." + methodname + " must be declared public"; >> + throw new IllegalAccessException(msg); >> + } >> + >> // The agent class must have a premain or agentmain method that >> // has 1 or 2 arguments. We check in the following order: >> // >> >> With the check above the message is: >> ` Exception in thread "main" java.lang.IllegalAccessException: agent class of method NonPublicAgent.premain must be declared public` >> >> Please, let me know what you think. >> >> I've done some tests refactoring motivated by some private requests from Mandy. Will publish the update as soon as it is ready. Hopefully, today. > > The agent class doesn't have to be public it just has to be accessible. > > The premain method should be queried for public modifier rather than just relying on a failed invocation request. David, thank you for catching this. I'm probably missing something here. If the agent class is not public then the `m.canAccess(null)` check is not passed and IAE is thrown with the message: `Exception in thread "main" java.lang.IllegalAccessException: method NonPublicAgent.premain must be declared public` But the `NonPublicAgent.premain` is declared public as below: public static void premain(String agentArgs, Instrumentation inst) { System.out.println("premain: NonPublicAgent was loaded"); } It seems, the IAE is thrown because the agent class is not public. Does it mean the `m.canAccess(null)` check is not fully correct? ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From david.holmes at oracle.com Wed Dec 16 01:50:52 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Dec 2020 11:50:52 +1000 Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On 16/12/2020 11:35 am, Serguei Spitsyn wrote: > On Wed, 16 Dec 2020 00:50:04 GMT, David Holmes wrote: >> The agent class doesn't have to be public it just has to be accessible. >> >> The premain method should be queried for public modifier rather than just relying on a failed invocation request. > > David, thank you for catching this. I'm probably missing something here. > If the agent class is not public then the `m.canAccess(null)` check is not passed and IAE is thrown with the message: > `Exception in thread "main" java.lang.IllegalAccessException: method NonPublicAgent.premain must be declared public` > > But the `NonPublicAgent.premain` is declared public as below: > public static void premain(String agentArgs, Instrumentation inst) { > System.out.println("premain: NonPublicAgent was loaded"); > } > It seems, the IAE is thrown because the agent class is not public. > Does it mean the `m.canAccess(null)` check is not fully correct? canAccess will check both the type accessibility and the method accessibility. The premain class is not required to be public so it may not be right to checks its accessibility as that may fail even though the premain method is public and should be invoked. In that regard I think the setAccessible call has to remain to deal with this situation. So the process would be: - load premain class via appLoader - lookup premain method using getDeclaredMethod() - check premain method is public and reject if not - call setAccessible(true) in case premain class is not accessible - do invoke David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1694 > From david.holmes at oracle.com Wed Dec 16 02:09:06 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Dec 2020 12:09:06 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <6515a8b8-0c4a-d06a-af8e-a28a6c31d185@oss.nttdata.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> <6515a8b8-0c4a-d06a-af8e-a28a6c31d185@oss.nttdata.com> Message-ID: <82684a2f-5231-d64b-5175-8aa6c8e428e9@oracle.com> Hi Yasumasa, Sorry for the delay getting back to this. On 1/12/2020 4:41 pm, Yasumasa Suenaga wrote: > Hi David, > > On 2020/12/01 14:59, David Holmes wrote: >> Looking at the original webrev from September: >> >> https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExport.cpp.cdiff.html >> >> >> The suggestion to unload the library if Agent_OnAttach fails seems >> quite reasonable - it is what happens if no Agent_OnAttach function >> can be found in the agent. >> >> But the specification is lacking because it simply states any such >> error is "ignored" - which is an oversimplification and I think was >> really intended to contrast with the abort behaviour if Agent_OnLoad >> fails. In addition the specification indicates that Agent_OnUnload is >> called any time the agent library is unloaded, except for >> "uncontrolled shutdown". This unfortunately suggests that before >> unloading the library after OnAttach fails, we also call OnUnload. >> That seems wrong and in fact the VM does not do that - and noone seems >> to have complained. >> >> Also note the specification states an agent "must export a start-up >> function ..." but doesn't say what happens if it doesn't do so. >> >> My gut feeling for what the specification should say here is that if >> the start-up function does not exist, or the call to Agent_OnAttach >> reports an error, then the agent library is immediately unloaded with >> no attempt to call the agent shutdown function (Agent_OnUnload). > > That's what I wanted to suggest! > I understand we need to consider following case in this issue, is it right? > > Agent_OnLoad / Agent_OnLoad_L does not exist: > ??? - Agent_OnUnload is not called > ??? - DLL is not unloaded (JVM will abort) > > Agent_OnLoad / Agent_OnLoad_L failed: > ??? - Agent_OnUnload is not called > ??? - DLL is not unloaded (JVM will abort) These cases are already well covered. > Agent_OnAttach does not exist: > ??? - Agent_OnUnload is not called > ??? - DLL is unloaded > > Agent_OnAttach_L does not exist: > ??? - Agent_OnUnload is not called > ??? - DLL is not unloaded (static link) These cases are kind of implicitly covered, but could be clarified. > Agent_OnAttach failed: > ??? - Agent_OnUnload is not called > ??? - DLL is unloaded > > Agent_OnAttach_L faled: > ??? - Agent_OnUnload is not called > ??? - DLL is not unloaded (static link) These are the problematic cases. > >> But with my "compatibility glasses" on this may be too strong to >> retrofit to the specification as other VMs may behave differently. So >> as I stated in the CSR request we probably want to allow the current >> hotspot behaviour but not mandate it (unless we check with all the >> other VM implementations that such a specification is okay with them). > > Ok, for example, can we change the spec as following? > (Of course, this is not all) > > ``` > diff --git a/src/hotspot/share/prims/jvmti.xml > b/src/hotspot/share/prims/jvmti.xml > index 44553b8065f..57c87b1a71b 100644 > --- a/src/hotspot/share/prims/jvmti.xml > +++ b/src/hotspot/share/prims/jvmti.xml > @@ -688,7 +688,8 @@ Agent_OnUnload_L(JavaVM *vm) > ???? mechanism causes the unload (an unload mechanism is not specified > in this document) > ???? or the library is (in effect) unloaded by the termination of the > VM whether through > ???? normal termination or VM failure, including start-up failure. > -??? Uncontrolled shutdown is, of course, an exception to this rule. > +??? Uncontrolled shutdown is, of course, an exception to this rule, and > also it might not be called > +??? when start-up function does not exist or fails (returns non-zero > value). I think this is what was originally proposed and as I said then I don't like burying this detail inside the reference to uncontrolled shutdown. We should make this much more explicit which requires some reworking of the existing far-too-long sentence. "This function will be called by the VM when the library is about to be unloaded. The library will be unloaded (unless it is statically linked into the executable) and this function will be called if some platform specific mechanism causes the unload (an unload mechanism is not specified in this document) or the library is (in effect) unloaded by the termination of the VM. VM termination includes normal termination and VM failure, including start-up failure, but not, of course, uncontrolled shutdown. An implementation may also choose to not call this function if the Agent_OnAttach/Agent_OnAttach_L function reported an error (returned a non-zero value)." Cheers, David ----- > ???? Note the distinction between this function and the > ???? VM Death event: for the VM > Death event > ???? to be sent, the VM must have run at least to the point of > initialization and a valid > ``` > >> I agree that the more general issue of re-loading an agent is a >> separate issue. > > Thanks! > > > Yasumasa > > >> David >> ----- >> >> On 1/12/2020 3:21 pm, David Holmes wrote: >>> On 1/12/2020 3:19 pm, David Holmes wrote: >>>> On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >>>>> Hi Chris, David, >>>>> >>>>> Currently Agent_OnUnload() is not called when Agent_OnLoad() is >>>>> failed - JVM will abort. >>>>> Should we re-think this behavior? >>>> >>>> We should we rethink that? It is probably one of the clearest parts >>>> of the spec. If Agent_Onload fails that is considered a fatal error >>>> - end of story. >>> >>> I meant, of course, "Why should we rethink that?". >>> >>> David >>> >>>> The issue is with Agent_onAttach and how its failure should, or >>>> should not, impact Agent_OnUnload. >>>> >>>> David >>>> ----- >>>> >>>>> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >>>>> >>>>> ``` >>>>> $ java -agentpath:/path/to/libhelloworld.so=error --version >>>>> Hello World from Agent_OnLoad() >>>>> ?? options = error >>>>> Error occurred during initialization of VM >>>>> agent library failed to init: /path/to/libhelloworld.so >>>>> ``` >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2020/12/01 11:44, David Holmes wrote: >>>>>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>>>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga >>>>>>> wrote: >>>>>>> >>>>>>>>> * Q3: What has to be done for statically linked agent? >>>>>>>> >>>>>>>> JVMTI spec says "unless it is statically linked into the >>>>>>>> executable", so I think we can ignore about Agent_OnUnload_L() >>>>>>>> in this PR. >>>>>>> >>>>>>> I don't think that makes sense. If you call it for dynamically >>>>>>> linked then you need to call it for statically linked also. >>>>>> >>>>>> Agreed. Even though you can't physically unload the statically >>>>>> linked library, if it is logically unloaded by some mechanism, >>>>>> then Agent_OnUnload_L is supposed to be called. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> ------------- >>>>>>> >>>>>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>>>>> From sspitsyn at openjdk.java.net Wed Dec 16 02:25:55 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 16 Dec 2020 02:25:55 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On Wed, 16 Dec 2020 01:32:53 GMT, Serguei Spitsyn wrote: >> The agent class doesn't have to be public it just has to be accessible. >> >> The premain method should be queried for public modifier rather than just relying on a failed invocation request. > > David, thank you for catching this. I'm probably missing something here. > If the agent class is not public then the `m.canAccess(null)` check is not passed and IAE is thrown with the message: > `Exception in thread "main" java.lang.IllegalAccessException: method NonPublicAgent.premain must be declared public` > > But the `NonPublicAgent.premain` is declared public as below: > public static void premain(String agentArgs, Instrumentation inst) { > System.out.println("premain: NonPublicAgent was loaded"); > } > It seems, the IAE is thrown because the agent class is not public. > Does it mean the `m.canAccess(null)` check is not fully correct? Thanks, David! Yes, I was also thinking that the setAccessible has to be remained after all the checks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From mandy.chung at oracle.com Wed Dec 16 02:54:58 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Dec 2020 18:54:58 -0800 Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On 12/15/20 5:50 PM, David Holmes wrote: > On 16/12/2020 11:35 am, Serguei Spitsyn wrote: >> On Wed, 16 Dec 2020 00:50:04 GMT, David Holmes >> wrote: >>> The agent class doesn't have to be public it just has to be accessible. >>> >>> The premain method should be queried for public modifier rather than >>> just relying on a failed invocation request. >> >> David, thank you for catching this. I'm probably missing something here. >> If the agent class is not public then the `m.canAccess(null)` check >> is not passed and IAE is thrown with the message: >> ?? `Exception in thread "main" java.lang.IllegalAccessException: >> method NonPublicAgent.premain must be declared public` >> >> But the `NonPublicAgent.premain` is declared public as below: >> ???? public static void premain(String agentArgs, Instrumentation >> inst) { >> ???????? System.out.println("premain: NonPublicAgent was loaded"); >> ???? } >> It seems, the IAE is thrown because the agent class is not public. >> Does it mean the `m.canAccess(null)` check is not fully correct? > > canAccess will check both the type accessibility and the method > accessibility. > > The premain class is not required to be public (I think you meant "exported"). The premain method must be public as this issue about.?? I expect the agent module must export the package of the Premain-Class (or Agent-Class) premain method (qualifiedly or unconditionally) for java.instrument to access.? The spec does not state clearly if the agent class is public but as it requires the premain method public, it is sensible to say it's accessible (otherwise, premain method does not have to be public), i.e. public premain method in a public (accessible) class).? ? So in the modular world, the public method in a public class in a package exported at least to java.instrument. Are you expecting differently? The spec should clarify.? FWIW.? I just realized that https://bugs.openjdk.java.net/browse/JDK-6932391 is not resolved. > so it may not be right to checks its accessibility as that may fail > even though the premain method is public and should be invoked. In > that regard I think the setAccessible call has to remain to deal with > this situation. So the process would be: > > - load premain class via appLoader > - lookup premain method using getDeclaredMethod() > - check premain method is public and reject if not > - call setAccessible(true) in case premain class is not accessible > - do invoke > > David Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Dec 16 04:32:53 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Dec 2020 14:32:53 +1000 Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: Hi Mandy, On 16/12/2020 12:54 pm, Mandy Chung wrote: > > > On 12/15/20 5:50 PM, David Holmes wrote: >> On 16/12/2020 11:35 am, Serguei Spitsyn wrote: >>> On Wed, 16 Dec 2020 00:50:04 GMT, David Holmes >>> wrote: >>>> The agent class doesn't have to be public it just has to be accessible. >>>> >>>> The premain method should be queried for public modifier rather than >>>> just relying on a failed invocation request. >>> >>> David, thank you for catching this. I'm probably missing something here. >>> If the agent class is not public then the `m.canAccess(null)` check >>> is not passed and IAE is thrown with the message: >>> ?? `Exception in thread "main" java.lang.IllegalAccessException: >>> method NonPublicAgent.premain must be declared public` >>> >>> But the `NonPublicAgent.premain` is declared public as below: >>> ???? public static void premain(String agentArgs, Instrumentation >>> inst) { >>> ???????? System.out.println("premain: NonPublicAgent was loaded"); >>> ???? } >>> It seems, the IAE is thrown because the agent class is not public. >>> Does it mean the `m.canAccess(null)` check is not fully correct? >> >> canAccess will check both the type accessibility and the method >> accessibility. >> >> The premain class is not required to be public > > (I think you meant "exported"). No I meant "public" in the context of the earlier issue that relaxed that constraint. > > The premain method must be public as this issue about.?? I expect the > agent module must export the package of the Premain-Class (or > Agent-Class) premain method (qualifiedly or unconditionally) for > java.instrument to access.? The spec does not state clearly if the agent > class is public but as it requires the premain method public, it is > sensible to say it's accessible (otherwise, premain method does not have > to be public), i.e. public premain method in a public (accessible) > class).? ? So in the modular world, the public method in a public class > in a package exported at least to java.instrument. > > Are you expecting differently? There are two issues: 1. What does the spec say about the premain class and the premain method For the method it says it must be public - hence this issue. For the class it says nothing and we know we've previously relaxed a check that forced it to be public when not required by the spec. 2. What accessibility will allow the instrumentation code to actually call the premain method? In a modular world this likely means the premain class must be exported somehow. That might mean it is public in an exported package, or perhaps it may mean that the appropriate --add-opens has been added to the command-line; or that it has been explicitly exported to allow access from the instrumentation package. I'm not at all clear which checks in a modular world can be circumvented by calling setAccessible(true), but I'm assuming that at least some scenario can be handled by continuing to use that. If after calling setAccessible(true) we still get an IllegalAccessException for a public premain method then we can give some general error message about the premain class needing to be accessible to the instrumentation package. Cheers, David ----- > The spec should clarify.? FWIW.? I just realized that > https://bugs.openjdk.java.net/browse/JDK-6932391 is not resolved. > > >> so it may not be right to checks its accessibility as that may fail >> even though the premain method is public and should be invoked. In >> that regard I think the setAccessible call has to remain to deal with >> this situation. So the process would be: >> >> - load premain class via appLoader >> - lookup premain method using getDeclaredMethod() >> - check premain method is public and reject if not >> - call setAccessible(true) in case premain class is not accessible >> - do invoke >> >> David > > Mandy > > From suenaga at oss.nttdata.com Wed Dec 16 06:33:16 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 16 Dec 2020 15:33:16 +0900 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <82684a2f-5231-d64b-5175-8aa6c8e428e9@oracle.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> <6515a8b8-0c4a-d06a-af8e-a28a6c31d185@oss.nttdata.com> <82684a2f-5231-d64b-5175-8aa6c8e428e9@oracle.com> Message-ID: <93e65fc1-3052-706e-cabf-fb1ff4f7f895@oss.nttdata.com> Hi David, > "This function will be called by the VM when the library is about to be unloaded. The library will be unloaded (unless it is statically linked into the executable) and this function will be called if some platform specific mechanism causes the unload (an unload mechanism is not specified in this document) or the library is (in effect) unloaded by the termination of the VM. VM termination includes normal termination and VM failure, including start-up failure, but not, of course, uncontrolled shutdown. An implementation may also choose to not call this function if the Agent_OnAttach/Agent_OnAttach_L function reported an error (returned a non-zero value)." Thank you so much! According to this, we can fix this bug simply. (We can unload agent library without `Agent_OnUnload()` call) However I think following sentence should be removed because DLL unloading mechanism is not hooked, and also `Agent_OnUnload()` wouldn't be called by dll unloading - it depends on VM termination / failure / non-zero value from entry points. "this function will be called if some platform specific mechanism causes the unload (an unload mechanism is not specified in this document)" If you are OK, I will update CSR. Cheers, Yasumasa On 2020/12/16 11:09, David Holmes wrote: > Hi Yasumasa, > > Sorry for the delay getting back to this. > > On 1/12/2020 4:41 pm, Yasumasa Suenaga wrote: >> Hi David, >> >> On 2020/12/01 14:59, David Holmes wrote: >>> Looking at the original webrev from September: >>> >>> https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExport.cpp.cdiff.html >>> >>> The suggestion to unload the library if Agent_OnAttach fails seems quite reasonable - it is what happens if no Agent_OnAttach function can be found in the agent. >>> >>> But the specification is lacking because it simply states any such error is "ignored" - which is an oversimplification and I think was really intended to contrast with the abort behaviour if Agent_OnLoad fails. In addition the specification indicates that Agent_OnUnload is called any time the agent library is unloaded, except for "uncontrolled shutdown". This unfortunately suggests that before unloading the library after OnAttach fails, we also call OnUnload. That seems wrong and in fact the VM does not do that - and noone seems to have complained. >>> >>> Also note the specification states an agent "must export a start-up function ..." but doesn't say what happens if it doesn't do so. >>> >>> My gut feeling for what the specification should say here is that if the start-up function does not exist, or the call to Agent_OnAttach reports an error, then the agent library is immediately unloaded with no attempt to call the agent shutdown function (Agent_OnUnload). >> >> That's what I wanted to suggest! >> I understand we need to consider following case in this issue, is it right? >> >> Agent_OnLoad / Agent_OnLoad_L does not exist: >> ???? - Agent_OnUnload is not called >> ???? - DLL is not unloaded (JVM will abort) >> >> Agent_OnLoad / Agent_OnLoad_L failed: >> ???? - Agent_OnUnload is not called >> ???? - DLL is not unloaded (JVM will abort) > > These cases are already well covered. > >> Agent_OnAttach does not exist: >> ???? - Agent_OnUnload is not called >> ???? - DLL is unloaded >> >> Agent_OnAttach_L does not exist: >> ???? - Agent_OnUnload is not called >> ???? - DLL is not unloaded (static link) > > These cases are kind of implicitly covered, but could be clarified. > >> Agent_OnAttach failed: >> ???? - Agent_OnUnload is not called >> ???? - DLL is unloaded >> >> Agent_OnAttach_L faled: >> ???? - Agent_OnUnload is not called >> ???? - DLL is not unloaded (static link) > > These are the problematic cases. > >> >>> But with my "compatibility glasses" on this may be too strong to retrofit to the specification as other VMs may behave differently. So as I stated in the CSR request we probably want to allow the current hotspot behaviour but not mandate it (unless we check with all the other VM implementations that such a specification is okay with them). >> >> Ok, for example, can we change the spec as following? >> (Of course, this is not all) >> >> ``` >> diff --git a/src/hotspot/share/prims/jvmti.xml b/src/hotspot/share/prims/jvmti.xml >> index 44553b8065f..57c87b1a71b 100644 >> --- a/src/hotspot/share/prims/jvmti.xml >> +++ b/src/hotspot/share/prims/jvmti.xml >> @@ -688,7 +688,8 @@ Agent_OnUnload_L(JavaVM *vm) >> ????? mechanism causes the unload (an unload mechanism is not specified in this document) >> ????? or the library is (in effect) unloaded by the termination of the VM whether through >> ????? normal termination or VM failure, including start-up failure. >> -??? Uncontrolled shutdown is, of course, an exception to this rule. >> +??? Uncontrolled shutdown is, of course, an exception to this rule, and also it might not be called >> +??? when start-up function does not exist or fails (returns non-zero value). > > I think this is what was originally proposed and as I said then I don't like burying this detail inside the reference to uncontrolled shutdown. We should make this much more explicit which requires some reworking of the existing far-too-long sentence. > > "This function will be called by the VM when the library is about to be unloaded. The library will be unloaded (unless it is statically linked into the executable) and this function will be called if some platform specific mechanism causes the unload (an unload mechanism is not specified in this document) or the library is (in effect) unloaded by the termination of the VM. VM termination includes normal termination and VM failure, including start-up failure, but not, of course, uncontrolled shutdown. An implementation may also choose to not call this function if the Agent_OnAttach/Agent_OnAttach_L function reported an error (returned a non-zero value)." > > Cheers, > David > ----- > >> ????? Note the distinction between this function and the >> ????? VM Death event: for the VM Death event >> ????? to be sent, the VM must have run at least to the point of initialization and a valid >> ``` >> >>> I agree that the more general issue of re-loading an agent is a separate issue. >> >> Thanks! >> >> >> Yasumasa >> >> >>> David >>> ----- >>> >>> On 1/12/2020 3:21 pm, David Holmes wrote: >>>> On 1/12/2020 3:19 pm, David Holmes wrote: >>>>> On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >>>>>> Hi Chris, David, >>>>>> >>>>>> Currently Agent_OnUnload() is not called when Agent_OnLoad() is failed - JVM will abort. >>>>>> Should we re-think this behavior? >>>>> >>>>> We should we rethink that? It is probably one of the clearest parts of the spec. If Agent_Onload fails that is considered a fatal error - end of story. >>>> >>>> I meant, of course, "Why should we rethink that?". >>>> >>>> David >>>> >>>>> The issue is with Agent_onAttach and how its failure should, or should not, impact Agent_OnUnload. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >>>>>> >>>>>> ``` >>>>>> $ java -agentpath:/path/to/libhelloworld.so=error --version >>>>>> Hello World from Agent_OnLoad() >>>>>> ?? options = error >>>>>> Error occurred during initialization of VM >>>>>> agent library failed to init: /path/to/libhelloworld.so >>>>>> ``` >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2020/12/01 11:44, David Holmes wrote: >>>>>>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>>>>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga wrote: >>>>>>>> >>>>>>>>>> * Q3: What has to be done for statically linked agent? >>>>>>>>> >>>>>>>>> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. >>>>>>>> >>>>>>>> I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. >>>>>>> >>>>>>> Agreed. Even though you can't physically unload the statically linked library, if it is logically unloaded by some mechanism, then Agent_OnUnload_L is supposed to be called. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> ------------- >>>>>>>> >>>>>>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>>>>>> From david.holmes at oracle.com Wed Dec 16 06:48:49 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Dec 2020 16:48:49 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <93e65fc1-3052-706e-cabf-fb1ff4f7f895@oss.nttdata.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> <6515a8b8-0c4a-d06a-af8e-a28a6c31d185@oss.nttdata.com> <82684a2f-5231-d64b-5175-8aa6c8e428e9@oracle.com> <93e65fc1-3052-706e-cabf-fb1ff4f7f895@oss.nttdata.com> Message-ID: <6e375192-bb36-3888-58b1-5cdc52688b08@oracle.com> On 16/12/2020 4:33 pm, Yasumasa Suenaga wrote: > Hi David, > >> "This function will be called by the VM when the library is about to >> be unloaded. The library will be unloaded (unless it is statically >> linked into the executable) and this function will be called if some >> platform specific mechanism causes the unload (an unload mechanism is >> not specified in this document) or the library is (in effect) unloaded >> by the termination of the VM. VM termination includes normal >> termination and VM failure, including start-up failure, but not, of >> course, uncontrolled shutdown. An implementation may also choose to >> not call this function if the Agent_OnAttach/Agent_OnAttach_L function >> reported an error (returned a non-zero value)." > > Thank you so much! > According to this, we can fix this bug simply. (We can unload agent > library without `Agent_OnUnload()` call) Yes I think it is reasonable to allow this. But of course there must be a general consensus. > However I think following sentence should be removed because DLL > unloading mechanism is not hooked, and also `Agent_OnUnload()` wouldn't > be called by dll unloading - it depends on VM termination / failure / > non-zero value from entry points. > > "this function will be called if some platform specific mechanism causes > the unload (an unload mechanism is not specified in this document)" I'm not sure you mean exactly by DLL unloading mechanism is not hooked. But that sentence has to remain because it makes it clear that the decision as to when unloading occurs is up to an implementation and is not defined by the specification. Cheers, David ----- > > If you are OK, I will update CSR. > > > Cheers, > > Yasumasa > > > On 2020/12/16 11:09, David Holmes wrote: >> Hi Yasumasa, >> >> Sorry for the delay getting back to this. >> >> On 1/12/2020 4:41 pm, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> On 2020/12/01 14:59, David Holmes wrote: >>>> Looking at the original webrev from September: >>>> >>>> https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExport.cpp.cdiff.html >>>> >>>> >>>> The suggestion to unload the library if Agent_OnAttach fails seems >>>> quite reasonable - it is what happens if no Agent_OnAttach function >>>> can be found in the agent. >>>> >>>> But the specification is lacking because it simply states any such >>>> error is "ignored" - which is an oversimplification and I think was >>>> really intended to contrast with the abort behaviour if Agent_OnLoad >>>> fails. In addition the specification indicates that Agent_OnUnload >>>> is called any time the agent library is unloaded, except for >>>> "uncontrolled shutdown". This unfortunately suggests that before >>>> unloading the library after OnAttach fails, we also call OnUnload. >>>> That seems wrong and in fact the VM does not do that - and noone >>>> seems to have complained. >>>> >>>> Also note the specification states an agent "must export a start-up >>>> function ..." but doesn't say what happens if it doesn't do so. >>>> >>>> My gut feeling for what the specification should say here is that if >>>> the start-up function does not exist, or the call to Agent_OnAttach >>>> reports an error, then the agent library is immediately unloaded >>>> with no attempt to call the agent shutdown function (Agent_OnUnload). >>> >>> That's what I wanted to suggest! >>> I understand we need to consider following case in this issue, is it >>> right? >>> >>> Agent_OnLoad / Agent_OnLoad_L does not exist: >>> ???? - Agent_OnUnload is not called >>> ???? - DLL is not unloaded (JVM will abort) >>> >>> Agent_OnLoad / Agent_OnLoad_L failed: >>> ???? - Agent_OnUnload is not called >>> ???? - DLL is not unloaded (JVM will abort) >> >> These cases are already well covered. >> >>> Agent_OnAttach does not exist: >>> ???? - Agent_OnUnload is not called >>> ???? - DLL is unloaded >>> >>> Agent_OnAttach_L does not exist: >>> ???? - Agent_OnUnload is not called >>> ???? - DLL is not unloaded (static link) >> >> These cases are kind of implicitly covered, but could be clarified. >> >>> Agent_OnAttach failed: >>> ???? - Agent_OnUnload is not called >>> ???? - DLL is unloaded >>> >>> Agent_OnAttach_L faled: >>> ???? - Agent_OnUnload is not called >>> ???? - DLL is not unloaded (static link) >> >> These are the problematic cases. >> >>> >>>> But with my "compatibility glasses" on this may be too strong to >>>> retrofit to the specification as other VMs may behave differently. >>>> So as I stated in the CSR request we probably want to allow the >>>> current hotspot behaviour but not mandate it (unless we check with >>>> all the other VM implementations that such a specification is okay >>>> with them). >>> >>> Ok, for example, can we change the spec as following? >>> (Of course, this is not all) >>> >>> ``` >>> diff --git a/src/hotspot/share/prims/jvmti.xml >>> b/src/hotspot/share/prims/jvmti.xml >>> index 44553b8065f..57c87b1a71b 100644 >>> --- a/src/hotspot/share/prims/jvmti.xml >>> +++ b/src/hotspot/share/prims/jvmti.xml >>> @@ -688,7 +688,8 @@ Agent_OnUnload_L(JavaVM *vm) >>> ????? mechanism causes the unload (an unload mechanism is not >>> specified in this document) >>> ????? or the library is (in effect) unloaded by the termination of >>> the VM whether through >>> ????? normal termination or VM failure, including start-up failure. >>> -??? Uncontrolled shutdown is, of course, an exception to this rule. >>> +??? Uncontrolled shutdown is, of course, an exception to this rule, >>> and also it might not be called >>> +??? when start-up function does not exist or fails (returns non-zero >>> value). >> >> I think this is what was originally proposed and as I said then I >> don't like burying this detail inside the reference to uncontrolled >> shutdown. We should make this much more explicit which requires some >> reworking of the existing far-too-long sentence. >> >> "This function will be called by the VM when the library is about to >> be unloaded. The library will be unloaded (unless it is statically >> linked into the executable) and this function will be called if some >> platform specific mechanism causes the unload (an unload mechanism is >> not specified in this document) or the library is (in effect) unloaded >> by the termination of the VM. VM termination includes normal >> termination and VM failure, including start-up failure, but not, of >> course, uncontrolled shutdown. An implementation may also choose to >> not call this function if the Agent_OnAttach/Agent_OnAttach_L function >> reported an error (returned a non-zero value)." >> >> Cheers, >> David >> ----- >> >>> ????? Note the distinction between this function and the >>> ????? VM Death event: for the VM >>> Death event >>> ????? to be sent, the VM must have run at least to the point of >>> initialization and a valid >>> ``` >>> >>>> I agree that the more general issue of re-loading an agent is a >>>> separate issue. >>> >>> Thanks! >>> >>> >>> Yasumasa >>> >>> >>>> David >>>> ----- >>>> >>>> On 1/12/2020 3:21 pm, David Holmes wrote: >>>>> On 1/12/2020 3:19 pm, David Holmes wrote: >>>>>> On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >>>>>>> Hi Chris, David, >>>>>>> >>>>>>> Currently Agent_OnUnload() is not called when Agent_OnLoad() is >>>>>>> failed - JVM will abort. >>>>>>> Should we re-think this behavior? >>>>>> >>>>>> We should we rethink that? It is probably one of the clearest >>>>>> parts of the spec. If Agent_Onload fails that is considered a >>>>>> fatal error - end of story. >>>>> >>>>> I meant, of course, "Why should we rethink that?". >>>>> >>>>> David >>>>> >>>>>> The issue is with Agent_onAttach and how its failure should, or >>>>>> should not, impact Agent_OnUnload. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >>>>>>> >>>>>>> ``` >>>>>>> $ java -agentpath:/path/to/libhelloworld.so=error --version >>>>>>> Hello World from Agent_OnLoad() >>>>>>> ?? options = error >>>>>>> Error occurred during initialization of VM >>>>>>> agent library failed to init: /path/to/libhelloworld.so >>>>>>> ``` >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2020/12/01 11:44, David Holmes wrote: >>>>>>>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>>>>>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>>> * Q3: What has to be done for statically linked agent? >>>>>>>>>> >>>>>>>>>> JVMTI spec says "unless it is statically linked into the >>>>>>>>>> executable", so I think we can ignore about Agent_OnUnload_L() >>>>>>>>>> in this PR. >>>>>>>>> >>>>>>>>> I don't think that makes sense. If you call it for dynamically >>>>>>>>> linked then you need to call it for statically linked also. >>>>>>>> >>>>>>>> Agreed. Even though you can't physically unload the statically >>>>>>>> linked library, if it is logically unloaded by some mechanism, >>>>>>>> then Agent_OnUnload_L is supposed to be called. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> ------------- >>>>>>>>> >>>>>>>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>>>>>>> From alanb at openjdk.java.net Wed Dec 16 07:13:58 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 16 Dec 2020 07:13:58 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v4] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 23:14:14 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > improve SERIAL_FILTER_PATTERN comment Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/java/util/Locale.java line 1649: > 1647: *

This implements the 'Language-Tag' production of BCP47, and > 1648: * so supports legacy (regular and irregular, referred to as > 1649: * {@code Type: grandfathered} in BCP47) as well as You might consider putting quotes around "Type; grandfathered" here, otherwise looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From sspitsyn at openjdk.java.net Wed Dec 16 07:31:28 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 16 Dec 2020 07:31:28 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v5] In-Reply-To: References: Message-ID: <3bzBMMao3p7rKFdlgnDxoFyB91_ALkZkJXpZ_dAoWMI=.a3edf316-5be9-4afc-b660-42f2caad3472@github.com> > This change have been already reviewed by Mandy, Sundar, Alan and David. > Please, see the jdk 15 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html > > Now, the PR approval is needed. > The push was postponed because the CSR was not approved at that time (it is now): > https://bugs.openjdk.java.net/browse/JDK-8248189 > Investigation of existing popular java agents was requested by Joe. > ---------- > > The java.lang.instrument spec: > https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html > > Summary: > The java.lang.instrument spec clearly states: > "The agent class must implement a public static premain method > similar in principle to the main application entry point." > Current implementation of sun/instrument/InstrumentationImpl.java > allows the premain method be non-public which violates the spec. > This fix aligns the implementation with the spec. > > Testing: > A mach5 run of jdk_instrument tests is in progress. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: (1) Update premain/agentmain method lookup; (2) refactored tests to get rid of shell scripts ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1694/files - new: https://git.openjdk.java.net/jdk/pull/1694/files/877ce70b..e0dc4e2f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=03-04 Stats: 945 lines in 32 files changed: 381 ins; 538 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/1694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1694/head:pull/1694 PR: https://git.openjdk.java.net/jdk/pull/1694 From suenaga at oss.nttdata.com Wed Dec 16 07:36:30 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 16 Dec 2020 16:36:30 +0900 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <6e375192-bb36-3888-58b1-5cdc52688b08@oracle.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> <6515a8b8-0c4a-d06a-af8e-a28a6c31d185@oss.nttdata.com> <82684a2f-5231-d64b-5175-8aa6c8e428e9@oracle.com> <93e65fc1-3052-706e-cabf-fb1ff4f7f895@oss.nttdata.com> <6e375192-bb36-3888-58b1-5cdc52688b08@oracle.com> Message-ID: <2f67d06f-4345-0d10-89a8-906beadcd737@oss.nttdata.com> Hi David, > I'm not sure you mean exactly by DLL unloading mechanism is not hooked. I want to say we do not hook `FreeLibrary()` on Windows and `dlclose()` on Linux. Can we describe ""this function may be called - " at here? Cheers, Yasumasa On 2020/12/16 15:48, David Holmes wrote: > On 16/12/2020 4:33 pm, Yasumasa Suenaga wrote: >> Hi David, >> >>> "This function will be called by the VM when the library is about to be unloaded. The library will be unloaded (unless it is statically linked into the executable) and this function will be called if some platform specific mechanism causes the unload (an unload mechanism is not specified in this document) or the library is (in effect) unloaded by the termination of the VM. VM termination includes normal termination and VM failure, including start-up failure, but not, of course, uncontrolled shutdown. An implementation may also choose to not call this function if the Agent_OnAttach/Agent_OnAttach_L function reported an error (returned a non-zero value)." >> >> Thank you so much! >> According to this, we can fix this bug simply. (We can unload agent library without `Agent_OnUnload()` call) > > Yes I think it is reasonable to allow this. But of course there must be a general consensus. > >> However I think following sentence should be removed because DLL unloading mechanism is not hooked, and also `Agent_OnUnload()` wouldn't be called by dll unloading - it depends on VM termination / failure / non-zero value from entry points. >> >> "this function will be called if some platform specific mechanism causes the unload (an unload mechanism is not specified in this document)" > > I'm not sure you mean exactly by DLL unloading mechanism is not hooked. But that sentence has to remain because it makes it clear that the decision as to when unloading occurs is up to an implementation and is not defined by the specification. > > Cheers, > David > ----- > >> >> If you are OK, I will update CSR. >> >> >> Cheers, >> >> Yasumasa >> >> >> On 2020/12/16 11:09, David Holmes wrote: >>> Hi Yasumasa, >>> >>> Sorry for the delay getting back to this. >>> >>> On 1/12/2020 4:41 pm, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> On 2020/12/01 14:59, David Holmes wrote: >>>>> Looking at the original webrev from September: >>>>> >>>>> https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExport.cpp.cdiff.html >>>>> >>>>> The suggestion to unload the library if Agent_OnAttach fails seems quite reasonable - it is what happens if no Agent_OnAttach function can be found in the agent. >>>>> >>>>> But the specification is lacking because it simply states any such error is "ignored" - which is an oversimplification and I think was really intended to contrast with the abort behaviour if Agent_OnLoad fails. In addition the specification indicates that Agent_OnUnload is called any time the agent library is unloaded, except for "uncontrolled shutdown". This unfortunately suggests that before unloading the library after OnAttach fails, we also call OnUnload. That seems wrong and in fact the VM does not do that - and noone seems to have complained. >>>>> >>>>> Also note the specification states an agent "must export a start-up function ..." but doesn't say what happens if it doesn't do so. >>>>> >>>>> My gut feeling for what the specification should say here is that if the start-up function does not exist, or the call to Agent_OnAttach reports an error, then the agent library is immediately unloaded with no attempt to call the agent shutdown function (Agent_OnUnload). >>>> >>>> That's what I wanted to suggest! >>>> I understand we need to consider following case in this issue, is it right? >>>> >>>> Agent_OnLoad / Agent_OnLoad_L does not exist: >>>> ???? - Agent_OnUnload is not called >>>> ???? - DLL is not unloaded (JVM will abort) >>>> >>>> Agent_OnLoad / Agent_OnLoad_L failed: >>>> ???? - Agent_OnUnload is not called >>>> ???? - DLL is not unloaded (JVM will abort) >>> >>> These cases are already well covered. >>> >>>> Agent_OnAttach does not exist: >>>> ???? - Agent_OnUnload is not called >>>> ???? - DLL is unloaded >>>> >>>> Agent_OnAttach_L does not exist: >>>> ???? - Agent_OnUnload is not called >>>> ???? - DLL is not unloaded (static link) >>> >>> These cases are kind of implicitly covered, but could be clarified. >>> >>>> Agent_OnAttach failed: >>>> ???? - Agent_OnUnload is not called >>>> ???? - DLL is unloaded >>>> >>>> Agent_OnAttach_L faled: >>>> ???? - Agent_OnUnload is not called >>>> ???? - DLL is not unloaded (static link) >>> >>> These are the problematic cases. >>> >>>> >>>>> But with my "compatibility glasses" on this may be too strong to retrofit to the specification as other VMs may behave differently. So as I stated in the CSR request we probably want to allow the current hotspot behaviour but not mandate it (unless we check with all the other VM implementations that such a specification is okay with them). >>>> >>>> Ok, for example, can we change the spec as following? >>>> (Of course, this is not all) >>>> >>>> ``` >>>> diff --git a/src/hotspot/share/prims/jvmti.xml b/src/hotspot/share/prims/jvmti.xml >>>> index 44553b8065f..57c87b1a71b 100644 >>>> --- a/src/hotspot/share/prims/jvmti.xml >>>> +++ b/src/hotspot/share/prims/jvmti.xml >>>> @@ -688,7 +688,8 @@ Agent_OnUnload_L(JavaVM *vm) >>>> ????? mechanism causes the unload (an unload mechanism is not specified in this document) >>>> ????? or the library is (in effect) unloaded by the termination of the VM whether through >>>> ????? normal termination or VM failure, including start-up failure. >>>> -??? Uncontrolled shutdown is, of course, an exception to this rule. >>>> +??? Uncontrolled shutdown is, of course, an exception to this rule, and also it might not be called >>>> +??? when start-up function does not exist or fails (returns non-zero value). >>> >>> I think this is what was originally proposed and as I said then I don't like burying this detail inside the reference to uncontrolled shutdown. We should make this much more explicit which requires some reworking of the existing far-too-long sentence. >>> >>> "This function will be called by the VM when the library is about to be unloaded. The library will be unloaded (unless it is statically linked into the executable) and this function will be called if some platform specific mechanism causes the unload (an unload mechanism is not specified in this document) or the library is (in effect) unloaded by the termination of the VM. VM termination includes normal termination and VM failure, including start-up failure, but not, of course, uncontrolled shutdown. An implementation may also choose to not call this function if the Agent_OnAttach/Agent_OnAttach_L function reported an error (returned a non-zero value)." >>> >>> Cheers, >>> David >>> ----- >>> >>>> ????? Note the distinction between this function and the >>>> ????? VM Death event: for the VM Death event >>>> ????? to be sent, the VM must have run at least to the point of initialization and a valid >>>> ``` >>>> >>>>> I agree that the more general issue of re-loading an agent is a separate issue. >>>> >>>> Thanks! >>>> >>>> >>>> Yasumasa >>>> >>>> >>>>> David >>>>> ----- >>>>> >>>>> On 1/12/2020 3:21 pm, David Holmes wrote: >>>>>> On 1/12/2020 3:19 pm, David Holmes wrote: >>>>>>> On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >>>>>>>> Hi Chris, David, >>>>>>>> >>>>>>>> Currently Agent_OnUnload() is not called when Agent_OnLoad() is failed - JVM will abort. >>>>>>>> Should we re-think this behavior? >>>>>>> >>>>>>> We should we rethink that? It is probably one of the clearest parts of the spec. If Agent_Onload fails that is considered a fatal error - end of story. >>>>>> >>>>>> I meant, of course, "Why should we rethink that?". >>>>>> >>>>>> David >>>>>> >>>>>>> The issue is with Agent_onAttach and how its failure should, or should not, impact Agent_OnUnload. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >>>>>>>> >>>>>>>> ``` >>>>>>>> $ java -agentpath:/path/to/libhelloworld.so=error --version >>>>>>>> Hello World from Agent_OnLoad() >>>>>>>> ?? options = error >>>>>>>> Error occurred during initialization of VM >>>>>>>> agent library failed to init: /path/to/libhelloworld.so >>>>>>>> ``` >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2020/12/01 11:44, David Holmes wrote: >>>>>>>>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>>>>>>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>>>>>>>>> * Q3: What has to be done for statically linked agent? >>>>>>>>>>> >>>>>>>>>>> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. >>>>>>>>>> >>>>>>>>>> I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. >>>>>>>>> >>>>>>>>> Agreed. Even though you can't physically unload the statically linked library, if it is logically unloaded by some mechanism, then Agent_OnUnload_L is supposed to be called. >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> ------------- >>>>>>>>>> >>>>>>>>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>>>>>>>> From sspitsyn at openjdk.java.net Wed Dec 16 07:40:18 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 16 Dec 2020 07:40:18 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v6] In-Reply-To: References: Message-ID: <1OIKWhOS9mGS7aorWigp-Eavdn5szSzRitY8Fu9Ftm8=.8ed296ac-a21b-4e93-9d1a-4c83ff50a440@github.com> > This change have been already reviewed by Mandy, Sundar, Alan and David. > Please, see the jdk 15 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html > > Now, the PR approval is needed. > The push was postponed because the CSR was not approved at that time (it is now): > https://bugs.openjdk.java.net/browse/JDK-8248189 > Investigation of existing popular java agents was requested by Joe. > ---------- > > The java.lang.instrument spec: > https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html > > Summary: > The java.lang.instrument spec clearly states: > "The agent class must implement a public static premain method > similar in principle to the main application entry point." > Current implementation of sun/instrument/InstrumentationImpl.java > allows the premain method be non-public which violates the spec. > This fix aligns the implementation with the spec. > > Testing: > A mach5 run of jdk_instrument tests is in progress. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fixed trailing spaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1694/files - new: https://git.openjdk.java.net/jdk/pull/1694/files/e0dc4e2f..9b95b037 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=04-05 Stats: 6 lines in 5 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1694/head:pull/1694 PR: https://git.openjdk.java.net/jdk/pull/1694 From sspitsyn at openjdk.java.net Wed Dec 16 08:14:56 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 16 Dec 2020 08:14:56 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On Wed, 16 Dec 2020 02:23:33 GMT, Serguei Spitsyn wrote: >> David, thank you for catching this. I'm probably missing something here. >> If the agent class is not public then the `m.canAccess(null)` check is not passed and IAE is thrown with the message: >> `Exception in thread "main" java.lang.IllegalAccessException: method NonPublicAgent.premain must be declared public` >> >> But the `NonPublicAgent.premain` is declared public as below: >> public static void premain(String agentArgs, Instrumentation inst) { >> System.out.println("premain: NonPublicAgent was loaded"); >> } >> It seems, the IAE is thrown because the agent class is not public. >> Does it mean the `m.canAccess(null)` check is not fully correct? > > Thanks, David! > Yes, I was also thinking that the setAccessible has to be remained after all the checks. I've pushed an update with the following changes: - InstrumentationImpl.java update with the process sequence suggested by David. More specifically: the premain/agentmain method public modifier is checked instead of m.canAccess, after that if the agent class is not public then the setAccessible is called to make the method invokeable; - The tests are refactored (tried to implement suggestion from Mandy to simplify the tests). It includes: - new helper class are added to build agent jar file: `test/jdk/java/lang/instrument/AgentJarBuilder.java` - new helper class to run negative tests which are expected to throw an exception: `test/jdk/java/lang/instrument/NegativeAgentRunner.java` - introduced in the first push new shell script is removed: `test/jdk/java/lang/instrument/PremainClass/MakeJAR.sh` - the test runners with names *Test.java are removed, all the tests use jtreg commands instead (negative tests now use the NegativeAgentRunner) - the test `test/jdk/java/lang/instrument/NonPublicPremainAgent.java` is moved to the PremainClass sub-folder It might make sense to remove previously added public modifiers to several agent classes. However, I've decided to skip it for now. Please, let me know if you think it is desired thing to do. Mandy also suggested to consider using the exception message format produced by thrown by `jdk.internal.reflect.Reflection::newIllegalAccessException`. It looks like this: `Exception in thread "main" java.lang.IllegalAccessException: class sun.instrument.InstrumentationImpl (in module java.instrument) cannot access a member of class NonPublicAgent with modifiers "public static"`. Please, let me know if this format would be better. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From alanb at openjdk.java.net Wed Dec 16 08:21:57 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 16 Dec 2020 08:21:57 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On Wed, 16 Dec 2020 08:11:44 GMT, Serguei Spitsyn wrote: >> Thanks, David! >> Yes, I was also thinking that the setAccessible has to be remained after all the checks. > > I've pushed an update with the following changes: > - InstrumentationImpl.java update with the process sequence suggested by David. More specifically: the premain/agentmain method public modifier is checked instead of m.canAccess, after that if the agent class is not public then the setAccessible is called to make the method invokeable; > - The tests are refactored (tried to implement suggestion from Mandy to simplify the tests). It includes: > - new helper class are added to build agent jar file: `test/jdk/java/lang/instrument/AgentJarBuilder.java` > - new helper class to run negative tests which are expected to throw an exception: `test/jdk/java/lang/instrument/NegativeAgentRunner.java` > - introduced in the first push new shell script is removed: `test/jdk/java/lang/instrument/PremainClass/MakeJAR.sh` > - the test runners with names *Test.java are removed, all the tests use jtreg commands instead (negative tests now use the NegativeAgentRunner) > - the test `test/jdk/java/lang/instrument/NonPublicPremainAgent.java` is moved to the PremainClass sub-folder > - added new test to provide test coverage for non-public agent class: > `test/jdk/java/lang/instrument/PremainClass/NonPublicAgent.java` > It might make sense to remove previously added public modifiers to several agent classes. However, I've decided to skip it for now. Please, let me know if you think it is desired thing to do. > Mandy also suggested to consider using the exception message format produced by thrown by `jdk.internal.reflect.Reflection::newIllegalAccessException`. It looks like this: `Exception in thread "main" java.lang.IllegalAccessException: class sun.instrument.InstrumentationImpl (in module java.instrument) cannot access a member of class NonPublicAgent with modifiers "public static"`. Please, let me know if this format would be better. > > Please, let me know if I missed anything. I feel that at least one more iteration will be needed anyway. Mandy is correct, the bigger picture here is accessibility. Code in the java.instrument module should be able to invoke the premain or agentmain without needing to suppress access checks. It's a perquisite to supporting the deployment of java agents as modules. When an agent is deployed as a module it will need the agent class to be public in a package that is exported to at least the java.instrument module. The premain method will need to be public too. So PR1694 is really just about aligning the spec so that the premain method is public. However, it does not fix the overall accessibility issue. Fixing the accessibility issue will fixing the java.lang.instrument package description to specify that the agent class is public. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From ysuenaga at openjdk.java.net Wed Dec 16 13:11:05 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 16 Dec 2020 13:11:05 GMT Subject: RFR: 8258471: "search codecache" clhsdb command does not work Message-ID: `search codecache` command does not work as following: hsdb> search codecache 0x7fedbd0aec90 java.lang.RuntimeException: Unable to deduce type of CodeBlob from address 0x00007fedbc85e810 (expected type nmethod, RuntimeStub, SafepointBlob, DeoptimizationBlob, or ExceptionBlob) at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.createCodeBlobWrapper(CodeCache.java:177) at jdk.hotspot.agent/sun.jvm.hotspot.memory.CodeHeap.iterate(CodeHeap.java:111) at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.iterate(CodeCache.java:185) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$40.doit(CommandProcessor.java:1535) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2051) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2021) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1901) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:280) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:483) I checked the Object which points 0x7fedbd0aec90, it was `VtableBlob`. It has been introduced in [JDK-8199406](https://bugs.openjdk.java.net/browse/JDK-8199406), but it did not change SA code. SA should support `VtableBlob`. ------------- Commit messages: - 8258471: "search codecache" clhsdb command does not work Changes: https://git.openjdk.java.net/jdk/pull/1800/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1800&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258471 Stats: 47 lines in 3 files changed: 46 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1800.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1800/head:pull/1800 PR: https://git.openjdk.java.net/jdk/pull/1800 From mchung at openjdk.java.net Wed Dec 16 19:07:04 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 16 Dec 2020 19:07:04 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v6] In-Reply-To: <1OIKWhOS9mGS7aorWigp-Eavdn5szSzRitY8Fu9Ftm8=.8ed296ac-a21b-4e93-9d1a-4c83ff50a440@github.com> References: <1OIKWhOS9mGS7aorWigp-Eavdn5szSzRitY8Fu9Ftm8=.8ed296ac-a21b-4e93-9d1a-4c83ff50a440@github.com> Message-ID: On Wed, 16 Dec 2020 07:40:18 GMT, Serguei Spitsyn wrote: >> This change have been already reviewed by Mandy, Sundar, Alan and David. >> Please, see the jdk 15 review thread: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html >> >> Now, the PR approval is needed. >> The push was postponed because the CSR was not approved at that time (it is now): >> https://bugs.openjdk.java.net/browse/JDK-8248189 >> Investigation of existing popular java agents was requested by Joe. >> ---------- >> >> The java.lang.instrument spec: >> https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html >> >> Summary: >> The java.lang.instrument spec clearly states: >> "The agent class must implement a public static premain method >> similar in principle to the main application entry point." >> Current implementation of sun/instrument/InstrumentationImpl.java >> allows the premain method be non-public which violates the spec. >> This fix aligns the implementation with the spec. >> >> Testing: >> A mach5 run of jdk_instrument tests is in progress. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fixed trailing spaces test/jdk/java/lang/instrument/NegativeAgentRunner.java line 42: > 40: agentClassName); > 41: OutputAnalyzer output = new OutputAnalyzer(pb.start()); > 42: output.shouldContain(excepClassName); This should also check if the exit value is non-zero. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From mchung at openjdk.java.net Wed Dec 16 19:12:00 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 16 Dec 2020 19:12:00 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v6] In-Reply-To: <1OIKWhOS9mGS7aorWigp-Eavdn5szSzRitY8Fu9Ftm8=.8ed296ac-a21b-4e93-9d1a-4c83ff50a440@github.com> References: <1OIKWhOS9mGS7aorWigp-Eavdn5szSzRitY8Fu9Ftm8=.8ed296ac-a21b-4e93-9d1a-4c83ff50a440@github.com> Message-ID: On Wed, 16 Dec 2020 07:40:18 GMT, Serguei Spitsyn wrote: >> This change have been already reviewed by Mandy, Sundar, Alan and David. >> Please, see the jdk 15 review thread: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html >> >> Now, the PR approval is needed. >> The push was postponed because the CSR was not approved at that time (it is now): >> https://bugs.openjdk.java.net/browse/JDK-8248189 >> Investigation of existing popular java agents was requested by Joe. >> ---------- >> >> The java.lang.instrument spec: >> https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html >> >> Summary: >> The java.lang.instrument spec clearly states: >> "The agent class must implement a public static premain method >> similar in principle to the main application entry point." >> Current implementation of sun/instrument/InstrumentationImpl.java >> allows the premain method be non-public which violates the spec. >> This fix aligns the implementation with the spec. >> >> Testing: >> A mach5 run of jdk_instrument tests is in progress. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fixed trailing spaces test/jdk/java/lang/instrument/AgentJarBuilder.java line 36: > 34: import jdk.test.lib.util.JarUtils; > 35: > 36: public class AgentJarBuilder { Can you use the test library `test/lib/jdk/test/lib/util/JavaAgentBuilder.java`? test/jdk/java/lang/instrument/PremainClass/InheritAgent0010.java line 32: > 30: * @library /test/lib > 31: * @library /test > 32: * @modules jdk.jartool/sun.tools.jar I don't see `sun.tools.jar` is used. Is this qualified exports needed? ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From mchung at openjdk.java.net Wed Dec 16 19:46:58 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 16 Dec 2020 19:46:58 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On Wed, 16 Dec 2020 08:18:49 GMT, Alan Bateman wrote: > So PR1694 is really just about aligning the spec so that the premain method is public. However, it does not fix the overall accessibility issue. OK I see that JDK-5070281 changes to allow the agent class to be non-public as the main class that declares `public static void main`. So `setAccessible` should only be called if the agent class is in an unnamed module. If the agent class is in a named module and not accessible to java.instrument module (if the java agent is packaged in a modular JAR file), it should fail with IAE - can you confirm? I wanted to understand the current behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From bchristi at openjdk.java.net Wed Dec 16 20:00:59 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 16 Dec 2020 20:00:59 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v4] In-Reply-To: References: Message-ID: <_3eyagnLPeaqOmlVW65dLaW-Wml-BqQHSAtqFGgtzcE=.1168634c-3ed4-457a-867c-5d8bcd0d12c1@github.com> On Wed, 16 Dec 2020 07:10:41 GMT, Alan Bateman wrote: >> Brent Christian has updated the pull request incrementally with one additional commit since the last revision: >> >> improve SERIAL_FILTER_PATTERN comment > > src/java.base/share/classes/java/util/Locale.java line 1649: > >> 1647: *

This implements the 'Language-Tag' production of BCP47, and >> 1648: * so supports legacy (regular and irregular, referred to as >> 1649: * {@code Type: grandfathered} in BCP47) as well as > > You might consider putting quotes around "Type; grandfathered" here, otherwise looks good. Yes, having that in quotes instead of in {@code} would be consistent with the rest of Locale.java. I will change that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From bchristi at openjdk.java.net Wed Dec 16 20:08:11 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 16 Dec 2020 20:08:11 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v5] In-Reply-To: References: Message-ID: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: Use quotes instead of @code in Locale ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1771/files - new: https://git.openjdk.java.net/jdk/pull/1771/files/ba586413..03264330 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771 From smarks at openjdk.java.net Wed Dec 16 22:17:56 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 16 Dec 2020 22:17:56 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v5] In-Reply-To: References: Message-ID: <7eyzI35LC0CuYkwMo5nfLC8CrEZxmIcX8GfbSKy91MI=.d3322944-9580-410c-b387-490742c36c5a@github.com> On Wed, 16 Dec 2020 20:08:11 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Use quotes instead of @code in Locale Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From bchristi at openjdk.java.net Wed Dec 16 23:12:55 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 16 Dec 2020 23:12:55 GMT Subject: Integrated: 8253497: Core Libs Terminology Refresh In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. This pull request has now been integrated. Changeset: b2f03554 Author: Brent Christian URL: https://git.openjdk.java.net/jdk/commit/b2f03554 Stats: 82 lines in 15 files changed: 1 ins; 0 del; 81 mod 8253497: Core Libs Terminology Refresh Reviewed-by: naoto, kcr, rriggs, joehw, bpb, smarks, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From pchilanomate at openjdk.java.net Wed Dec 16 23:45:08 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 16 Dec 2020 23:45:08 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings [v2] In-Reply-To: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> Message-ID: <6vfgJkXCLsZEXpKBR2eEvEP-jAOlZfO8EBw-Q41J8nM=.5b83331a-2580-4598-88f0-5edd64127ba0@github.com> > Hi, > > Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. > > I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. > > Without the patch I can consistently reproduce the issue. With the patch the test always passes. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: include 'VM Warning' in stderr search ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1749/files - new: https://git.openjdk.java.net/jdk/pull/1749/files/6e03341b..11184ea6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1749&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1749&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1749.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1749/head:pull/1749 PR: https://git.openjdk.java.net/jdk/pull/1749 From pchilanomate at openjdk.java.net Wed Dec 16 23:52:03 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 16 Dec 2020 23:52:03 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings [v2] In-Reply-To: <7m0k5-ugaD1RwS-8VJNngGyDF-suLk-YBkGa-MTHYCE=.168d9ee3-a897-4f19-bf05-18b3e7d28999@github.com> References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> <7m0k5-ugaD1RwS-8VJNngGyDF-suLk-YBkGa-MTHYCE=.168d9ee3-a897-4f19-bf05-18b3e7d28999@github.com> Message-ID: On Wed, 16 Dec 2020 01:19:43 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> include 'VM Warning' in stderr search > > test/lib/jdk/test/lib/process/OutputAnalyzer.java line 43: > >> 41: private static final String jvmwarningmsg = ".* VM warning:.*"; >> 42: >> 43: private static final String deprecatedmsg = ".* deprecated.*"; > > This might be too generic, perhaps combine it with "VM warning" so we don't get accidental hits on other deprecation output eg from javac? > Also I'm not sure if only deprecation warnings should be handled but I guess we can adjust if that need arises. Sounds good. I added "VM warning" to the search. ------------- PR: https://git.openjdk.java.net/jdk/pull/1749 From lmesnik at openjdk.java.net Thu Dec 17 00:49:02 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 17 Dec 2020 00:49:02 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition Message-ID: The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. I run all existing tests with enabled logging and sanity verified error messages. ------------- Commit messages: - updated. - redfine log added Changes: https://git.openjdk.java.net/jdk/pull/1811/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1811&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258061 Stats: 63 lines in 1 file changed: 53 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1811.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1811/head:pull/1811 PR: https://git.openjdk.java.net/jdk/pull/1811 From jwilhelm at openjdk.java.net Thu Dec 17 02:59:10 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 17 Dec 2020 02:59:10 GMT Subject: RFR: Merge jdk16 Message-ID: Merge JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8258338: Support deprecated records - 8241353: NPE in ToolProvider.getSystemJavaCompiler - 8255880: UI of Swing components is not redrawn after their internal state changed - 8257637: Update usage of "type" terminology in java.lang.annotation - 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive - 8258419: RSA cipher buffer cleanup - 8258380: [JVMCI] don't clear InstalledCode reference when unloading JVMCI nmethods - 8258427: Problem List some tests related to FileDialog for MacOS - 8258140: Update @jls tags in java.base for renamed/renumbered sections - ... and 4 more: https://git.openjdk.java.net/jdk/compare/b2f03554...951fc9c0 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1812&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1812&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/1812/files Stats: 882 lines in 41 files changed: 659 ins; 30 del; 193 mod Patch: https://git.openjdk.java.net/jdk/pull/1812.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1812/head:pull/1812 PR: https://git.openjdk.java.net/jdk/pull/1812 From jwilhelm at openjdk.java.net Thu Dec 17 03:08:57 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 17 Dec 2020 03:08:57 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: <6qEv2eY0O11uVLbYwNrAVT7U4LFVK5INiyqa2hByAyQ=.5b8cb7e1-d127-487a-91fc-a1a65e4786b3@github.com> On Thu, 17 Dec 2020 02:48:38 GMT, Jesper Wilhelmsson wrote: > Merge JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 11bd7a81 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/11bd7a81 Stats: 882 lines in 41 files changed: 659 ins; 30 del; 193 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/1812 From sspitsyn at openjdk.java.net Thu Dec 17 04:39:17 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 17 Dec 2020 04:39:17 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v7] In-Reply-To: References: Message-ID: > This change have been already reviewed by Mandy, Sundar, Alan and David. > Please, see the jdk 15 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html > > Now, the PR approval is needed. > The push was postponed because the CSR was not approved at that time (it is now): > https://bugs.openjdk.java.net/browse/JDK-8248189 > Investigation of existing popular java agents was requested by Joe. > ---------- > > The java.lang.instrument spec: > https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html > > Summary: > The java.lang.instrument spec clearly states: > "The agent class must implement a public static premain method > similar in principle to the main application entry point." > Current implementation of sun/instrument/InstrumentationImpl.java > allows the premain method be non-public which violates the spec. > This fix aligns the implementation with the spec. > > Testing: > A mach5 run of jdk_instrument tests is in progress. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: 1. Replaced AgentJarBuilder with JavaAgentBuilder; 2. Removed unneeded sun.tools.jar imports ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1694/files - new: https://git.openjdk.java.net/jdk/pull/1694/files/9b95b037..09cf3fda Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=05-06 Stats: 127 lines in 20 files changed: 0 ins; 89 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/1694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1694/head:pull/1694 PR: https://git.openjdk.java.net/jdk/pull/1694 From sspitsyn at openjdk.java.net Thu Dec 17 04:59:17 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 17 Dec 2020 04:59:17 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v8] In-Reply-To: References: Message-ID: > This change have been already reviewed by Mandy, Sundar, Alan and David. > Please, see the jdk 15 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html > > Now, the PR approval is needed. > The push was postponed because the CSR was not approved at that time (it is now): > https://bugs.openjdk.java.net/browse/JDK-8248189 > Investigation of existing popular java agents was requested by Joe. > ---------- > > The java.lang.instrument spec: > https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html > > Summary: > The java.lang.instrument spec clearly states: > "The agent class must implement a public static premain method > similar in principle to the main application entry point." > Current implementation of sun/instrument/InstrumentationImpl.java > allows the premain method be non-public which violates the spec. > This fix aligns the implementation with the spec. > > Testing: > A mach5 run of jdk_instrument tests is in progress. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: added to NegativeAgentRunner exit value check to be non-zero ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1694/files - new: https://git.openjdk.java.net/jdk/pull/1694/files/09cf3fda..448bb8b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=06-07 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1694/head:pull/1694 PR: https://git.openjdk.java.net/jdk/pull/1694 From sspitsyn at openjdk.java.net Thu Dec 17 05:14:58 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 17 Dec 2020 05:14:58 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v4] In-Reply-To: References: <-UnrJzRklbiK5jDbZGNBxKT74pVk20JL8BdiDJxJGEY=.b16652a9-1304-46ac-bb63-443ef80a4572@github.com> Message-ID: On Wed, 16 Dec 2020 19:44:04 GMT, Mandy Chung wrote: >> Mandy is correct, the bigger picture here is accessibility. Code in the java.instrument module should be able to invoke the premain or agentmain without needing to suppress access checks. It's a perquisite to supporting the deployment of java agents as modules. When an agent is deployed as a module it will need the agent class to be public in a package that is exported to at least the java.instrument module. The premain method will need to be public too. >> So PR1694 is really just about aligning the spec so that the premain method is public. However, it does not fix the overall accessibility issue. Fixing the accessibility issue will fixing the java.lang.instrument package description to specify that the agent class is public. > >> So PR1694 is really just about aligning the spec so that the premain method is public. However, it does not fix the overall accessibility issue. > > OK I see that JDK-5070281 changes to allow the agent class to be non-public as the main class that declares `public static void main`. So `setAccessible` should only be called if the agent class is in an unnamed module. > > If the agent class is in a named module and not accessible to java.instrument module (if the java agent is packaged in a modular JAR file), it should fail with IAE - can you confirm? I wanted to understand the current behavior. Mandy, I've pushed updates with changes: - NegativeAgentRunner checks if the exit value is non-zero - AgentJarBuilder is replaced with JavaAgentBuilder - removed unneeded qualified exports > So setAccessible should only be called if the agent class is in an unnamed module. Now the agent class is always loaded as in the unnamed module. I tried to test this with a modular jar file which has module-info.class in it. In fact, I don't know if there are any options that would help to load the premain agent class in named module. I guess, it has to be implemented as part of the enhancement https://bugs.openjdk.java.net/browse/JDK-6932391 . The following patch can be committed if you like as it does not harm: @@ -476,11 +476,13 @@ public class InstrumentationImpl implements Instrumentation { String msg = "method " + classname + "." + methodname + " must be declared public"; throw new IllegalAccessException(msg); } - - if ((javaAgentClass.getModifiers() & java.lang.reflect.Modifier.PUBLIC) == 0) { - // If the java agent class is not public, make the premain/agentmain - // accessible, so we can call it. + if ((javaAgentClass.getModifiers() & java.lang.reflect.Modifier.PUBLIC) == 0 && + !javaAgentClass.getModule().isNamed()) { + // If the java agent class is not public and is in unnamed module + // then make the premain/agentmain accessible, so we can call it. setAccessible(m, true); } ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From cjplummer at openjdk.java.net Thu Dec 17 05:30:00 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Dec 2020 05:30:00 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 00:44:18 GMT, Leonid Mesnik wrote: > The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. > I run all existing tests with enabled logging and sanity verified error messages. src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1003: > 1001: ("redefined class %s modifiers change error: modifiers changed from %d to %d.", > 1002: the_class->external_name(), old_flags, new_flags); > 1003: return JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_MODIFIERS_CHANGED; You've changed the ordering of the checks. I'm not sure why. src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 936: > 934: scratch_class->super()->name())) { > 935: log_trace(redefine, class, normalize) > 936: ("redefined class %s superclass change error: superclass changed from %s to %s.", I'm not so sure I like the style of the log message wording. I would prefer something like: error redefining class %s: superclass changed from %s to %s. The same comment applies to pretty much every error message below. Besides being more concise and easier to read, I don't like using "superclass change error" when there is no such formally defined error. The error is `JVMTI_ERROR_UNSUPPORTED_REDEFINITION_HIERARCHY_CHANGED`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From cjplummer at openjdk.java.net Thu Dec 17 05:33:58 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Dec 2020 05:33:58 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition In-Reply-To: References: Message-ID: <1em3Hqp5pzUBBViIiPvWEMSbELrUvmXloZ1BvlGZoWo=.edcca0ec-4173-42fa-8ccf-d055c3254578@github.com> On Thu, 17 Dec 2020 05:27:36 GMT, Chris Plummer wrote: >> The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. >> I run all existing tests with enabled logging and sanity verified error messages. > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 936: > >> 934: scratch_class->super()->name())) { >> 935: log_trace(redefine, class, normalize) >> 936: ("redefined class %s superclass change error: superclass changed from %s to %s.", > > I'm not so sure I like the style of the log message wording. I would prefer something like: > > error redefining class %s: superclass changed from %s to %s. > > The same comment applies to pretty much every error message below. Besides being more concise and easier to read, I don't like using "superclass change error" when there is no such formally defined error. The error is `JVMTI_ERROR_UNSUPPORTED_REDEFINITION_HIERARCHY_CHANGED`. I see now that you are just being consistent with the style used in existing logs, so I guess it's ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From cjplummer at openjdk.java.net Thu Dec 17 05:54:55 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Dec 2020 05:54:55 GMT Subject: RFR: 8258471: "search codecache" clhsdb command does not work In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 10:27:05 GMT, Yasumasa Suenaga wrote: > `search codecache` command does not work as following: > > hsdb> search codecache 0x7fedbd0aec90 > java.lang.RuntimeException: Unable to deduce type of CodeBlob from address 0x00007fedbc85e810 (expected type nmethod, RuntimeStub, SafepointBlob, DeoptimizationBlob, or ExceptionBlob) > at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.createCodeBlobWrapper(CodeCache.java:177) > at jdk.hotspot.agent/sun.jvm.hotspot.memory.CodeHeap.iterate(CodeHeap.java:111) > at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.iterate(CodeCache.java:185) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$40.doit(CommandProcessor.java:1535) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2051) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2021) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1901) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:280) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:483) > > I checked the Object which points 0x7fedbd0aec90, it was `VtableBlob`. It has been introduced in [JDK-8199406](https://bugs.openjdk.java.net/browse/JDK-8199406), but it did not change SA code. > > SA should support `VtableBlob`. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1800 From dholmes at openjdk.java.net Thu Dec 17 07:55:57 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Dec 2020 07:55:57 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings [v2] In-Reply-To: <6vfgJkXCLsZEXpKBR2eEvEP-jAOlZfO8EBw-Q41J8nM=.5b83331a-2580-4598-88f0-5edd64127ba0@github.com> References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> <6vfgJkXCLsZEXpKBR2eEvEP-jAOlZfO8EBw-Q41J8nM=.5b83331a-2580-4598-88f0-5edd64127ba0@github.com> Message-ID: On Wed, 16 Dec 2020 23:45:08 GMT, Patricio Chilano Mateo wrote: >> Hi, >> >> Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. >> >> I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. >> >> Without the patch I can consistently reproduce the issue. With the patch the test always passes. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > include 'VM Warning' in stderr search Thanks! ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1749 From coleenp at openjdk.java.net Thu Dec 17 13:29:02 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 13:29:02 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition In-Reply-To: References: Message-ID: <5JnfETmHNoAT7qmq9s_CaoagDaQfluT7V8JYsnQ6GIQ=.896623d0-aa19-41bc-bead-e347b87b0114@github.com> On Thu, 17 Dec 2020 00:44:18 GMT, Leonid Mesnik wrote: > The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. > I run all existing tests with enabled logging and sanity verified error messages. src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 935: > 933: the_class->super()->name() != > 934: scratch_class->super()->name())) { > 935: log_trace(redefine, class, normalize) I think these would be useful to users so that these should be made log_info(redefine). All the other redefinition logging is useful for developers in debugging redefinition, and a user wouldn't really be able to follow the output unless they are very knowledgeable. Making this log_info(redefine) would let them see this without the noise of the other output. ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From lmesnik at openjdk.java.net Thu Dec 17 16:13:01 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 17 Dec 2020 16:13:01 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition In-Reply-To: <5JnfETmHNoAT7qmq9s_CaoagDaQfluT7V8JYsnQ6GIQ=.896623d0-aa19-41bc-bead-e347b87b0114@github.com> References: <5JnfETmHNoAT7qmq9s_CaoagDaQfluT7V8JYsnQ6GIQ=.896623d0-aa19-41bc-bead-e347b87b0114@github.com> Message-ID: On Thu, 17 Dec 2020 13:25:42 GMT, Coleen Phillimore wrote: >> The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. >> I run all existing tests with enabled logging and sanity verified error messages. > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 935: > >> 933: the_class->super()->name() != >> 934: scratch_class->super()->name())) { >> 935: log_trace(redefine, class, normalize) > > I think these would be useful to users so that these should be made log_info(redefine). All the other redefinition logging is useful for developers in debugging redefinition, and a user wouldn't really be able to follow the output unless they are very knowledgeable. Making this log_info(redefine) would let them see this without the noise of the other output. I've made them log_trace to be consistent with already existing logging introduced for nestmates related errors. Do you want to make all of them log_info in such case? ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From lmesnik at openjdk.java.net Thu Dec 17 16:12:58 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 17 Dec 2020 16:12:58 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition In-Reply-To: References: Message-ID: <5FV52nh_1HBsZTOyYBVKKPQH8hYbh3gTfcYY5gkuEzY=.8a2bb58d-03bb-4452-813f-f8cfe4c9c6c4@github.com> On Thu, 17 Dec 2020 05:27:28 GMT, Chris Plummer wrote: >> The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. >> I run all existing tests with enabled logging and sanity verified error messages. > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1003: > >> 1001: ("redefined class %s modifiers change error: modifiers changed from %d to %d.", >> 1002: the_class->external_name(), old_flags, new_flags); >> 1003: return JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_MODIFIERS_CHANGED; > > You've changed the ordering of the checks. I'm not sure why. I changed the order to report about different names first if any of the variables are added/deleted. And report about different modifiers/offsets only if the names of variables are the same. The result should be the same because JVMTI_ERROR_UNSUPPORTED_REDEFINITION_SCHEMA_CHANGED is returned anyway. ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From pchilanomate at openjdk.java.net Thu Dec 17 16:34:58 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 17 Dec 2020 16:34:58 GMT Subject: RFR: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings [v2] In-Reply-To: References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> Message-ID: <7qSK1vLuZHdo-K3wIRyxRC1QrhjLDxpiGFR9p56eLGg=.709c3ba9-98ec-4cce-b954-7c3694a2cd8c@github.com> On Tue, 15 Dec 2020 20:52:36 GMT, Alex Menkov wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> include 'VM Warning' in stderr search > > Marked as reviewed by amenkov (Reviewer). Thanks @alexmenkov, @plummercj and @dholmes-ora for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/1749 From pchilanomate at openjdk.java.net Thu Dec 17 16:44:57 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 17 Dec 2020 16:44:57 GMT Subject: Integrated: 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings In-Reply-To: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> References: <65knp1iAj2f0upKcj7hd4AtuPVvoq05NG1Nd2j3s5YI=.4b13a9c6-28ee-4a8a-b32c-22420868e667@github.com> Message-ID: On Fri, 11 Dec 2020 17:25:33 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following small fix for test RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue is due to having two different StreamPumper objects consuming from the same stderr, one created by ProcessTools.startProcess() and another by OutputAnalyzer(). In the failing cases the StreamPumper processing thread created in ProcessTools.startProcess() consumes the first part of the deprecation message while the one created in OutputAnalyzer consumes the rest. Since out.getStderr() is not empty and does not contain the string "VM warning:", the test fails. > > I simply replaced the ProcessTools.startProcess() call by a call to start() on the ProcessBuilder object, which doesn't use StreamPumper. I added stderrShouldBeEmptyIgnoreDeprecatedWarnings(), since as mentioned in 8248162 we might not want to hide all warning messages. > > Without the patch I can consistently reproduce the issue. With the patch the test always passes. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 7b05439d Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/7b05439d Stats: 20 lines in 2 files changed: 18 ins; 0 del; 2 mod 8258057: serviceability/attach/RemovingUnixDomainSocketTest.java doesn't ignore VM warnings Reviewed-by: cjplummer, amenkov, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1749 From coleenp at openjdk.java.net Thu Dec 17 18:48:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 18:48:58 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition In-Reply-To: References: <5JnfETmHNoAT7qmq9s_CaoagDaQfluT7V8JYsnQ6GIQ=.896623d0-aa19-41bc-bead-e347b87b0114@github.com> Message-ID: <_0DS35gmr5jBx9MeDr36TUlGveC4oXScyAjFjYjE8UA=.afd3a44f-d358-4514-bdbe-9112715f4f18@github.com> On Thu, 17 Dec 2020 16:10:29 GMT, Leonid Mesnik wrote: >> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 935: >> >>> 933: the_class->super()->name() != >>> 934: scratch_class->super()->name())) { >>> 935: log_trace(redefine, class, normalize) >> >> I think these would be useful to users so that these should be made log_info(redefine). All the other redefinition logging is useful for developers in debugging redefinition, and a user wouldn't really be able to follow the output unless they are very knowledgeable. Making this log_info(redefine) would let them see this without the noise of the other output. > > I've made them log_trace to be consistent with already existing logging introduced for nestmates related errors. Do you want to make all of them log_info in such case? I see. I think so, yes. Since you're returning an error from redefinition, a higher level logging seems warranted. ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From mchung at openjdk.java.net Thu Dec 17 20:22:58 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 17 Dec 2020 20:22:58 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v8] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 04:59:17 GMT, Serguei Spitsyn wrote: >> This change have been already reviewed by Mandy, Sundar, Alan and David. >> Please, see the jdk 15 review thread: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html >> >> Now, the PR approval is needed. >> The push was postponed because the CSR was not approved at that time (it is now): >> https://bugs.openjdk.java.net/browse/JDK-8248189 >> Investigation of existing popular java agents was requested by Joe. >> ---------- >> >> The java.lang.instrument spec: >> https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html >> >> Summary: >> The java.lang.instrument spec clearly states: >> "The agent class must implement a public static premain method >> similar in principle to the main application entry point." >> Current implementation of sun/instrument/InstrumentationImpl.java >> allows the premain method be non-public which violates the spec. >> This fix aligns the implementation with the spec. >> >> Testing: >> A mach5 run of jdk_instrument tests is in progress. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > added to NegativeAgentRunner exit value check to be non-zero @sspitsyn Thanks for the update. I think it's good to add the unnamed module check before calling `setAccessible` that becomes clear that this check only intends for unnamed module. Maybe make it clear in the comment something like this: // if the java agent class is in an unnamed module, the java agent class can be non-public. // suppress access check upon the invocation of the premain/agentmain method Since the agent class can be non-public, it means that it's not necessary to modify the test agent class to public as you did in this patch. I don't think `@library /test` is needed, isn't it? The test library classes are under test/lib. src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java line 475: > 473: > 474: // reject non-public premain or agentmain method > 475: if ((m.getModifiers() & java.lang.reflect.Modifier.PUBLIC) == 0) { An alternative way: `if (Modifier.isPublic(m.getModifiers()))` Similar can be applied for checking if the javaagentClass is public. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From iignatyev at openjdk.java.net Thu Dec 17 20:23:56 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 17 Dec 2020 20:23:56 GMT Subject: Withdrawn: 8254861: reformat code in vmTestbase/nsk/jdb In-Reply-To: References: Message-ID: <6a4E1ywjY_W4Sv3NkOg67lx_2N9Am2diX-NsLroy2cI=.3a4f6048-0fae-44d2-be78-0d279928ae11@github.com> On Thu, 15 Oct 2020 22:47:43 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this patch which reformats/cleans up the code of vmTestbase/nsk/jdb tests? > > the part of this patch is a spinoff from #350. > > testing: > * [x] `vmTestbase/nsk/jdb` tests on `linux-x64-debug` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From lmesnik at openjdk.java.net Thu Dec 17 22:54:13 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 17 Dec 2020 22:54:13 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition [v2] In-Reply-To: References: Message-ID: > The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. > I run all existing tests with enabled logging and sanity verified error messages. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: updated log_trace to log_info ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1811/files - new: https://git.openjdk.java.net/jdk/pull/1811/files/801a0c2a..fe6dccf3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1811&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1811&range=00-01 Stats: 21 lines in 1 file changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/1811.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1811/head:pull/1811 PR: https://git.openjdk.java.net/jdk/pull/1811 From lmesnik at openjdk.java.net Thu Dec 17 23:51:57 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 17 Dec 2020 23:51:57 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition [v2] In-Reply-To: <_0DS35gmr5jBx9MeDr36TUlGveC4oXScyAjFjYjE8UA=.afd3a44f-d358-4514-bdbe-9112715f4f18@github.com> References: <5JnfETmHNoAT7qmq9s_CaoagDaQfluT7V8JYsnQ6GIQ=.896623d0-aa19-41bc-bead-e347b87b0114@github.com> <_0DS35gmr5jBx9MeDr36TUlGveC4oXScyAjFjYjE8UA=.afd3a44f-d358-4514-bdbe-9112715f4f18@github.com> Message-ID: On Thu, 17 Dec 2020 18:46:14 GMT, Coleen Phillimore wrote: >> I've made them log_trace to be consistent with already existing logging introduced for nestmates related errors. Do you want to make all of them log_info in such case? > > I see. I think so, yes. Since you're returning an error from redefinition, a higher level logging seems warranted. I've updated logging to use log_info where error is returned. ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From coleenp at openjdk.java.net Fri Dec 18 02:09:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 18 Dec 2020 02:09:57 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition [v2] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 22:54:13 GMT, Leonid Mesnik wrote: >> The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. >> I run all existing tests with enabled logging and sanity verified error messages. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated log_trace to log_info Looks good to me. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1811 From sspitsyn at openjdk.java.net Fri Dec 18 03:20:59 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 18 Dec 2020 03:20:59 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition [v2] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 22:54:13 GMT, Leonid Mesnik wrote: >> The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. >> I run all existing tests with enabled logging and sanity verified error messages. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated log_trace to log_info Hi Leonid, It is useful and looks good. Just one nit: This line can be split after the comma: `1047 ("redefined class %s fields change error: some fields were %s.", the_class->external_name(), action); ` Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1811 From sspitsyn at openjdk.java.net Fri Dec 18 03:30:56 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 18 Dec 2020 03:30:56 GMT Subject: RFR: 8258471: "search codecache" clhsdb command does not work In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 10:27:05 GMT, Yasumasa Suenaga wrote: > `search codecache` command does not work as following: > > hsdb> search codecache 0x7fedbd0aec90 > java.lang.RuntimeException: Unable to deduce type of CodeBlob from address 0x00007fedbc85e810 (expected type nmethod, RuntimeStub, SafepointBlob, DeoptimizationBlob, or ExceptionBlob) > at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.createCodeBlobWrapper(CodeCache.java:177) > at jdk.hotspot.agent/sun.jvm.hotspot.memory.CodeHeap.iterate(CodeHeap.java:111) > at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.iterate(CodeCache.java:185) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$40.doit(CommandProcessor.java:1535) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2051) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2021) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1901) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:280) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:483) > > I checked the Object which points 0x7fedbd0aec90, it was `VtableBlob`. It has been introduced in [JDK-8199406](https://bugs.openjdk.java.net/browse/JDK-8199406), but it did not change SA code. > > SA should support `VtableBlob`. Hi Yasumasa, It looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1800 From david.holmes at oracle.com Fri Dec 18 04:00:27 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Dec 2020 14:00:27 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <2f67d06f-4345-0d10-89a8-906beadcd737@oss.nttdata.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> <6515a8b8-0c4a-d06a-af8e-a28a6c31d185@oss.nttdata.com> <82684a2f-5231-d64b-5175-8aa6c8e428e9@oracle.com> <93e65fc1-3052-706e-cabf-fb1ff4f7f895@oss.nttdata.com> <6e375192-bb36-3888-58b1-5cdc52688b08@oracle.com> <2f67d06f-4345-0d10-89a8-906beadcd737@oss.nttdata.com> Message-ID: <7a434941-6aaf-1c7e-8c32-02d45f5d6ae5@oracle.com> On 16/12/2020 5:36 pm, Yasumasa Suenaga wrote: > Hi David, > >> I'm not sure you mean exactly by DLL unloading mechanism is not hooked. > > I want to say we do not hook `FreeLibrary()` on Windows and `dlclose()` > on Linux. > Can we describe ""this function may be called - " at here? I think it is clear this refers to the VM doing the unloading not somebody issuing direct dlclose/FreeLibrary commands. David > > Cheers, > Yasumasa > > > On 2020/12/16 15:48, David Holmes wrote: >> On 16/12/2020 4:33 pm, Yasumasa Suenaga wrote: >>> Hi David, >>> >>>> "This function will be called by the VM when the library is about to >>>> be unloaded. The library will be unloaded (unless it is statically >>>> linked into the executable) and this function will be called if some >>>> platform specific mechanism causes the unload (an unload mechanism >>>> is not specified in this document) or the library is (in effect) >>>> unloaded by the termination of the VM. VM termination includes >>>> normal termination and VM failure, including start-up failure, but >>>> not, of course, uncontrolled shutdown. An implementation may also >>>> choose to not call this function if the >>>> Agent_OnAttach/Agent_OnAttach_L function reported an error (returned >>>> a non-zero value)." >>> >>> Thank you so much! >>> According to this, we can fix this bug simply. (We can unload agent >>> library without `Agent_OnUnload()` call) >> >> Yes I think it is reasonable to allow this. But of course there must >> be a general consensus. >> >>> However I think following sentence should be removed because DLL >>> unloading mechanism is not hooked, and also `Agent_OnUnload()` >>> wouldn't be called by dll unloading - it depends on VM termination / >>> failure / non-zero value from entry points. >>> >>> "this function will be called if some platform specific mechanism >>> causes the unload (an unload mechanism is not specified in this >>> document)" >> >> I'm not sure you mean exactly by DLL unloading mechanism is not >> hooked. But that sentence has to remain because it makes it clear that >> the decision as to when unloading occurs is up to an implementation >> and is not defined by the specification. >> >> Cheers, >> David >> ----- >> >>> >>> If you are OK, I will update CSR. >>> >>> >>> Cheers, >>> >>> Yasumasa >>> >>> >>> On 2020/12/16 11:09, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> Sorry for the delay getting back to this. >>>> >>>> On 1/12/2020 4:41 pm, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>> On 2020/12/01 14:59, David Holmes wrote: >>>>>> Looking at the original webrev from September: >>>>>> >>>>>> https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExport.cpp.cdiff.html >>>>>> >>>>>> >>>>>> The suggestion to unload the library if Agent_OnAttach fails seems >>>>>> quite reasonable - it is what happens if no Agent_OnAttach >>>>>> function can be found in the agent. >>>>>> >>>>>> But the specification is lacking because it simply states any such >>>>>> error is "ignored" - which is an oversimplification and I think >>>>>> was really intended to contrast with the abort behaviour if >>>>>> Agent_OnLoad fails. In addition the specification indicates that >>>>>> Agent_OnUnload is called any time the agent library is unloaded, >>>>>> except for "uncontrolled shutdown". This unfortunately suggests >>>>>> that before unloading the library after OnAttach fails, we also >>>>>> call OnUnload. That seems wrong and in fact the VM does not do >>>>>> that - and noone seems to have complained. >>>>>> >>>>>> Also note the specification states an agent "must export a >>>>>> start-up function ..." but doesn't say what happens if it doesn't >>>>>> do so. >>>>>> >>>>>> My gut feeling for what the specification should say here is that >>>>>> if the start-up function does not exist, or the call to >>>>>> Agent_OnAttach reports an error, then the agent library is >>>>>> immediately unloaded with no attempt to call the agent shutdown >>>>>> function (Agent_OnUnload). >>>>> >>>>> That's what I wanted to suggest! >>>>> I understand we need to consider following case in this issue, is >>>>> it right? >>>>> >>>>> Agent_OnLoad / Agent_OnLoad_L does not exist: >>>>> ???? - Agent_OnUnload is not called >>>>> ???? - DLL is not unloaded (JVM will abort) >>>>> >>>>> Agent_OnLoad / Agent_OnLoad_L failed: >>>>> ???? - Agent_OnUnload is not called >>>>> ???? - DLL is not unloaded (JVM will abort) >>>> >>>> These cases are already well covered. >>>> >>>>> Agent_OnAttach does not exist: >>>>> ???? - Agent_OnUnload is not called >>>>> ???? - DLL is unloaded >>>>> >>>>> Agent_OnAttach_L does not exist: >>>>> ???? - Agent_OnUnload is not called >>>>> ???? - DLL is not unloaded (static link) >>>> >>>> These cases are kind of implicitly covered, but could be clarified. >>>> >>>>> Agent_OnAttach failed: >>>>> ???? - Agent_OnUnload is not called >>>>> ???? - DLL is unloaded >>>>> >>>>> Agent_OnAttach_L faled: >>>>> ???? - Agent_OnUnload is not called >>>>> ???? - DLL is not unloaded (static link) >>>> >>>> These are the problematic cases. >>>> >>>>> >>>>>> But with my "compatibility glasses" on this may be too strong to >>>>>> retrofit to the specification as other VMs may behave differently. >>>>>> So as I stated in the CSR request we probably want to allow the >>>>>> current hotspot behaviour but not mandate it (unless we check with >>>>>> all the other VM implementations that such a specification is okay >>>>>> with them). >>>>> >>>>> Ok, for example, can we change the spec as following? >>>>> (Of course, this is not all) >>>>> >>>>> ``` >>>>> diff --git a/src/hotspot/share/prims/jvmti.xml >>>>> b/src/hotspot/share/prims/jvmti.xml >>>>> index 44553b8065f..57c87b1a71b 100644 >>>>> --- a/src/hotspot/share/prims/jvmti.xml >>>>> +++ b/src/hotspot/share/prims/jvmti.xml >>>>> @@ -688,7 +688,8 @@ Agent_OnUnload_L(JavaVM *vm) >>>>> ????? mechanism causes the unload (an unload mechanism is not >>>>> specified in this document) >>>>> ????? or the library is (in effect) unloaded by the termination of >>>>> the VM whether through >>>>> ????? normal termination or VM failure, including start-up failure. >>>>> -??? Uncontrolled shutdown is, of course, an exception to this rule. >>>>> +??? Uncontrolled shutdown is, of course, an exception to this >>>>> rule, and also it might not be called >>>>> +??? when start-up function does not exist or fails (returns >>>>> non-zero value). >>>> >>>> I think this is what was originally proposed and as I said then I >>>> don't like burying this detail inside the reference to uncontrolled >>>> shutdown. We should make this much more explicit which requires some >>>> reworking of the existing far-too-long sentence. >>>> >>>> "This function will be called by the VM when the library is about to >>>> be unloaded. The library will be unloaded (unless it is statically >>>> linked into the executable) and this function will be called if some >>>> platform specific mechanism causes the unload (an unload mechanism >>>> is not specified in this document) or the library is (in effect) >>>> unloaded by the termination of the VM. VM termination includes >>>> normal termination and VM failure, including start-up failure, but >>>> not, of course, uncontrolled shutdown. An implementation may also >>>> choose to not call this function if the >>>> Agent_OnAttach/Agent_OnAttach_L function reported an error (returned >>>> a non-zero value)." >>>> >>>> Cheers, >>>> David >>>> ----- >>>> >>>>> ????? Note the distinction between this function and the >>>>> ????? VM Death event: for the >>>>> VM Death event >>>>> ????? to be sent, the VM must have run at least to the point of >>>>> initialization and a valid >>>>> ``` >>>>> >>>>>> I agree that the more general issue of re-loading an agent is a >>>>>> separate issue. >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 1/12/2020 3:21 pm, David Holmes wrote: >>>>>>> On 1/12/2020 3:19 pm, David Holmes wrote: >>>>>>>> On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >>>>>>>>> Hi Chris, David, >>>>>>>>> >>>>>>>>> Currently Agent_OnUnload() is not called when Agent_OnLoad() is >>>>>>>>> failed - JVM will abort. >>>>>>>>> Should we re-think this behavior? >>>>>>>> >>>>>>>> We should we rethink that? It is probably one of the clearest >>>>>>>> parts of the spec. If Agent_Onload fails that is considered a >>>>>>>> fatal error - end of story. >>>>>>> >>>>>>> I meant, of course, "Why should we rethink that?". >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> The issue is with Agent_onAttach and how its failure should, or >>>>>>>> should not, impact Agent_OnUnload. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> $ java -agentpath:/path/to/libhelloworld.so=error --version >>>>>>>>> Hello World from Agent_OnLoad() >>>>>>>>> ?? options = error >>>>>>>>> Error occurred during initialization of VM >>>>>>>>> agent library failed to init: /path/to/libhelloworld.so >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2020/12/01 11:44, David Holmes wrote: >>>>>>>>>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>>>>>>>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>>> * Q3: What has to be done for statically linked agent? >>>>>>>>>>>> >>>>>>>>>>>> JVMTI spec says "unless it is statically linked into the >>>>>>>>>>>> executable", so I think we can ignore about >>>>>>>>>>>> Agent_OnUnload_L() in this PR. >>>>>>>>>>> >>>>>>>>>>> I don't think that makes sense. If you call it for >>>>>>>>>>> dynamically linked then you need to call it for statically >>>>>>>>>>> linked also. >>>>>>>>>> >>>>>>>>>> Agreed. Even though you can't physically unload the statically >>>>>>>>>> linked library, if it is logically unloaded by some mechanism, >>>>>>>>>> then Agent_OnUnload_L is supposed to be called. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> ------------- >>>>>>>>>>> >>>>>>>>>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>>>>>>>>> From lmesnik at openjdk.java.net Fri Dec 18 04:52:13 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Fri, 18 Dec 2020 04:52:13 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition [v3] In-Reply-To: References: Message-ID: > The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. > I run all existing tests with enabled logging and sanity verified error messages. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: identation fixed after comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1811/files - new: https://git.openjdk.java.net/jdk/pull/1811/files/fe6dccf3..78e67d9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1811&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1811&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1811.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1811/head:pull/1811 PR: https://git.openjdk.java.net/jdk/pull/1811 From ysuenaga at openjdk.java.net Fri Dec 18 04:52:57 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 18 Dec 2020 04:52:57 GMT Subject: Integrated: 8258471: "search codecache" clhsdb command does not work In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 10:27:05 GMT, Yasumasa Suenaga wrote: > `search codecache` command does not work as following: > > hsdb> search codecache 0x7fedbd0aec90 > java.lang.RuntimeException: Unable to deduce type of CodeBlob from address 0x00007fedbc85e810 (expected type nmethod, RuntimeStub, SafepointBlob, DeoptimizationBlob, or ExceptionBlob) > at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.createCodeBlobWrapper(CodeCache.java:177) > at jdk.hotspot.agent/sun.jvm.hotspot.memory.CodeHeap.iterate(CodeHeap.java:111) > at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.iterate(CodeCache.java:185) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$40.doit(CommandProcessor.java:1535) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2051) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2021) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1901) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:280) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:483) > > I checked the Object which points 0x7fedbd0aec90, it was `VtableBlob`. It has been introduced in [JDK-8199406](https://bugs.openjdk.java.net/browse/JDK-8199406), but it did not change SA code. > > SA should support `VtableBlob`. This pull request has now been integrated. Changeset: 1e03ca13 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/1e03ca13 Stats: 47 lines in 3 files changed: 46 ins; 0 del; 1 mod 8258471: "search codecache" clhsdb command does not work Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/1800 From ysuenaga at openjdk.java.net Fri Dec 18 05:11:56 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 18 Dec 2020 05:11:56 GMT Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> Message-ID: On Tue, 1 Dec 2020 01:43:15 GMT, Chris Plummer wrote: >>> * Q1: Is it necessary to call the Agent_OnUnload()? >> >> [JVMTI spec of Agent_OnUnload()](https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#onunload) says this function will be called when the agent library will be unloaded by platform specific mechanism. OTOH it also says `Agent_OnUnload()` will be called both at VM termination and **by other reasons**. >> The spec don't say for the case if `Agent_OnAttach()` would be failed. IMHO `Agent_OnUnload()` should be called because this PR would unload library if `Agent_OnAttach()` failed. >> >>> * Q2: Would it be a JVMTI spec violation to call the Agent_OnAttach() multiple times? (It seems to be the case to me.) >> >> `Agent_OnAttach()` should be called only once per attach request, but VM should accept multiple attach request for same agent library. >> >> For example, we can add multiple `-agentlib` and `-agentpath` request as below. JVMTI agent might change behavior due to arguments or configuration file. >> >> -agentlib:test=profile=A -agentlib:test=profile=B -agentpath:/path/to/libtest=profile=C >> >> Agent developers should have responsibility for the behavior when more than one agent is loaded at a time. >> >>> * Q3: What has to be done for statically linked agent? >> >> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. >> >>> * Q4: Should the agent be correctly loadable in the first place? What were the reasons its loading to fail? >> >> Agent (`Agent_OnAttach()`) might fail due to error in agent logic. For example, some agents load configuration file at initialization. If the user gives wrong value, it will fail. >> >>> Yes, at least, a CSR is needed for this. >> >> I will file CSR for this PR after this discussion. > >> > * Q3: What has to be done for statically linked agent? >> >> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. > > I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. @dholmes-ora Thank you for explanation! I updated [CSR](https://bugs.openjdk.java.net/browse/JDK-8256918). Could you review it? ------------- PR: https://git.openjdk.java.net/jdk/pull/19 From sspitsyn at openjdk.java.net Fri Dec 18 12:00:48 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 18 Dec 2020 12:00:48 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v9] In-Reply-To: References: Message-ID: > This change have been already reviewed by Mandy, Sundar, Alan and David. > Please, see the jdk 15 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html > > Now, the PR approval is needed. > The push was postponed because the CSR was not approved at that time (it is now): > https://bugs.openjdk.java.net/browse/JDK-8248189 > Investigation of existing popular java agents was requested by Joe. > ---------- > > The java.lang.instrument spec: > https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html > > Summary: > The java.lang.instrument spec clearly states: > "The agent class must implement a public static premain method > similar in principle to the main application entry point." > Current implementation of sun/instrument/InstrumentationImpl.java > allows the premain method be non-public which violates the spec. > This fix aligns the implementation with the spec. > > Testing: > A mach5 run of jdk_instrument tests is in progress. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: 1. Suppress premain method check only if agent class is in unnamed module; 2. minor tests cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1694/files - new: https://git.openjdk.java.net/jdk/pull/1694/files/448bb8b8..412789d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=07-08 Stats: 19 lines in 14 files changed: 2 ins; 13 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1694/head:pull/1694 PR: https://git.openjdk.java.net/jdk/pull/1694 From lmesnik at openjdk.java.net Fri Dec 18 16:42:58 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Fri, 18 Dec 2020 16:42:58 GMT Subject: Integrated: 8258061: Improve diagnostic information about errors during class redefinition In-Reply-To: References: Message-ID: <6KqWtb-IpCQIGvKC-YtlOxZMe7eMfZiCcp8m3TJe7rk=.4387396e-ab8a-4d79-8a7f-b6190be3fb14@github.com> On Thu, 17 Dec 2020 00:44:18 GMT, Leonid Mesnik wrote: > The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. > I run all existing tests with enabled logging and sanity verified error messages. This pull request has now been integrated. Changeset: 71ae05d5 Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/71ae05d5 Stats: 72 lines in 1 file changed: 54 ins; 10 del; 8 mod 8258061: Improve diagnostic information about errors during class redefinition Reviewed-by: coleenp, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From sspitsyn at openjdk.java.net Fri Dec 18 17:57:56 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 18 Dec 2020 17:57:56 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v8] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 20:19:56 GMT, Mandy Chung wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> added to NegativeAgentRunner exit value check to be non-zero > > @sspitsyn Thanks for the update. I think it's good to add the unnamed module check before calling `setAccessible` that becomes clear that this check only intends for unnamed module. Maybe make it clear in the comment something like this: > > // if the java agent class is in an unnamed module, the java agent class can be non-public. > // suppress access check upon the invocation of the premain/agentmain method > > Since the agent class can be non-public, it means that it's not necessary to modify the test agent class to public as you did in this patch. > > I don't think `@library /test` is needed, isn't it? The test library classes are under test/lib. @mlchung Thank you for the suggestions. I've addressed them in the latest update. The `@library /test` is needed only in the tests that use NegativeAgentRunner as this class is located in folder one level up. I've removed the this line from the other tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From coleenp at openjdk.java.net Fri Dec 18 19:43:05 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 18 Dec 2020 19:43:05 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions Message-ID: This change allows JRT_LEAF functions to create Handles because it doesn't need them but some code inside the VM needs Handles. There's a NoSafepointVerifier in JRT_LEAF functions. The JNI_LEAF and JVM_LEAF functions have NoHandleMark (so you can't create handles) but the transition ThreadInVMfromNative will reenable the HandleMarks, so that all this code doesn't have to do it itself. Tested with tier1-6. ------------- Commit messages: - 8258032: Reconsider LEAF entry restrictions Changes: https://git.openjdk.java.net/jdk/pull/1846/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1846&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258032 Stats: 102 lines in 17 files changed: 7 ins; 69 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/1846.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1846/head:pull/1846 PR: https://git.openjdk.java.net/jdk/pull/1846 From github.com+741251+turbanoff at openjdk.java.net Sun Dec 20 17:10:02 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 20 Dec 2020 17:10:02 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Message-ID: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo ------------- Commit messages: - 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo - 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo Changes: https://git.openjdk.java.net/jdk/pull/1853/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8080272 Stats: 319 lines in 26 files changed: 1 ins; 248 del; 70 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Sun Dec 20 17:46:10 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 20 Dec 2020 17:46:10 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v2] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo revert changes in JrtPath. They compiled with java 8 language level ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/fa3ae201..90b1a455 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=00-01 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From alanb at openjdk.java.net Sun Dec 20 19:45:54 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 20 Dec 2020 19:45:54 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov wrote: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be careful with the changes here as it will likely causing build breakage. We try to keep the changes to ASM to a minimum, might be better to leave this change out of the patch. One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Sun Dec 20 20:09:12 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 20 Dec 2020 20:09:12 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v3] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo revert changes in ASM use Files.copy in sjavac ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/90b1a455..2ae88471 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=01-02 Stats: 18 lines in 2 files changed: 8 ins; 6 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Sun Dec 20 20:15:09 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 20 Dec 2020 20:15:09 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v4] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo use Files.copy in MLet too ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/2ae88471..c4133d32 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Sun Dec 20 20:22:10 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 20 Dec 2020 20:22:10 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v5] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo use Files.copy in Win32PrintJob too ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/c4133d32..ec602c1a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=03-04 Stats: 14 lines in 1 file changed: 2 ins; 10 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Sun Dec 20 20:25:52 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 20 Dec 2020 20:25:52 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 19:43:21 GMT, Alan Bateman wrote: > One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java. Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From prr at openjdk.java.net Sun Dec 20 20:36:56 2020 From: prr at openjdk.java.net (Phil Race) Date: Sun, 20 Dec 2020 20:36:56 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 20:22:48 GMT, Andrey Turbanov wrote: >> jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be careful with the changes here as it will likely causing build breakage. >> >> We try to keep the changes to ASM to a minimum, might be better to leave this change out of the patch. >> >> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java. > >> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java. > > Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive. So these changes are all over the place which means no one person knows how to test all of it. Have you run the sound, swing tests, and the printing tests on unix and windows ? For printing for sure you'll need to do some manual testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From serb at openjdk.java.net Sun Dec 20 22:50:55 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 20 Dec 2020 22:50:55 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 20:33:43 GMT, Phil Race wrote: >>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java. >> >> Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive. > > So these changes are all over the place which means no one person knows how to test all of it. > Have you run the sound, swing tests, and the printing tests on unix and windows ? > For printing for sure you'll need to do some manual testing. I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Dec 21 07:52:10 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Dec 2020 07:52:10 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v6] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Andrey Turbanov 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 since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/ec602c1a..6f8ec711 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=04-05 Stats: 135 lines in 13 files changed: 102 ins; 2 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Dec 21 07:58:59 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Dec 2020 07:58:59 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 22:48:24 GMT, Sergey Bylokhov wrote: >> So these changes are all over the place which means no one person knows how to test all of it. >> Have you run the sound, swing tests, and the printing tests on unix and windows ? >> For printing for sure you'll need to do some manual testing. > > I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR. I've extracted changes in java.desktop into separate PR #1856 Reverted this changes from current PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Dec 21 08:19:08 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Dec 2020 08:19:08 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v7] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Andrey Turbanov 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 since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/6f8ec711..fceb20e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=05-06 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From alanb at openjdk.java.net Mon Dec 21 08:36:56 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 21 Dec 2020 08:36:56 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo In-Reply-To: References: Message-ID: <2PqLx13nZz23evPEzR9WEuwRg0PsfxgrHzly7VbuCrE=.3d1d0fd0-6b91-48b5-9dd1-ba6834cc6bbd@github.com> On Mon, 21 Dec 2020 07:55:06 GMT, Andrey Turbanov wrote: >> I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR. > > I've extracted changes in java.desktop into separate PR #1856 > Reverted this changes from current PR. Probably best to drop the changes to src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/** too as it gets refreshed periodically from the upstream Apache Santuario project. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Dec 21 09:16:11 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Dec 2020 09:16:11 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo revert changes in Apache Santuario ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/fceb20e3..94e99817 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=06-07 Stats: 42 lines in 3 files changed: 35 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+10835776+stsypanov at openjdk.java.net Mon Dec 21 09:47:59 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 21 Dec 2020 09:47:59 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > revert changes in Apache Santuario I'm not a reviewer, but still think we could simplify `sun.security.tools.keytool.Main` src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459: > 2457: byte[] bytes = in.readAllBytes(); > 2458: return CertificateFactory.getInstance("X509").generateCRLs( > 2459: new ByteArrayInputStream(bytes)); Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again? ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Dec 21 09:53:57 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Dec 2020 09:53:57 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 09:40:39 GMT, ?????? ??????? wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> revert changes in Apache Santuario > > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459: > >> 2457: byte[] bytes = in.readAllBytes(); >> 2458: return CertificateFactory.getInstance("X509").generateCRLs( >> 2459: new ByteArrayInputStream(bytes)); > > Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again? Looks like it was done intentionally by original author of the code. Check comment above: // Read the full stream before feeding to X509Factory, // otherwise, keytool -gencrl | keytool -printcrl // might not work properly, since -gencrl is slow // and there's no data in the pipe at the beginning. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+10835776+stsypanov at openjdk.java.net Mon Dec 21 10:06:01 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 21 Dec 2020 10:06:01 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 09:51:25 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459: >> >>> 2457: byte[] bytes = in.readAllBytes(); >>> 2458: return CertificateFactory.getInstance("X509").generateCRLs( >>> 2459: new ByteArrayInputStream(bytes)); >> >> Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again? > > Looks like it was done intentionally by original author of the code. > Check comment above: > > // Read the full stream before feeding to X509Factory, > // otherwise, keytool -gencrl | keytool -printcrl > // might not work properly, since -gencrl is slow > // and there's no data in the pipe at the beginning. Let's keep it then ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From mchung at openjdk.java.net Mon Dec 21 20:06:58 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 21 Dec 2020 20:06:58 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v9] In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 12:00:48 GMT, Serguei Spitsyn wrote: >> This change have been already reviewed by Mandy, Sundar, Alan and David. >> Please, see the jdk 15 review thread: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html >> >> Now, the PR approval is needed. >> The push was postponed because the CSR was not approved at that time (it is now): >> https://bugs.openjdk.java.net/browse/JDK-8248189 >> Investigation of existing popular java agents was requested by Joe. >> ---------- >> >> The java.lang.instrument spec: >> https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html >> >> Summary: >> The java.lang.instrument spec clearly states: >> "The agent class must implement a public static premain method >> similar in principle to the main application entry point." >> Current implementation of sun/instrument/InstrumentationImpl.java >> allows the premain method be non-public which violates the spec. >> This fix aligns the implementation with the spec. >> >> Testing: >> A mach5 run of jdk_instrument tests is in progress. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. Suppress premain method check only if agent class is in unnamed module; 2. minor tests cleanup The change looks okay with minor comments on the tests. Nit: it will be good to update `@summary` in the InheritAgentxxxx tests that now fail to load the agent. W.r.t. the premain/agentmain method declared in the agent class, the specification clearly states that in the package summary: > The agent class must implement a public static premain method similar in principle to the main application entry point. > The agent class must implement a public static agentmain method. test/jdk/java/lang/instrument/PremainClass/NonPublicAgent.java line 27: > 25: * @test > 26: * @bug 8165276 > 27: * @summary Test that agent with non-public premain method is rejected to load the comment is incorrect. This tests a non-public agent class with a public premain method. The agent is not rejected. test/jdk/java/lang/instrument/RetransformAgent.java line 41: > 39: import asmlib.*; > 40: > 41: public class RetransformAgent { Making RetransformAgent as public is not necessary. This fix does not change this test and so better to revert it. test/jdk/java/lang/instrument/SimpleAgent.java line 26: > 24: import java.lang.instrument.Instrumentation; > 25: > 26: public class SimpleAgent { There is no other change in this test except making SImpleAgent as public which is not necessary. So better to revert it. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1694 From dcubed at openjdk.java.net Mon Dec 21 22:16:07 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 21 Dec 2020 22:16:07 GMT Subject: [jdk16] RFR: 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java Message-ID: ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI. ------------- Commit messages: - 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java Changes: https://git.openjdk.java.net/jdk16/pull/57/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=57&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258802 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/57.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/57/head:pull/57 PR: https://git.openjdk.java.net/jdk16/pull/57 From dcubed at openjdk.java.net Mon Dec 21 22:16:07 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 21 Dec 2020 22:16:07 GMT Subject: [jdk16] RFR: 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java In-Reply-To: References: Message-ID: <4V17EMVLkjvzEvxTXE2m034GAsOZW36cfo9n8WxAJPs=.fa94c4ba-734a-4027-827c-d2a664dbad2e@github.com> On Mon, 21 Dec 2020 22:09:33 GMT, Daniel D. Daugherty wrote: > ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI. Links to the JDK16 CI failures for each of the three tests are in the bug report. ------------- PR: https://git.openjdk.java.net/jdk16/pull/57 From amenkov at openjdk.java.net Mon Dec 21 22:47:54 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Mon, 21 Dec 2020 22:47:54 GMT Subject: [jdk16] RFR: 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 22:09:33 GMT, Daniel D. Daugherty wrote: > ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/57 From cjplummer at openjdk.java.net Mon Dec 21 23:29:56 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 21 Dec 2020 23:29:56 GMT Subject: [jdk16] RFR: 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 22:09:33 GMT, Daniel D. Daugherty wrote: > ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/57 From sspitsyn at openjdk.java.net Tue Dec 22 05:47:19 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 22 Dec 2020 05:47:19 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v9] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 20:04:39 GMT, Mandy Chung wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. Suppress premain method check only if agent class is in unnamed module; 2. minor tests cleanup > > The change looks okay with minor comments on the tests. Nit: it will be good to update `@summary` in the InheritAgentxxxx tests that now fail to load the agent. @mlchung All suggestions are right and addressed in the latest update. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From sspitsyn at openjdk.java.net Tue Dec 22 05:47:19 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 22 Dec 2020 05:47:19 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v10] In-Reply-To: References: Message-ID: <00q2A_kzFEXeSVclMIvmtgE1d09kGCgj36aMh4pRxoE=.dc6c5b29-ecab-4008-89ac-46df41c8dc31@github.com> > This change have been already reviewed by Mandy, Sundar, Alan and David. > Please, see the jdk 15 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html > > Now, the PR approval is needed. > The push was postponed because the CSR was not approved at that time (it is now): > https://bugs.openjdk.java.net/browse/JDK-8248189 > Investigation of existing popular java agents was requested by Joe. > ---------- > > The java.lang.instrument spec: > https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html > > Summary: > The java.lang.instrument spec clearly states: > "The agent class must implement a public static premain method > similar in principle to the main application entry point." > Current implementation of sun/instrument/InstrumentationImpl.java > allows the premain method be non-public which violates the spec. > This fix aligns the implementation with the spec. > > Testing: > A mach5 run of jdk_instrument tests is in progress. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: @summary of some negative tests is corrected ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1694/files - new: https://git.openjdk.java.net/jdk/pull/1694/files/412789d3..81cb0e49 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=08-09 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1694/head:pull/1694 PR: https://git.openjdk.java.net/jdk/pull/1694 From dcubed at openjdk.java.net Tue Dec 22 13:45:58 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 13:45:58 GMT Subject: [jdk16] Integrated: 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 22:09:33 GMT, Daniel D. Daugherty wrote: > ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI. This pull request has now been integrated. Changeset: 88dd6a94 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk16/commit/88dd6a94 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java Reviewed-by: amenkov, cjplummer ------------- PR: https://git.openjdk.java.net/jdk16/pull/57 From dcubed at openjdk.java.net Tue Dec 22 13:45:57 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 13:45:57 GMT Subject: [jdk16] RFR: 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 22:44:51 GMT, Alex Menkov wrote: >> ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI. > > Marked as reviewed by amenkov (Reviewer). @alexmenkov and @plummercj - Thanks for the fast reviews. ------------- PR: https://git.openjdk.java.net/jdk16/pull/57 From dcubed at openjdk.java.net Tue Dec 22 17:03:05 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 17:03:05 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows Message-ID: ProblemList two java/rmi/Naming tests on Windows in order to reduce the noise in the JDK16 CI. This is a trivial fix. ------------- Commit messages: - 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows Changes: https://git.openjdk.java.net/jdk16/pull/58/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=58&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258827 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/58.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/58/head:pull/58 PR: https://git.openjdk.java.net/jdk16/pull/58 From msheppar at openjdk.java.net Tue Dec 22 17:18:59 2020 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Tue, 22 Dec 2020 17:18:59 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty wrote: > ProblemList two java/rmi/Naming tests on Windows in order to reduce the > noise in the JDK16 CI. This is a trivial fix. LGTM ------------- Marked as reviewed by msheppar (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/58 From rriggs at openjdk.java.net Tue Dec 22 17:18:59 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 22 Dec 2020 17:18:59 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty wrote: > ProblemList two java/rmi/Naming tests on Windows in order to reduce the > noise in the JDK16 CI. This is a trivial fix. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/58 From prr at openjdk.java.net Tue Dec 22 17:19:00 2020 From: prr at openjdk.java.net (Phil Race) Date: Tue, 22 Dec 2020 17:19:00 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty wrote: > ProblemList two java/rmi/Naming tests on Windows in order to reduce the > noise in the JDK16 CI. This is a trivial fix. overdue ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/58 From dcubed at openjdk.java.net Tue Dec 22 17:19:00 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 17:19:00 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 17:14:24 GMT, Phil Race wrote: >> ProblemList two java/rmi/Naming tests on Windows in order to reduce the >> noise in the JDK16 CI. This is a trivial fix. > > overdue Thanks for the fast reviews! ------------- PR: https://git.openjdk.java.net/jdk16/pull/58 From dcubed at openjdk.java.net Tue Dec 22 17:19:01 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 17:19:01 GMT Subject: [jdk16] Integrated: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: <49rEuRYk_yWrf0W7mmQ16jRX3BlcOw0Xj-2-jGaqDqQ=.3b9cb617-a8b6-4b56-8ce0-01f9d4dc3aa0@github.com> On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty wrote: > ProblemList two java/rmi/Naming tests on Windows in order to reduce the > noise in the JDK16 CI. This is a trivial fix. This pull request has now been integrated. Changeset: eabc9030 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk16/commit/eabc9030 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows Reviewed-by: rriggs, msheppar, prr ------------- PR: https://git.openjdk.java.net/jdk16/pull/58 From mchung at openjdk.java.net Tue Dec 22 17:28:03 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Dec 2020 17:28:03 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v10] In-Reply-To: <00q2A_kzFEXeSVclMIvmtgE1d09kGCgj36aMh4pRxoE=.dc6c5b29-ecab-4008-89ac-46df41c8dc31@github.com> References: <00q2A_kzFEXeSVclMIvmtgE1d09kGCgj36aMh4pRxoE=.dc6c5b29-ecab-4008-89ac-46df41c8dc31@github.com> Message-ID: On Tue, 22 Dec 2020 05:47:19 GMT, Serguei Spitsyn wrote: >> This change have been already reviewed by Mandy, Sundar, Alan and David. >> Please, see the jdk 15 review thread: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html >> >> Now, the PR approval is needed. >> The push was postponed because the CSR was not approved at that time (it is now): >> https://bugs.openjdk.java.net/browse/JDK-8248189 >> Investigation of existing popular java agents was requested by Joe. >> ---------- >> >> The java.lang.instrument spec: >> https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html >> >> Summary: >> The java.lang.instrument spec clearly states: >> "The agent class must implement a public static premain method >> similar in principle to the main application entry point." >> Current implementation of sun/instrument/InstrumentationImpl.java >> allows the premain method be non-public which violates the spec. >> This fix aligns the implementation with the spec. >> >> Testing: >> A mach5 run of jdk_instrument tests is in progress. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > @summary of some negative tests is corrected test/jdk/java/lang/instrument/RetransformAgent.java line 26: > 24: /** > 25: * @test > 26: * @bug 6274264 6274241 5070281 8165276 The copyright header and `@bug` change should be reverted. test/jdk/java/lang/instrument/SimpleAgent.java line 2: > 1: /* > 2: * Copyright (c) 2016, 2020, Oracle and/or its affiliates. All rights reserved. The copyright header change should be reverted. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From dcubed at openjdk.java.net Tue Dec 22 17:47:06 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 17:47:06 GMT Subject: [jdk16] RFR: 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 Message-ID: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> This is a trivial fix to ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64. ------------- Commit messages: - 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 Changes: https://git.openjdk.java.net/jdk16/pull/59/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=59&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258832 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/59/head:pull/59 PR: https://git.openjdk.java.net/jdk16/pull/59 From ccheung at openjdk.java.net Tue Dec 22 17:58:59 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 22 Dec 2020 17:58:59 GMT Subject: [jdk16] RFR: 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 In-Reply-To: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> References: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> Message-ID: On Tue, 22 Dec 2020 17:42:49 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64. Looks good and trivial. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/59 From amenkov at openjdk.java.net Tue Dec 22 18:03:00 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 22 Dec 2020 18:03:00 GMT Subject: [jdk16] RFR: 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 In-Reply-To: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> References: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> Message-ID: On Tue, 22 Dec 2020 17:42:49 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/59 From amenkov at openjdk.java.net Tue Dec 22 18:16:55 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 22 Dec 2020 18:16:55 GMT Subject: RFR: 8257928: Test image build failure with clang-10 due to -Wmisleading-indentation In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 07:11:53 GMT, Hao Sun wrote: > Flag '-Wmisleading-indentation' was introduced since clang-10 [1] and > gcc-6 [2]. Putting the code with proper indentations would suppress this > warning. > > The main reason why test image build with gcc succeeds is that, clang > and gcc might behave differently for some corner cases under > '-Wmisleading-indentation'. > > The following code snippet is crafted based on this build failure, where > each statement with improper indentation (line A and line B) follows an > if-statement. The key difference between foo() and bar() lies in that > there exists an extra comment, i.e. "/* comment 2 */", between statement > at line A and the if-statement. > > int foo(int num) { > /* comment 1 */ > if (num > 1) > return 0; > > /* comment 2 */ > num = num + 1; // line A > return num; > } > > int bar(int val) { > /* comment 3 */ > if (val > 1) > return 0; > > val = val + 1; // line B > return val; > } > > It's worth noting that foo() is quite similar to the erroneous code in > this build failure. Clang-10 would emit misleading indentation warnings > for both foo() and bar(), whereas gcc-6 or higher considers foo() free > of problems. [3] > > This patch is a complement to JDK-8253892. In JDK-8253892, flag > '-Wmisleading-indentation' is disabled for both clang and gcc when > building JRE and JDK images. This patch does not disable the flag for > test image building, but just fixes the code, becasue: > - only a small number of warnings are produced and it's easy to fix > them one by one. > - inconsistent warning behaviors between gcc and clang are triggered > by this case and simply disabling the flag does not work. > > Note that AArch64 is NOT tested because test image build still fails > after this bug is fixed due to another runtime error (See JDK-8257936), > which is not related to this patch. > > [1] https://releases.llvm.org/10.0.0/tools/clang/docs/DiagnosticsReference.html > [2] https://gcc.gnu.org/onlinedocs/gcc-6.5.0/gcc/Warning-Options.html#Warning-Options > [3] https://godbolt.org/z/xs6xWv > > --------------------- > We have tested with this patch, the test image can be built successfully with clang-10 on Linux X86 machine. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1709 From dcubed at openjdk.java.net Tue Dec 22 19:01:57 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 19:01:57 GMT Subject: [jdk16] Integrated: 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 In-Reply-To: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> References: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> Message-ID: On Tue, 22 Dec 2020 17:42:49 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64. This pull request has now been integrated. Changeset: 61e5e393 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk16/commit/61e5e393 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 Reviewed-by: ccheung, amenkov ------------- PR: https://git.openjdk.java.net/jdk16/pull/59 From dcubed at openjdk.java.net Tue Dec 22 19:01:56 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 19:01:56 GMT Subject: [jdk16] RFR: 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 In-Reply-To: References: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> Message-ID: On Tue, 22 Dec 2020 18:00:29 GMT, Alex Menkov wrote: >> This is a trivial fix to ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64. > > Marked as reviewed by amenkov (Reviewer). Thanks for the fast reviews! ------------- PR: https://git.openjdk.java.net/jdk16/pull/59 From cjplummer at openjdk.java.net Tue Dec 22 19:19:55 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 22 Dec 2020 19:19:55 GMT Subject: RFR: 8257928: Test image build failure with clang-10 due to -Wmisleading-indentation In-Reply-To: References: Message-ID: <7e-w6rdmO_JE0zmLCVAptzuLlL6nLZ55ULxpqJEYu9c=.700ab28a-7e4a-4093-9110-379159dd9112@github.com> On Wed, 9 Dec 2020 07:11:53 GMT, Hao Sun wrote: > Flag '-Wmisleading-indentation' was introduced since clang-10 [1] and > gcc-6 [2]. Putting the code with proper indentations would suppress this > warning. > > The main reason why test image build with gcc succeeds is that, clang > and gcc might behave differently for some corner cases under > '-Wmisleading-indentation'. > > The following code snippet is crafted based on this build failure, where > each statement with improper indentation (line A and line B) follows an > if-statement. The key difference between foo() and bar() lies in that > there exists an extra comment, i.e. "/* comment 2 */", between statement > at line A and the if-statement. > > int foo(int num) { > /* comment 1 */ > if (num > 1) > return 0; > > /* comment 2 */ > num = num + 1; // line A > return num; > } > > int bar(int val) { > /* comment 3 */ > if (val > 1) > return 0; > > val = val + 1; // line B > return val; > } > > It's worth noting that foo() is quite similar to the erroneous code in > this build failure. Clang-10 would emit misleading indentation warnings > for both foo() and bar(), whereas gcc-6 or higher considers foo() free > of problems. [3] > > This patch is a complement to JDK-8253892. In JDK-8253892, flag > '-Wmisleading-indentation' is disabled for both clang and gcc when > building JRE and JDK images. This patch does not disable the flag for > test image building, but just fixes the code, becasue: > - only a small number of warnings are produced and it's easy to fix > them one by one. > - inconsistent warning behaviors between gcc and clang are triggered > by this case and simply disabling the flag does not work. > > Note that AArch64 is NOT tested because test image build still fails > after this bug is fixed due to another runtime error (See JDK-8257936), > which is not related to this patch. > > [1] https://releases.llvm.org/10.0.0/tools/clang/docs/DiagnosticsReference.html > [2] https://gcc.gnu.org/onlinedocs/gcc-6.5.0/gcc/Warning-Options.html#Warning-Options > [3] https://godbolt.org/z/xs6xWv > > --------------------- > We have tested with this patch, the test image can be built successfully with clang-10 on Linux X86 machine. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1709 From sspitsyn at openjdk.java.net Tue Dec 22 22:11:19 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 22 Dec 2020 22:11:19 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v11] In-Reply-To: References: Message-ID: > This change have been already reviewed by Mandy, Sundar, Alan and David. > Please, see the jdk 15 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html > > Now, the PR approval is needed. > The push was postponed because the CSR was not approved at that time (it is now): > https://bugs.openjdk.java.net/browse/JDK-8248189 > Investigation of existing popular java agents was requested by Joe. > ---------- > > The java.lang.instrument spec: > https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html > > Summary: > The java.lang.instrument spec clearly states: > "The agent class must implement a public static premain method > similar in principle to the main application entry point." > Current implementation of sun/instrument/InstrumentationImpl.java > allows the premain method be non-public which violates the spec. > This fix aligns the implementation with the spec. > > Testing: > A mach5 run of jdk_instrument tests is in progress. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: 1. Prperly reverted fixes in 3 tests; 2. Got rid of term in tests summary comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1694/files - new: https://git.openjdk.java.net/jdk/pull/1694/files/81cb0e49..219a2cd6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=09-10 Stats: 15 lines in 12 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/1694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1694/head:pull/1694 PR: https://git.openjdk.java.net/jdk/pull/1694 From sspitsyn at openjdk.java.net Tue Dec 22 22:14:56 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 22 Dec 2020 22:14:56 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v9] In-Reply-To: References: Message-ID: <0T_iHmglzMrlCZl0UpypbWNKlHmffWekz3uHy_p-6G4=.db0349c5-7fcc-4007-bc27-c30bdfeb1ec1@github.com> On Mon, 21 Dec 2020 20:04:39 GMT, Mandy Chung wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. Suppress premain method check only if agent class is in unnamed module; 2. minor tests cleanup > > The change looks okay with minor comments on the tests. Nit: it will be good to update `@summary` in the InheritAgentxxxx tests that now fail to load the agent. @mlchung Thank you for the catch! Fixed it. Also, reverted the fix in the NativeMethodPrefixAgent.java. Additionally, got rid of the 'inherited' term in the summary of InheritAgent*.java tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From mchung at openjdk.java.net Tue Dec 22 23:09:58 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Dec 2020 23:09:58 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v11] In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 22:11:19 GMT, Serguei Spitsyn wrote: >> This change have been already reviewed by Mandy, Sundar, Alan and David. >> Please, see the jdk 15 review thread: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html >> >> Now, the PR approval is needed. >> The push was postponed because the CSR was not approved at that time (it is now): >> https://bugs.openjdk.java.net/browse/JDK-8248189 >> Investigation of existing popular java agents was requested by Joe. >> ---------- >> >> The java.lang.instrument spec: >> https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html >> >> Summary: >> The java.lang.instrument spec clearly states: >> "The agent class must implement a public static premain method >> similar in principle to the main application entry point." >> Current implementation of sun/instrument/InstrumentationImpl.java >> allows the premain method be non-public which violates the spec. >> This fix aligns the implementation with the spec. >> >> Testing: >> A mach5 run of jdk_instrument tests is in progress. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. Prperly reverted fixes in 3 tests; 2. Got rid of term in tests summary comment Thanks for the change. Looks okay. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1694 From sspitsyn at openjdk.java.net Tue Dec 22 23:59:56 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 22 Dec 2020 23:59:56 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v11] In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 23:07:12 GMT, Mandy Chung wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. Prperly reverted fixes in 3 tests; 2. Got rid of term in tests summary comment > > Thanks for the change. Looks okay. Thank you a lot, Mandy! Sorry for missed changes and overlooked issues in tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From github.com+16932759+shqking at openjdk.java.net Wed Dec 23 01:34:56 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Wed, 23 Dec 2020 01:34:56 GMT Subject: Integrated: 8257928: Test image build failure with clang-10 due to -Wmisleading-indentation In-Reply-To: References: Message-ID: <7NtRFBxuoWO8Z18Xf59SnIZDZpDHAFgKZ9XVFlydVuo=.51a8cfac-dbde-4857-baf6-d99f37c52e66@github.com> On Wed, 9 Dec 2020 07:11:53 GMT, Hao Sun wrote: > Flag '-Wmisleading-indentation' was introduced since clang-10 [1] and > gcc-6 [2]. Putting the code with proper indentations would suppress this > warning. > > The main reason why test image build with gcc succeeds is that, clang > and gcc might behave differently for some corner cases under > '-Wmisleading-indentation'. > > The following code snippet is crafted based on this build failure, where > each statement with improper indentation (line A and line B) follows an > if-statement. The key difference between foo() and bar() lies in that > there exists an extra comment, i.e. "/* comment 2 */", between statement > at line A and the if-statement. > > int foo(int num) { > /* comment 1 */ > if (num > 1) > return 0; > > /* comment 2 */ > num = num + 1; // line A > return num; > } > > int bar(int val) { > /* comment 3 */ > if (val > 1) > return 0; > > val = val + 1; // line B > return val; > } > > It's worth noting that foo() is quite similar to the erroneous code in > this build failure. Clang-10 would emit misleading indentation warnings > for both foo() and bar(), whereas gcc-6 or higher considers foo() free > of problems. [3] > > This patch is a complement to JDK-8253892. In JDK-8253892, flag > '-Wmisleading-indentation' is disabled for both clang and gcc when > building JRE and JDK images. This patch does not disable the flag for > test image building, but just fixes the code, becasue: > - only a small number of warnings are produced and it's easy to fix > them one by one. > - inconsistent warning behaviors between gcc and clang are triggered > by this case and simply disabling the flag does not work. > > Note that AArch64 is NOT tested because test image build still fails > after this bug is fixed due to another runtime error (See JDK-8257936), > which is not related to this patch. > > [1] https://releases.llvm.org/10.0.0/tools/clang/docs/DiagnosticsReference.html > [2] https://gcc.gnu.org/onlinedocs/gcc-6.5.0/gcc/Warning-Options.html#Warning-Options > [3] https://godbolt.org/z/xs6xWv > > --------------------- > We have tested with this patch, the test image can be built successfully with clang-10 on Linux X86 machine. This pull request has now been integrated. Changeset: 4ea88512 Author: Hao Sun Committer: Ningsheng Jian URL: https://git.openjdk.java.net/jdk/commit/4ea88512 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod 8257928: Test image build failure with clang-10 due to -Wmisleading-indentation Reviewed-by: amenkov, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/1709 From alanb at openjdk.java.net Wed Dec 23 14:08:58 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 23 Dec 2020 14:08:58 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v11] In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 22:11:19 GMT, Serguei Spitsyn wrote: >> This change have been already reviewed by Mandy, Sundar, Alan and David. >> Please, see the jdk 15 review thread: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html >> >> Now, the PR approval is needed. >> The push was postponed because the CSR was not approved at that time (it is now): >> https://bugs.openjdk.java.net/browse/JDK-8248189 >> Investigation of existing popular java agents was requested by Joe. >> ---------- >> >> The java.lang.instrument spec: >> https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html >> >> Summary: >> The java.lang.instrument spec clearly states: >> "The agent class must implement a public static premain method >> similar in principle to the main application entry point." >> Current implementation of sun/instrument/InstrumentationImpl.java >> allows the premain method be non-public which violates the spec. >> This fix aligns the implementation with the spec. >> >> Testing: >> A mach5 run of jdk_instrument tests is in progress. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. Prperly reverted fixes in 3 tests; 2. Got rid of term in tests summary comment Thanks for persevering on this one. The updated checks look good. At some point I think we re-examine the issue of allowing agents to be non-public, maybe emit a warning and eventually disallow it. If/when support is added for developing and deployed java agents as modules it might be the time to re-examine it. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1694 From sspitsyn at openjdk.java.net Wed Dec 23 18:05:03 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 23 Dec 2020 18:05:03 GMT Subject: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v11] In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 14:06:27 GMT, Alan Bateman wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. Prperly reverted fixes in 3 tests; 2. Got rid of term in tests summary comment > > Thanks for persevering on this one. The updated checks look good. At some point I think we re-examine the issue of allowing agents to be non-public, maybe emit a warning and eventually disallow it. If/when support is added for developing and deployed java agents as modules it might be the time to re-examine it. Thank you for review, Alan! ------------- PR: https://git.openjdk.java.net/jdk/pull/1694 From dcubed at openjdk.java.net Wed Dec 23 20:30:04 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 20:30:04 GMT Subject: RFR: 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 Message-ID: This is a trivial fix to ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64. The test has been failing fairly frequently in the JDK17 CI when it is run with the "-XX:NativeMemoryTracking=detail" option. We currently only specify that configuration on linux-x64 so I'm going to ProblemList the test only on Linux-X64 ------------- Commit messages: - 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 Changes: https://git.openjdk.java.net/jdk/pull/1884/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1884&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258911 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1884.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1884/head:pull/1884 PR: https://git.openjdk.java.net/jdk/pull/1884 From amenkov at openjdk.java.net Wed Dec 23 20:30:04 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 23 Dec 2020 20:30:04 GMT Subject: RFR: 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 20:21:12 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java > on Linux-X64. > > The test has been failing fairly frequently in the JDK17 CI when it is run with the > "-XX:NativeMemoryTracking=detail" option. We currently only specify that configuration > on linux-x64 so I'm going to ProblemList the test only on Linux-X64 Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1884 From amenkov at openjdk.java.net Wed Dec 23 20:30:04 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 23 Dec 2020 20:30:04 GMT Subject: RFR: 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 In-Reply-To: References: Message-ID: <2Se2GVQpFdDWKCAkDDNiRgHGp6WLHuPZq3AXriQbTjA=.8bf1e4b8-9408-44a9-aacf-f7a9f4ae7539@github.com> On Wed, 23 Dec 2020 20:26:36 GMT, Alex Menkov wrote: >> This is a trivial fix to ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java >> on Linux-X64. >> >> The test has been failing fairly frequently in the JDK17 CI when it is run with the >> "-XX:NativeMemoryTracking=detail" option. We currently only specify that configuration >> on linux-x64 so I'm going to ProblemList the test only on Linux-X64 > > Marked as reviewed by amenkov (Reviewer). Agreed that this is trivial fix ------------- PR: https://git.openjdk.java.net/jdk/pull/1884 From dcubed at openjdk.java.net Wed Dec 23 20:33:57 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 20:33:57 GMT Subject: Integrated: 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 In-Reply-To: References: Message-ID: <-LSg054SDXlaEEkH5QT90MbSD8wcErL1C-m9VyyI3PQ=.fbf6d653-2257-4c2c-8a00-6c8434e1e89d@github.com> On Wed, 23 Dec 2020 20:21:12 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java > on Linux-X64. > > The test has been failing fairly frequently in the JDK17 CI when it is run with the > "-XX:NativeMemoryTracking=detail" option. We currently only specify that configuration > on linux-x64 so I'm going to ProblemList the test only on Linux-X64 This pull request has now been integrated. Changeset: e46edb55 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/e46edb55 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 Reviewed-by: amenkov ------------- PR: https://git.openjdk.java.net/jdk/pull/1884 From dcubed at openjdk.java.net Wed Dec 23 20:33:56 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 20:33:56 GMT Subject: RFR: 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 In-Reply-To: <2Se2GVQpFdDWKCAkDDNiRgHGp6WLHuPZq3AXriQbTjA=.8bf1e4b8-9408-44a9-aacf-f7a9f4ae7539@github.com> References: <2Se2GVQpFdDWKCAkDDNiRgHGp6WLHuPZq3AXriQbTjA=.8bf1e4b8-9408-44a9-aacf-f7a9f4ae7539@github.com> Message-ID: <7DtSWRcblQK5-8aVdvT0venPIuSsNPh94Ggix8wYHzA=.fb0e335f-aba9-4df3-a182-87ca07d5fa1c@github.com> On Wed, 23 Dec 2020 20:27:11 GMT, Alex Menkov wrote: >> Marked as reviewed by amenkov (Reviewer). > > Agreed that this is trivial fix @alexmenkov - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1884 From dcubed at openjdk.java.net Thu Dec 24 17:43:04 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 24 Dec 2020 17:43:04 GMT Subject: RFR: 8231627: runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java fails because error occurred during printing all threads Message-ID: <2UBK37oWUs8yehzfftzswNyDs53HFQ-hhexvGlcuJwk=.4a65ade2-cde6-45af-b599-de35339671c7@github.com> A small robustness fix in ThreadsSMRSupport::print_info_on() to reduce the likelihood of crashes during error reporting. Uses Threads_lock->try_lock() for safety and restricts some reporting to when the Threads_lock has been acquired (depends on JDK-8256383). Uses a ThreadsListHandle to make the current ThreadsList safe for reporting (depends on JDK-8258284). Also detects when the system ThreadsList (_java_thread_list) has changed and will warn that some of the reported info may now be stale. Two existing tests have been updated to reflect the use of a ThreadsListHandle in ThreadsSMRSupport::print_info_on(). Mach5 Tier[1-6] testing has no regressions. ------------- Commit messages: - 8231627: runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java fails because error occurred during printing all threads Changes: https://git.openjdk.java.net/jdk/pull/1891/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1891&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231627 Stats: 68 lines in 3 files changed: 39 ins; 5 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/1891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1891/head:pull/1891 PR: https://git.openjdk.java.net/jdk/pull/1891 From dcubed at openjdk.java.net Thu Dec 24 17:43:04 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 24 Dec 2020 17:43:04 GMT Subject: RFR: 8231627: runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java fails because error occurred during printing all threads In-Reply-To: <2UBK37oWUs8yehzfftzswNyDs53HFQ-hhexvGlcuJwk=.4a65ade2-cde6-45af-b599-de35339671c7@github.com> References: <2UBK37oWUs8yehzfftzswNyDs53HFQ-hhexvGlcuJwk=.4a65ade2-cde6-45af-b599-de35339671c7@github.com> Message-ID: On Thu, 24 Dec 2020 17:33:21 GMT, Daniel D. Daugherty wrote: > A small robustness fix in ThreadsSMRSupport::print_info_on() to reduce the > likelihood of crashes during error reporting. Uses Threads_lock->try_lock() > for safety and restricts some reporting to when the Threads_lock has been > acquired (depends on JDK-8256383). Uses a ThreadsListHandle to make > the current ThreadsList safe for reporting (depends on JDK-8258284). Also > detects when the system ThreadsList (_java_thread_list) has changed and > will warn that some of the reported info may now be stale. > > Two existing tests have been updated to reflect the use of a ThreadsListHandle > in ThreadsSMRSupport::print_info_on(). Mach5 Tier[1-6] testing has no regressions. @dholmes-ora, @fisk and @robehn - You folks might be interested in this Thread-SMR related robustness fix. It should help during error reporting. ------------- PR: https://git.openjdk.java.net/jdk/pull/1891 From eosterlund at openjdk.java.net Thu Dec 24 22:03:54 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Dec 2020 22:03:54 GMT Subject: RFR: 8231627: runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java fails because error occurred during printing all threads In-Reply-To: <2UBK37oWUs8yehzfftzswNyDs53HFQ-hhexvGlcuJwk=.4a65ade2-cde6-45af-b599-de35339671c7@github.com> References: <2UBK37oWUs8yehzfftzswNyDs53HFQ-hhexvGlcuJwk=.4a65ade2-cde6-45af-b599-de35339671c7@github.com> Message-ID: <0K6JjE__AaTO7A8wYchNtc19_87t1cSxnsmBllJCFW0=.2d3efed6-5f2c-481d-ba47-141538c63d9c@github.com> On Thu, 24 Dec 2020 17:33:21 GMT, Daniel D. Daugherty wrote: > A small robustness fix in ThreadsSMRSupport::print_info_on() to reduce the > likelihood of crashes during error reporting. Uses Threads_lock->try_lock() > for safety and restricts some reporting to when the Threads_lock has been > acquired (depends on JDK-8256383). Uses a ThreadsListHandle to make > the current ThreadsList safe for reporting (depends on JDK-8258284). Also > detects when the system ThreadsList (_java_thread_list) has changed and > will warn that some of the reported info may now be stale. > > Two existing tests have been updated to reflect the use of a ThreadsListHandle > in ThreadsSMRSupport::print_info_on(). Mach5 Tier[1-6] testing has no regressions. Looks good. We have something similar in the precious GC log code during error reporting. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1891 From dcubed at openjdk.java.net Thu Dec 24 22:09:55 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 24 Dec 2020 22:09:55 GMT Subject: RFR: 8231627: runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java fails because error occurred during printing all threads In-Reply-To: <0K6JjE__AaTO7A8wYchNtc19_87t1cSxnsmBllJCFW0=.2d3efed6-5f2c-481d-ba47-141538c63d9c@github.com> References: <2UBK37oWUs8yehzfftzswNyDs53HFQ-hhexvGlcuJwk=.4a65ade2-cde6-45af-b599-de35339671c7@github.com> <0K6JjE__AaTO7A8wYchNtc19_87t1cSxnsmBllJCFW0=.2d3efed6-5f2c-481d-ba47-141538c63d9c@github.com> Message-ID: On Thu, 24 Dec 2020 22:01:38 GMT, Erik ?sterlund wrote: >> A small robustness fix in ThreadsSMRSupport::print_info_on() to reduce the >> likelihood of crashes during error reporting. Uses Threads_lock->try_lock() >> for safety and restricts some reporting to when the Threads_lock has been >> acquired (depends on JDK-8256383). Uses a ThreadsListHandle to make >> the current ThreadsList safe for reporting (depends on JDK-8258284). Also >> detects when the system ThreadsList (_java_thread_list) has changed and >> will warn that some of the reported info may now be stale. >> >> Two existing tests have been updated to reflect the use of a ThreadsListHandle >> in ThreadsSMRSupport::print_info_on(). Mach5 Tier[1-6] testing has no regressions. > > Looks good. We have something similar in the precious GC log code during error reporting. @fisk - Thanks for the review! And Merry Christmas Eve!! ------------- PR: https://git.openjdk.java.net/jdk/pull/1891 From eosterlund at openjdk.java.net Thu Dec 24 22:17:59 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Dec 2020 22:17:59 GMT Subject: RFR: 8231627: runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java fails because error occurred during printing all threads In-Reply-To: <0K6JjE__AaTO7A8wYchNtc19_87t1cSxnsmBllJCFW0=.2d3efed6-5f2c-481d-ba47-141538c63d9c@github.com> References: <2UBK37oWUs8yehzfftzswNyDs53HFQ-hhexvGlcuJwk=.4a65ade2-cde6-45af-b599-de35339671c7@github.com> <0K6JjE__AaTO7A8wYchNtc19_87t1cSxnsmBllJCFW0=.2d3efed6-5f2c-481d-ba47-141538c63d9c@github.com> Message-ID: On Thu, 24 Dec 2020 22:01:38 GMT, Erik ?sterlund wrote: >> A small robustness fix in ThreadsSMRSupport::print_info_on() to reduce the >> likelihood of crashes during error reporting. Uses Threads_lock->try_lock() >> for safety and restricts some reporting to when the Threads_lock has been >> acquired (depends on JDK-8256383). Uses a ThreadsListHandle to make >> the current ThreadsList safe for reporting (depends on JDK-8258284). Also >> detects when the system ThreadsList (_java_thread_list) has changed and >> will warn that some of the reported info may now be stale. >> >> Two existing tests have been updated to reflect the use of a ThreadsListHandle >> in ThreadsSMRSupport::print_info_on(). Mach5 Tier[1-6] testing has no regressions. > > Looks good. We have something similar in the precious GC log code during error reporting. > @fisk - Thanks for the review! And Merry Christmas Eve!! Merry Christmas to you too Dan! ------------- PR: https://git.openjdk.java.net/jdk/pull/1891 From ysuenaga at openjdk.java.net Thu Dec 31 00:18:07 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 31 Dec 2020 00:18:07 GMT Subject: RFR: 8259008: ArithmeticException was thrown at "Monitor Cache Dump" on HSDB Message-ID: <0iZCD-O-3IYg8mATfnTUH1DH7oLF-mPFNWOuyKVqEnE=.62161c51-36d9-4bd0-8505-c027258d18df@github.com> I saw the exception as following when I chose "Monitor Cache Dump" menu on HSDB: Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError at jdk.hotspot.agent/sun.jvm.hotspot.ui.MonitorCacheDumpPanel.dumpOn(MonitorCacheDumpPanel.java:92) at jdk.hotspot.agent/sun.jvm.hotspot.ui.MonitorCacheDumpPanel.(MonitorCacheDumpPanel.java:59) at jdk.hotspot.agent/sun.jvm.hotspot.HSDB.showMonitorCacheDumpPanel(HSDB.java:1556) at jdk.hotspot.agent/sun.jvm.hotspot.HSDB$16.actionPerformed(HSDB.java:338) at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1972) at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2313) at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405) at java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262) at java.desktop/javax.swing.AbstractButton.doClick(AbstractButton.java:374) at java.desktop/javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1022) at java.desktop/javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1066) at java.desktop/java.awt.Component.processMouseEvent(Component.java:6617) at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342) at java.desktop/java.awt.Component.processEvent(Component.java:6382) at java.desktop/java.awt.Container.processEvent(Container.java:2264) at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4993) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2322) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4825) at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4934) at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4563) at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4504) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2308) at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2773) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4825) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743) at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) Caused by: java.lang.ArithmeticException: / by zero at jdk.hotspot.agent/sun.jvm.hotspot.runtime.ObjectSynchronizer.initialize(ObjectSynchronizer.java:55) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.ObjectSynchronizer$1.update(ObjectSynchronizer.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:578) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.ObjectSynchronizer.(ObjectSynchronizer.java:38) ... 41 more This exception seems to be caused by [JDK-8253064](https://bugs.openjdk.java.net/browse/JDK-8253064). It has changed `ObjectSynchronizer`, but it has not changed SA code. ------------- Commit messages: - 8259008: ArithmeticException was thrown at "Monitor Cache Dump" on HSDB Changes: https://git.openjdk.java.net/jdk/pull/1910/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1910&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259008 Stats: 182 lines in 5 files changed: 130 ins; 38 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1910.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1910/head:pull/1910 PR: https://git.openjdk.java.net/jdk/pull/1910 From ysuenaga at openjdk.java.net Thu Dec 31 00:19:09 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 31 Dec 2020 00:19:09 GMT Subject: RFR: 8259009: G1 heap summary should be shown in "Heap Parameters" window on HSDB Message-ID: <0H5ICCOuS2CMe6xjvEKSAi_T3qGsTsamid4pzp7EV18=.b7219f71-9be3-40e0-8605-3d0b7edd9e99@github.com> G1 heap summary (G1 Heap, summaries for each spaces) is shown on console even though I chosen "Heap Parameters" menu on HSDB. It should be shown on "Heap Parameters" window on HSDB. ------------- Commit messages: - G1 heap summary should be shown in "Heap Parameters" window on HSDB Changes: https://git.openjdk.java.net/jdk/pull/1911/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1911&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259009 Stats: 31 lines in 2 files changed: 14 ins; 1 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1911.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1911/head:pull/1911 PR: https://git.openjdk.java.net/jdk/pull/1911