Re: RFR: 8192647: GClocker induced GCs can starve threads requiring memory leading to OOME [v2]

2025-02-06 Thread David Holmes
On Thu, 6 Feb 2025 21:42:50 GMT, Albert Mingkun Yang wrote: > The storeload barrier is critical ... I'm not sure it is sufficient. I would have expected some full fences to be needed here as this is very similar to the interaction of thread state with safepoints. I will look closer on Monday

Re: RFR: 8192647: GClocker induced GCs can starve threads requiring memory leading to OOME [v2]

2025-02-06 Thread David Holmes
On Thu, 6 Feb 2025 21:42:50 GMT, Albert Mingkun Yang wrote: > in_critical() is used only by the owning thread, I see code using `thr->in_critical()` which is not obviously being executed by the current thread on itself. But in any case adding the atomic load to `in_critical()` is basically a n

Re: RFR: 8319055: JCMD should not buffer the whole output of commands [v2]

2025-02-06 Thread Alex Menkov
On Thu, 6 Feb 2025 17:35:08 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> feedback > > test/hotspot/jtreg/serviceability/attach/AttachAPIv2/StreamingOutputTest.java > line 86: > >> 84: >> 8

Re: RFR: 8319055: JCMD should not buffer the whole output of commands [v2]

2025-02-06 Thread Alex Menkov
On Thu, 6 Feb 2025 17:34:01 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> feedback > > test/hotspot/jtreg/serviceability/attach/AttachAPIv2/StreamingOutputTest.java > line 70: > >> 68: >> 6

Re: RFR: 8319055: JCMD should not buffer the whole output of commands [v3]

2025-02-06 Thread Alex Menkov
On Tue, 4 Feb 2025 10:10:41 GMT, Johan Sjölen wrote: >> Alex Menkov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> feedback - test > > src/hotspot/share/services/attachListener.cpp line 53: > >> 51: >> 52: // Stream for printing attac

Re: RFR: 8319055: JCMD should not buffer the whole output of commands [v3]

2025-02-06 Thread Alex Menkov
On Wed, 5 Feb 2025 07:24:29 GMT, Thomas Stuefe wrote: >> This is for [JDK-8319307](https://bugs.openjdk.org/browse/JDK-8319307) >> @tstuefe Do you want to keep this comment to work on JDK-8319307? > > You can remove it. Removed - PR Review Comment: https://git.openjdk.org/jdk/pull/

Re: RFR: 8346567: Make Class.getModifiers() non-native [v5]

2025-02-06 Thread Coleen Phillimore
On Thu, 6 Feb 2025 14:31:28 GMT, Coleen Phillimore wrote: >> The Class.getModifiers() method is implemented as a native method in >> java.lang.Class to access a field that we've calculated when creating the >> mirror. The field is final after that point. The VM doesn't need it >> anymore, so

Re: RFR: 8346567: Make Class.getModifiers() non-native [v6]

2025-02-06 Thread Coleen Phillimore
> The Class.getModifiers() method is implemented as a native method in > java.lang.Class to access a field that we've calculated when creating the > mirror. The field is final after that point. The VM doesn't need it anymore, > so there's no real need for the jdk code to call into the VM to get

RFR: 8349571: Remove JavaThreadFactory interface from SA

2025-02-06 Thread Chris Plummer
The SA JavaThreadFactory interface is no longer used, so it is being removed. I stumbled on it while looking at JavaThread related code. It looks like it's original purpose is related to JavaThread subclasses at one point being platform dependent, as described in the following JavaThread.java co

Re: RFR: 8348347: Cleanup JavaThread subclass support in SA [v2]

2025-02-06 Thread Chris Plummer
> Cleanup SA JavaThread support. Details in first comment: > > Testing: > - Tier1 > - Tier2 svc > - Tier3 > - Tier5 svc > - Local testing of debuggee using graal java compiler threads. Verified that > the compiler threads shows up in jstack output if the property is set. Chris Plummer has update

Re: RFR: 8192647: GClocker induced GCs can starve threads requiring memory leading to OOME [v2]

2025-02-06 Thread Albert Mingkun Yang
On Thu, 6 Feb 2025 06:35:46 GMT, David Holmes wrote: > can you explain how this protocol is intended to work please. When a GC is requested, the `block()` function sets `_is_gc_request_pending` to `true` and then waits until all threads have exited their critical regions. Any thread attemptin

Re: RFR: 8346567: Make Class.getModifiers() non-native [v5]

2025-02-06 Thread Vladimir Ivanov
On Thu, 6 Feb 2025 14:31:28 GMT, Coleen Phillimore wrote: >> The Class.getModifiers() method is implemented as a native method in >> java.lang.Class to access a field that we've calculated when creating the >> mirror. The field is final after that point. The VM doesn't need it >> anymore, so

Re: RFR: 8346567: Make Class.getModifiers() non-native [v2]

2025-02-06 Thread Vladimir Ivanov
On Thu, 6 Feb 2025 13:08:31 GMT, Coleen Phillimore wrote: >> Does `static final` help here? > > Yes. Yes it does. Cases when a class mirror is a compile-time constant are already well-optimized. Non constant cases are the ones where missing optimization opportunities arise. In this particul

Re: RFR: 8319055: JCMD should not buffer the whole output of commands [v3]

2025-02-06 Thread Alex Menkov
> The fix implements streaming output support for attach protocol. > See JBS issue for evaluation, summary of the changes in the 1st comment. > Testing: tier1..4,hs-tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: feedback - t

Re: RFR: 8319055: JCMD should not buffer the whole output of commands [v2]

2025-02-06 Thread Serguei Spitsyn
On Wed, 5 Feb 2025 20:11:53 GMT, Alex Menkov wrote: >> The fix implements streaming output support for attach protocol. >> See JBS issue for evaluation, summary of the changes in the 1st comment. >> Testing: tier1..4,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one

Re: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3]

2025-02-06 Thread Coleen Phillimore
On Fri, 15 Nov 2024 15:30:05 GMT, Coleen Phillimore wrote: >> This change adds a couple of comments, removes some ancient bootstrapping >> code, and adds an old test that we call the verifier for redefining a class, >> even one in the bootclass path. >> >> The fix for always verifying redefine

Re: RFR: 8346567: Make Class.getModifiers() non-native [v5]

2025-02-06 Thread Chen Liang
On Thu, 6 Feb 2025 12:08:59 GMT, Coleen Phillimore wrote: >> If Class had other fields smaller than `int`, would be consider making this >> something like `char` to save space (allowing all the sub-word fields to be >> compacted)? > > I thought of doing this since I made modifiers u2 in the Hot

Re: RFR: 8346567: Make Class.getModifiers() non-native [v5]

2025-02-06 Thread Coleen Phillimore
> The Class.getModifiers() method is implemented as a native method in > java.lang.Class to access a field that we've calculated when creating the > mirror. The field is final after that point. The VM doesn't need it anymore, > so there's no real need for the jdk code to call into the VM to get

Re: RFR: 8346567: Make Class.getModifiers() non-native [v2]

2025-02-06 Thread Coleen Phillimore
On Wed, 5 Feb 2025 21:26:29 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix copyright and param name > > src/hotspot/share/oops/instanceKlass.hpp line 1128: > >> 1126: #endif >> 1127: >> 1

Re: RFR: 8346567: Make Class.getModifiers() non-native [v4]

2025-02-06 Thread Coleen Phillimore
> The Class.getModifiers() method is implemented as a native method in > java.lang.Class to access a field that we've calculated when creating the > mirror. The field is final after that point. The VM doesn't need it anymore, > so there's no real need for the jdk code to call into the VM to get

Re: RFR: 8346567: Make Class.getModifiers() non-native [v2]

2025-02-06 Thread Coleen Phillimore
On Thu, 6 Feb 2025 04:37:17 GMT, Chen Liang wrote: >> OK, if the extra load turns out to be a problem in the future, we could look >> into why the compilers are generating the load when the Class is >> known/constant. If the old intrinsic was able to pull the constant out of >> the Klass, the

Re: RFR: 8346567: Make Class.getModifiers() non-native [v2]

2025-02-06 Thread Coleen Phillimore
On Wed, 5 Feb 2025 21:24:25 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix copyright and param name > > src/hotspot/share/compiler/compileLog.cpp line 116: > >> 114: print(" unload

Re: RFR: 8346567: Make Class.getModifiers() non-native [v3]

2025-02-06 Thread Coleen Phillimore
> The Class.getModifiers() method is implemented as a native method in > java.lang.Class to access a field that we've calculated when creating the > mirror. The field is final after that point. The VM doesn't need it anymore, > so there's no real need for the jdk code to call into the VM to get

Re: RFR: 8346567: Make Class.getModifiers() non-native [v2]

2025-02-06 Thread Coleen Phillimore
On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore wrote: >> The Class.getModifiers() method is implemented as a native method in >> java.lang.Class to access a field that we've calculated when creating the >> mirror. The field is final after that point. The VM doesn't need it >> anymore, so

Re: RFR: 8346567: Make Class.getModifiers() non-native [v2]

2025-02-06 Thread Coleen Phillimore
On Wed, 5 Feb 2025 21:44:37 GMT, Dean Long wrote: >> @DanHeidinga Great explanation, thank you! > > If Class had other fields smaller than `int`, would be consider making this > something like `char` to save space (allowing all the sub-word fields to be > compacted)? I thought of doing this si