Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3]

2020-10-22 Thread Chris Plummer
On Thu, 22 Oct 2020 20:35:29 GMT, Richard Reingruber wrote: >> The following test cases try to provoke VMOutOfMemoryException during object >> reallocation: >> >> EAPopFrameNotInlinedReallocFailure >> EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure >> EAForceEarlyReturnOfInlinedMethod

Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown

2020-10-22 Thread Richard Reingruber
On Thu, 22 Oct 2020 14:29:28 GMT, Chris Plummer wrote: >> You mentioned the possibility that the OOME is not thrown because it is >> another thread that consumes all memory than the one calling >> forceEarlyReturn() which is supposed to fail with OOME. TLAB could be an >> issue then. In genera

Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3]

2020-10-22 Thread Richard Reingruber
> The following test cases try to provoke VMOutOfMemoryException during object > reallocation: > > EAPopFrameNotInlinedReallocFailure > EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure > EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure > > This is not 100% reliab

Integrated: JDK-8255262: Remove use of legacy custom @spec tag

2020-10-22 Thread Jonathan Gibbons
On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. This pull request has now been integrated. Changeset: 0aa3c925 Author:Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/0aa3c925 Stats:

Re: RFR: JDK-8255262: Remove use of legacy custom @spec tag

2020-10-22 Thread Mandy Chung
On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Marked as reviewed by mchung (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/814

Re: RFR: JDK-8255262: Remove use of legacy custom @spec tag

2020-10-22 Thread Joe Darcy
On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/814

Re: RFR: JDK-8255262: Remove use of legacy custom @spec tag

2020-10-22 Thread Mark Reinhold
On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. As the creator of these tags many moons ago, I approve this change. - Marked as reviewed by mr (Lead). PR: https://git.openjdk.java.net/jdk/pull/81

Re: RFR: JDK-8255262: Remove use of legacy custom @spec tag

2020-10-22 Thread Alan Bateman
On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/814

Re: RFR: JDK-8255262: Remove use of legacy custom @spec tag

2020-10-22 Thread Iris Clark
On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Nice clean-up. - Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/814

Re: RFR: JDK-8255262: Remove use of legacy custom @spec tag

2020-10-22 Thread Lance Andersen
On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. looks fine - Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/814

RFR: JDK-8255262: Remove use of legacy custom @spec tag

2020-10-22 Thread Jonathan Gibbons
The change is (just) to remove legacy usages of a JDK-private custom tag. - Commit messages: - JDK-8255262: Remove use of legacy custom @spec tag Changes: https://git.openjdk.java.net/jdk/pull/814/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=814&range=00 Issue: htt

Re: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2]

2020-10-22 Thread Chris Plummer
On Thu, 22 Oct 2020 08:48:20 GMT, Serguei Spitsyn wrote: >> File test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001.java has >> this change: >> >> for (int i = 0; i < threads.length; i++) { >> reply = jdb.receiveReplyForWithMessageWait(JdbCommand.kill + >> threads

Integrated: 8223312: Utilize handshakes instead of is_thread_fully_suspended

2020-10-22 Thread Robbin Ehn
On Mon, 19 Oct 2020 09:59:34 GMT, Robbin Ehn wrote: > The main point of this change-set is to make it easier to implement S/R on > top of handshakes. > Which is a prerequisite for removing _suspend_flag (which duplicates the > handshake functionality). > But we also remove some complicated S/R

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Robbin Ehn
On Thu, 22 Oct 2020 10:44:21 GMT, Robbin Ehn wrote: >> Looks good. Awesome fix IMO. > > Passes my local testing: open/test/jdk/com/sun/jdi/EATests.java, nsk_jvmti, > nsk_jdi, jdk_jdi, jck:vm. > Still running t1-t5 in test system. > > I will be integrating later today, so the ZGC/EscapeBarrier i

Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown

2020-10-22 Thread Chris Plummer
On Thu, 22 Oct 2020 13:07:32 GMT, Richard Reingruber wrote: > But honestly I don't think it is worth it and I cannot even test if it fixes > the issues. I'd prefer to skip the 3 test cases if running with ZGC. Please > let me know what you prefer. That's one option if this only happens with ZG

Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown

2020-10-22 Thread Richard Reingruber
On Thu, 22 Oct 2020 07:57:32 GMT, Richard Reingruber wrote: >>> The new LinkedListOfLongArrays is created by renaming LinkedList to >>> LinkedListOfLongArrays. The new LinkedList is a list node without payload, >>> so it >>> is smaller than a LinkedListOfLongArrays node. I try to fill the last f

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Robbin Ehn
On Thu, 22 Oct 2020 10:04:48 GMT, Erik Österlund wrote: >> Robbin Ehn has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains seven commits: >> >> - Fixed merge miss >> - Merge branch 'master' into >> 8223312-Utilize-handshakes-instead

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Robbin Ehn
On Thu, 22 Oct 2020 08:50:54 GMT, Richard Reingruber wrote: >> Depth 1 means top frame and its caller. In >> UpdateForPopTopFrameClosure::doit() line 1606(?) the 2 top frames are >> deoptimized. Reallocating objects while a frame pop request is processed >> does not work if reallocation fails

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Robbin Ehn
On Thu, 22 Oct 2020 10:04:01 GMT, Erik Österlund wrote: >> @robehn you haven't messed up. Hope I havn't either. I've tested >> >> == >> Test summary >> == >>TEST TOTAL PASS FAIL ERROR >>

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v4]

2020-10-22 Thread Robbin Ehn
> The main point of this change-set is to make it easier to implement S/R on > top of handshakes. > Which is a prerequisite for removing _suspend_flag (which duplicates the > handshake functionality). > But we also remove some complicated S/R methods. > > We basically just put in everything in t

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Erik Österlund
On Thu, 22 Oct 2020 08:42:40 GMT, Richard Reingruber wrote: >> Stack frames are counted beginning at 0. The top frame has depth 0. So >> object deoptimization happens in the top frame. >> >> Still the used method is not optimal because it assumes that objects of >> frames within the given dept

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Erik Österlund
On Wed, 21 Oct 2020 08:40:47 GMT, Robbin Ehn wrote: >> The main point of this change-set is to make it easier to implement S/R on >> top of handshakes. >> Which is a prerequisite for removing _suspend_flag (which duplicates the >> handshake functionality). >> But we also remove some complicated

Re: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v4]

2020-10-22 Thread Stefan Johansson
On Mon, 19 Oct 2020 13:09:34 GMT, Lin Zang wrote: >> - Parallel heap iteration support for PSS >> - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 > > Lin Zang has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show diffe

Re: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v4]

2020-10-22 Thread Stefan Johansson
On Wed, 21 Oct 2020 19:49:03 GMT, Stefan Johansson wrote: >> Lin Zang 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. > > src/hotspot/share/gc/parallel/parallel

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Richard Reingruber
On Thu, 22 Oct 2020 08:23:38 GMT, Richard Reingruber wrote: >> @reinrich did I mess something up when merging this in? > > Depth 1 means top frame and its caller. In > UpdateForPopTopFrameClosure::doit() line 1606(?) the 2 top frames are > deoptimized. Reallocating objects while a frame pop req

Re: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2]

2020-10-22 Thread Serguei Spitsyn
On Thu, 22 Oct 2020 08:03:15 GMT, Serguei Spitsyn wrote: >> due to the same reasons in the case w/ `fields001`, these lines have 3 unit >> indentation, 1st for `hc001` class, 2nd for `testInvalidCommands` method, >> 3rd for `invClassNames` array initialization, so they have 3x4 = 12 spaces. > >

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Richard Reingruber
On Thu, 22 Oct 2020 08:14:47 GMT, Richard Reingruber wrote: >> @reinrich did I mess something up when merging this in? > > Stack frames are counted beginning at 0. The top frame has depth 0. So object > deoptimization happens in the top frame. > > Still the used method is not optimal because it

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Richard Reingruber
On Thu, 22 Oct 2020 08:04:48 GMT, Robbin Ehn wrote: >> src/hotspot/share/prims/jvmtiEnv.cpp line 1663: >> >>> 1661: return JVMTI_ERROR_OUT_OF_MEMORY; >>> 1662: } >>> 1663: if (!eb.deoptimize_objects(1)) { >> >> Oh and why is the depth 1 here, when two frames are deoptimized? Maybe

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Richard Reingruber
On Thu, 22 Oct 2020 08:04:44 GMT, Robbin Ehn wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1390: >> >>> 1388: return JVMTI_ERROR_OUT_OF_MEMORY; >>> 1389: } >>> 1390: if (!eb.deoptimize_objects(0)) { >> >> Why is the depth 0 here? That makes no sense to me. My understandi

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Robbin Ehn
On Wed, 21 Oct 2020 14:20:21 GMT, Richard Reingruber wrote: >> src/hotspot/share/runtime/deoptimization.cpp line 1771: >> >>> 1769: Deoptimization::deoptimize_frame_internal(thread, id, reason); >>> 1770: } else { >>> 1771: VM_DeoptimizeFrame deopt(thread, id, reason); >> >> I guess V

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Robbin Ehn
On Wed, 21 Oct 2020 22:57:59 GMT, David Holmes wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1661: >> >>> 1659: assert(vf->frame_pointer() != NULL, "frame pointer mustn't be >>> NULL"); >>> 1660: if (java_thread->is_exiting() || java_thread->threadObj() == NULL) { >>> 1661: re

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Robbin Ehn
On Wed, 21 Oct 2020 20:31:27 GMT, Erik Österlund wrote: >> Robbin Ehn has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains seven commits: >> >> - Fixed merge miss >> - Merge branch 'master' into >> 8223312-Utilize-handshakes-instead

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Robbin Ehn
On Wed, 21 Oct 2020 16:54:48 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains seven commits: >> >> - Fixed merge miss >> - Merge branch 'master' into >> 8223312-Utilize-handshakes-i

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Robbin Ehn
On Wed, 21 Oct 2020 16:47:39 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/prims/jvmtiEnv.cpp line 1808: >> >>> 1806: } >>> 1807: if (java_lang_Class::is_primitive(k_mirror)) { >>> 1808: return JVMTI_ERROR_NONE; >> >> The call of JvmtiSuspendControl::print() seems to be el

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Robbin Ehn
On Thu, 22 Oct 2020 06:50:37 GMT, Richard Reingruber wrote: >> Agreed. @sspitsyn - This makes me wonder if the lack of >> synchronization is the cause of some instability in the >> JVM/TI ForceEarlyReturn() testing. >> >> Update: The old code only made the updates if the thread was fully >> susp

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Robbin Ehn
On Wed, 21 Oct 2020 14:02:59 GMT, Richard Reingruber wrote: >> Robbin Ehn has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains seven commits: >> >> - Fixed merge miss >> - Merge branch 'master' into >> 8223312-Utilize-handshakes-ins

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Robbin Ehn
On Wed, 21 Oct 2020 22:57:26 GMT, David Holmes wrote: >> Especially if an assert() is added above on L1543. > > Agreed - this code has become confused about what thread variables are > present and their relationship. Fixed and moved assert. - PR: https://git.openjdk.java.net/jdk/p

Re: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2]

2020-10-22 Thread Serguei Spitsyn
On Mon, 19 Oct 2020 20:57:03 GMT, Igor Ignatyev wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jdb/hidden_class/hc001/hc001.java line 323: >> >>> 321: "xx.yyy/0x111/0x222", >>> 322: "xx./0x111.0x222", >>> 323: "xx.yyy.zzz/" >> >> Why are these indent

Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown

2020-10-22 Thread Richard Reingruber
On Thu, 22 Oct 2020 05:06:43 GMT, Chris Plummer wrote: > Earlier you said: > > > Note also that the OOME is successfully generated during object > > reallocation a couple of times before (search "run args" in attachments > > to the JBS issue). > > So I suppose in that case it's ok if this one t

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Erik Österlund
On Wed, 21 Oct 2020 08:40:47 GMT, Robbin Ehn wrote: >> The main point of this change-set is to make it easier to implement S/R on >> top of handshakes. >> Which is a prerequisite for removing _suspend_flag (which duplicates the >> handshake functionality). >> But we also remove some complicated

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Erik Österlund
On Wed, 21 Oct 2020 08:40:47 GMT, Robbin Ehn wrote: >> The main point of this change-set is to make it easier to implement S/R on >> top of handshakes. >> Which is a prerequisite for removing _suspend_flag (which duplicates the >> handshake functionality). >> But we also remove some complicated

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Richard Reingruber
On Wed, 21 Oct 2020 17:03:45 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1454: >> >>> 1452: _state->set_earlyret_pending(); >>> 1453: _state->set_earlyret_oop(ret_ob_h()); >>> 1454: _state->set_earlyret_value(_value, _tos); >> >> Good that these updat

Re: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

2020-10-22 Thread Richard Reingruber
On Wed, 21 Oct 2020 16:45:53 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains seven commits: >> >> - Fixed merge miss >> - Merge branch 'master' into >> 8223312-Utilize-handshakes-i

Re: RFR: 8254723: add diagnostic command to write Linux perf map file [v2]

2020-10-22 Thread Nick Gasson
On Thu, 22 Oct 2020 05:00:10 GMT, Thomas Stuefe wrote: > > 1. Like Alexey, I would really wish for an print-at-exit switch. The > common naming seems to be xxxAtExit (so not, OnExit). "PrintXxx" seems to be > printing stuff out to tty, "DumpXxxx" for writing separate files (e.g. CDS > map

Re: RFR: 8254723: add diagnostic command to write Linux perf map file [v2]

2020-10-22 Thread Nick Gasson
On Thu, 22 Oct 2020 04:57:18 GMT, Thomas Stuefe wrote: >> Nick Gasson has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update for review comments > > src/hotspot/share/code/codeCache.hpp line 194: > >> 192: static void print_summary(ou

Re: RFR: 8254723: add diagnostic command to write Linux perf map file [v2]

2020-10-22 Thread Nick Gasson
On Wed, 21 Oct 2020 17:57:46 GMT, Chris Plummer wrote: >> I'm not sure, I didn't want to add too much `#ifdef` mess. The code will >> compile on other platforms, it just won't be called. Better to add `#ifdef`s >> around all of it? > > Any reason not to have this dcmd supported on all platforms