Re: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v7]

2021-10-19 Thread Richard Reingruber
On Tue, 19 Oct 2021 20:17:59 GMT, Chris Plummer wrote: >> Richard Reingruber has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Call blockOnDebuggerSuspend() after setup of the resumer tracking. > > src/jdk.jdwp.agent/share/native/libjdwp/t

Re: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5]

2021-10-19 Thread Jakob Cornell
On Thu, 23 Sep 2021 15:24:47 GMT, Jakob Cornell wrote: >> This has been under discussion on and off for the past month or so on >> serviceability-dev, and I think a CSR request is required, so this may be a >> work in progress. >> >> Notes on the patch: >> >> - The `list` command previously m

Re: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v6]

2021-10-19 Thread Jakob Cornell
> This has been under discussion on and off for the past month or so on > serviceability-dev, and I think a CSR request is required, so this may be a > work in progress. > > Notes on the patch: > > - The `list` command previously marked a line in each listing with `=>`. In > a bare `list` thi

Re: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager

2021-10-19 Thread Serguei Spitsyn
On Wed, 13 Oct 2021 04:17:25 GMT, Ioi Lam wrote: > LocalVmManager and PerfDataFile have APIs that are supposed to look for VMs > owned by a specific user. No one uses these APIs, and they don't work anyway. > > The current code is very confusing to look at. Since we're likely to change > code

Re: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5]

2021-10-19 Thread Chris Plummer
On Tue, 19 Oct 2021 21:52:14 GMT, Ioi Lam wrote: > > > Hi Jacob, this is not your fault, but the "zz help text" in the Chinese > > > and Japanese versions are in a single huge line. This makes it impossible > > > to see what you have changed in the GitHub diffs, and impossible to tell > > > wh

Re: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager

2021-10-19 Thread Chris Plummer
On Tue, 19 Oct 2021 21:41:41 GMT, Ioi Lam wrote: >> src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java >> line 80: >> >>> 78: "^hsperfdata_[0-9]+(_[1-2]+)?$"; >>> 79: >>> 80: >> >> I don't understand why you thought it best to rem

Re: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager

2021-10-19 Thread Chris Plummer
On Wed, 13 Oct 2021 04:17:25 GMT, Ioi Lam wrote: > LocalVmManager and PerfDataFile have APIs that are supposed to look for VMs > owned by a specific user. No one uses these APIs, and they don't work anyway. > > The current code is very confusing to look at. Since we're likely to change > code

Re: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5]

2021-10-19 Thread Ioi Lam
On Tue, 19 Oct 2021 21:26:11 GMT, Chris Plummer wrote: > > Hi Jacob, this is not your fault, but the "zz help text" in the Chinese and > > Japanese versions are in a single huge line. This makes it impossible to > > see what you have changed in the GitHub diffs, and impossible to tell > > whet

Re: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager

2021-10-19 Thread Ioi Lam
On Tue, 19 Oct 2021 21:17:57 GMT, Chris Plummer wrote: >> LocalVmManager and PerfDataFile have APIs that are supposed to look for VMs >> owned by a specific user. No one uses these APIs, and they don't work anyway. >> >> The current code is very confusing to look at. Since we're likely to chang

Re: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5]

2021-10-19 Thread Chris Plummer
On Tue, 19 Oct 2021 21:16:03 GMT, Ioi Lam wrote: > Hi Jacob, this is not your fault, but the "zz help text" in the Chinese and > Japanese versions are in a single huge line. This makes it impossible to see > what you have changed in the GitHub diffs, and impossible to tell whether you > made a

Re: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager

2021-10-19 Thread Chris Plummer
On Wed, 13 Oct 2021 04:17:25 GMT, Ioi Lam wrote: > LocalVmManager and PerfDataFile have APIs that are supposed to look for VMs > owned by a specific user. No one uses these APIs, and they don't work anyway. > > The current code is very confusing to look at. Since we're likely to change > code

Re: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5]

2021-10-19 Thread Ioi Lam
On Thu, 23 Sep 2021 15:24:47 GMT, Jakob Cornell wrote: >> This has been under discussion on and off for the past month or so on >> serviceability-dev, and I think a CSR request is required, so this may be a >> work in progress. >> >> Notes on the patch: >> >> - The `list` command previously m

Re: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v7]

2021-10-19 Thread Chris Plummer
On Mon, 18 Oct 2021 20:02:21 GMT, Richard Reingruber wrote: >> This change fixes deadlocks described in the JBS-bug by: >> >> * Releasing `handlerLock` before waiting on `threadLock` in >> `blockOnDebuggerSuspend()` >> >> * Notifying on `threadLock` in `threadControl_reset()` >> >> Also the a

Integrated: 8275517: Off-by-one error in allocation

2021-10-19 Thread Markus Grönlund
On Tue, 19 Oct 2021 15:31:39 GMT, Markus Grönlund wrote: > Greetings (again), > > The quick fix for > [JDK-8275445](https://bugs.openjdk.java.net/browse/JDK-8275445) includes an > off-by-one error as part of the allocation. :-( > > Sorry for this inconvenience. > > Markus This pull request

Re: Integrated: 8275517: Off-by-one error in allocation

2021-10-19 Thread Thomas Schatzl
On Tue, 19 Oct 2021 15:31:39 GMT, Markus Grönlund wrote: > Greetings (again), > > The quick fix for > [JDK-8275445](https://bugs.openjdk.java.net/browse/JDK-8275445) includes an > off-by-one error as part of the allocation. :-( > > Sorry for this inconvenience. > > Markus Lgtm. Fingers cros

Integrated: 8275517: Off-by-one error in allocation

2021-10-19 Thread Markus Grönlund
Greetings (again), The quick fix for [JDK-8275445](https://bugs.openjdk.java.net/browse/JDK-8275445) includes an off-by-one error as part of the allocation. :-( Sorry for this inconvenience. Markus - Commit messages: - Off-by-one error in allocation Changes: https://git.openjdk

Re: Integrated: 8275517: Off-by-one error in allocation

2021-10-19 Thread Markus Grönlund
On Tue, 19 Oct 2021 15:34:13 GMT, Thomas Schatzl wrote: >> Greetings (again), >> >> The quick fix for >> [JDK-8275445](https://bugs.openjdk.java.net/browse/JDK-8275445) includes an >> off-by-one error as part of the allocation. :-( >> >> Sorry for this inconvenience. >> >> Markus > > Lgtm. F

Integrated: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent

2021-10-19 Thread Andrey Turbanov
On Sat, 25 Sep 2021 11:15:35 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method > directly. This pull request has now been integrated. Changeset: a579483c Author:Andrey Turbanov Committer: Albert Mingkun Yang URL: https://gi

Re: RFR: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent

2021-10-19 Thread Albert Mingkun Yang
On Sat, 25 Sep 2021 11:15:35 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method > directly. Marked as reviewed by ayang (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5697

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

2021-10-19 Thread Leo Korinth
On Thu, 7 Oct 2021 06:18:00 GMT, Kim Barrett wrote: >> Leo Korinth has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use a thread local buffer so that the compiler might reorder operator new. > > src/hotspot/share/memory/memRegion.hpp line

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

2021-10-19 Thread Leo Korinth
On Thu, 7 Oct 2021 06:21:52 GMT, Kim Barrett wrote: >> Leo Korinth has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use a thread local buffer so that the compiler might reorder operator new. > > src/hotspot/share/memory/allocation.hpp lin

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

2021-10-19 Thread Leo Korinth
On Thu, 7 Oct 2021 06:21:09 GMT, Kim Barrett wrote: >> Leo Korinth has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use a thread local buffer so that the compiler might reorder operator new. > > src/hotspot/share/memory/allocation.hpp lin

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

2021-10-19 Thread Leo Korinth
On Tue, 19 Oct 2021 13:01:10 GMT, Leo Korinth wrote: >> src/hotspot/share/memory/allocation.hpp line 398: >> >>> 396: class ResourceObj ALLOCATION_SUPER_CLASS_SPEC { >>> 397: public: >>> 398: enum allocation_type : uint8_t { STACK_OR_EMBEDDED, RESOURCE_AREA, >>> C_HEAP, ARENA }; >> >> Consi

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

2021-10-19 Thread Leo Korinth
On Thu, 7 Oct 2021 06:12:07 GMT, Kim Barrett wrote: >> Leo Korinth has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use a thread local buffer so that the compiler might reorder operator new. > > src/hotspot/share/memory/allocation.hpp lin

Integrated: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked"

2021-10-19 Thread Markus Grönlund
On Tue, 19 Oct 2021 09:39:06 GMT, Markus Grönlund wrote: > Greetings, > > This fixes the issue seen in testing when accessing an oop as part of > unloading (introduced with > [JDK-8266936](https://bugs.openjdk.java.net/browse/JDK-8266936)). > > Instead, oop accesses will be done outside of un

Re: RFR: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" [v2]

2021-10-19 Thread Markus Grönlund
On Tue, 19 Oct 2021 12:19:24 GMT, Erik Gahlin wrote: >> Markus Grönlund has updated the pull request incrementally with one >> additional commit since the last revision: >> >> header > > Marked as reviewed by egahlin (Reviewer). Thanks, @egahlin and @coleenp, for your quick reviews. I will p

Re: RFR: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" [v2]

2021-10-19 Thread Coleen Phillimore
On Tue, 19 Oct 2021 10:05:15 GMT, Markus Grönlund wrote: >> Greetings, >> >> This fixes the issue seen in testing when accessing an oop as part of >> unloading (introduced with >> [JDK-8266936](https://bugs.openjdk.java.net/browse/JDK-8266936)). >> >> Instead, oop accesses will be done outsid

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

2021-10-19 Thread Leo Korinth
On Thu, 7 Oct 2021 05:54:55 GMT, Kim Barrett wrote: >> Leo Korinth has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use a thread local buffer so that the compiler might reorder operator new. > > src/hotspot/share/asm/codeBuffer.hpp line 3

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

2021-10-19 Thread Leo Korinth
On Thu, 7 Oct 2021 05:49:24 GMT, Kim Barrett wrote: >> Leo Korinth has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use a thread local buffer so that the compiler might reorder operator new. > > src/hotspot/share/asm/codeBuffer.cpp line 1

Re: RFR: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" [v2]

2021-10-19 Thread Erik Gahlin
On Tue, 19 Oct 2021 10:05:15 GMT, Markus Grönlund wrote: >> Greetings, >> >> This fixes the issue seen in testing when accessing an oop as part of >> unloading (introduced with >> [JDK-8266936](https://bugs.openjdk.java.net/browse/JDK-8266936)). >> >> Instead, oop accesses will be done outsid

Re: RFR: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" [v2]

2021-10-19 Thread Markus Grönlund
> Greetings, > > This fixes the issue seen in testing when accessing an oop as part of > unloading (introduced with > [JDK-8266936](https://bugs.openjdk.java.net/browse/JDK-8266936)). > > Instead, oop accesses will be done outside of unloading and the result, i.e > the codesource attribute, wi