Re: RFR: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name()

2020-12-07 Thread Ioi Lam
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

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2]

2020-12-07 Thread Chris Plummer
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 >>

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2]

2020-12-07 Thread David Holmes
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()`. >>

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2]

2020-12-07 Thread David Holmes
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: > >

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2]

2020-12-07 Thread David Holmes
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()`.

Re: RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads

2020-12-07 Thread Chris Plummer
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

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2]

2020-12-07 Thread Chris Plummer
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, >>>

Re: RFR: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name()

2020-12-07 Thread Vladimir Kozlov
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

RFR: 8253797: [cgroups v2] Account for the fact that swap accounting is disabled on some systems

2020-12-07 Thread Severin Gehwolf
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

Re: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal

2020-12-07 Thread Lois Foltan
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

Re: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal

2020-12-07 Thread Harold Seigel
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"

Re: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal

2020-12-07 Thread Roger Riggs
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"

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2]

2020-12-07 Thread Per Liden
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

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

2020-12-07 Thread David Holmes
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

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

2020-12-07 Thread David Holmes
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();

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2]

2020-12-07 Thread Per Liden
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

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException [v2]

2020-12-07 Thread Per Liden
> 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

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

2020-12-07 Thread Per Liden
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()`.

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

2020-12-07 Thread Per Liden
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

Re: RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

2020-12-07 Thread Per Liden
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()`.

RFR: 8255381: com/sun/jdi/EATests.java should not suspend graal threads

2020-12-07 Thread Richard Reingruber
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