Re: RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode

It would work right now. But I don’t want us fixing it again when somebody implements effectively final optimization in Graal. igor > On Nov 28, 2018, at 10:02 PM, dean.l...@oracle.com wrote: > > I like it better. But do you really need to use JNI to reset the values? If > you had > > sta

Re: RFR: (S): JDK-8213323: sa/TestJmapCoreMetaspace.java and sa/TestJmapCore.java fail with ZGC

Thank you very much, Chris. I have modified HeapHprofBinWriter.java slightly so that the hprof file does not dumped if this is ZGC. In the test, we check for the presence of the hprof file and throw an exception if the hprof file does not exist and only if this is not ZGC. The tests are not exc

Re: RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode

I like it better.  But do you really need to use JNI to reset the values?  If you had static int POISON = 0x1234;  // not final class TaggedClass {   static int field1 = 0xC0DE01 + POISON; in HeapFilter.java, is the compiler smart enough to treat the value as constant until it changes?

Re: RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode

Alright, how about the following solution: http://cr.openjdk.java.net/~iveresov/8193577/webrev.01/ igor > On Nov 28, 2018, at 4:59 PM, Igor Veresov wrote: > > I don’t want to make it Graal specific. I think I’ll just do field > assignments in native so that it’s all invisible to the compile

Re: RFR(XXS): 8214462: Add serviceability/sa/ClhsdbInspect.java to ProblemList.txt

Looks good. Thanks! Jini. On 11/29/2018 9:13 AM, leonid.mes...@oracle.com wrote: Hi Could you please review following trivial fix which just exclude test ClhsdbInspect.java from execution on Windows where it might hang because of https://bugs.openjdk.java.net/browse/JDK-8213457. bug: https

Re: RFR(XXS): 8214462: Add serviceability/sa/ClhsdbInspect.java to ProblemList.txt

Looks fine. Please ensure it's mentioned in 8213457 that the ProblemList will need updating when it is fixed. Thanks, David On 29/11/2018 1:43 pm, leonid.mes...@oracle.com wrote: Hi Could you please review following trivial fix which just exclude test ClhsdbInspect.java from execution on W

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Roman, The SA tests which iterate over the heap (ClhsdbJhisto.java, TestHeapDumpFor*.java) fail if ZGC is passed as an option to these also (Am planning on fixing these). It might be better to avoid invoking those tests for Shenandoah now with an @requires tag. Thank you, Jini On 11/29/2

Re: JDK-8176828: jtools do not list VM process launched with the debugger option suspend=y

I've been lurking on this ... On 29/11/2018 9:41 am, gary.ad...@oracle.com wrote: On 11/28/18 4:12 PM, Chris Plummer wrote: On 11/28/18 11:52 AM, Gary Adams wrote: https://bugs.openjdk.java.net/browse/JDK-8156537   - Added a fix for module naming https://bugs.openjdk.java.net/browse/JDK-81765

RFR(XXS): 8214462: Add serviceability/sa/ClhsdbInspect.java to ProblemList.txt

Hi Could you please review following trivial fix which just exclude test ClhsdbInspect.java from execution on Windows where it might hang because of https://bugs.openjdk.java.net/browse/JDK-8213457. bug: https://bugs.openjdk.java.net/browse/JDK-8214462 diff: diff -r 1d520c376105 test/hotspo

Re: RFR (L) 8214417: Add space after/before {} in vmTestbase/nsk/jvmti/[A-I] tests

Hi Serguei, On 11/28/2018 16:44, serguei.spit...@oracle.com wrote: There are some implicit rules, like unification and consistency. We want a space or new line after '{' and before '}'. I believe this rule is about braces for code blocks (new line after "{", "}" on a separate line), but this

Re: RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode

I don’t want to make it Graal specific. I think I’ll just do field assignments in native so that it’s all invisible to the compiler. igor > On Nov 28, 2018, at 3:25 PM, serguei.spit...@oracle.com wrote: > > On 11/28/18 15:16, dean.l...@oracle.com wrote: >> It sou

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

About C2 changes. .ad files. I am thinking may be we should put new code in separate _shenandoah.ad files and merge them only if Shenandoah is included in built [1]. I don't like #ifdefs - you still generate this mach nodes even without Shenandoah. debug_final_field_at() and debug_stable_field

Re: RFR (L) 8214417: Add space after/before {} in vmTestbase/nsk/jvmti/[A-I] tests

There are some implicit rules, like unification and consistency. We want a space or new line after '{' and before '}'. Why this case needs to have an exception? Thanks, Serguei On 11/28/18 16:18, Alex Menkov wrote: I don't see such rule (I suppose https://wiki.openjdk.java.net/display/HotSpot/

Re: RFR (L) 8214417: Add space after/before {} in vmTestbase/nsk/jvmti/[A-I] tests

I don't see such rule (I suppose https://wiki.openjdk.java.net/display/HotSpot/StyleGuide is correct link?) --alex On 11/28/2018 16:05, serguei.spit...@oracle.com wrote: On 11/28/18 15:43, Alex Menkov wrote: Hi Jc, In the JDK-8212771 review thread cleanup for "{}" was requested for statemen

Re: RFR (L) 8214417: Add space after/before {} in vmTestbase/nsk/jvmti/[A-I] tests

On 11/28/18 15:43, Alex Menkov wrote: Hi Jc, In the JDK-8212771 review thread cleanup for "{}" was requested for statements like test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/MethodBind/JvmtiTest/JvmtiTest.cpp, +#define JVMTI_ERROR_CHECK(str,res) if (res != JVMTI_ERROR_NONE) { printf(str);

Re: RFR (L) 8214417: Add space after/before {} in vmTestbase/nsk/jvmti/[A-I] tests

Hi Jc, LGTM. Thanks, Serguei On 11/28/18 11:20, JC Beyler wrote: Hi all, When working on a previous clean-up (JDK-8212771), I was asked to clean-up

Re: RFR (L) 8214417: Add space after/before {} in vmTestbase/nsk/jvmti/[A-I] tests

Hi Jc, In the JDK-8212771 review thread cleanup for "{}" was requested for statements like test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/MethodBind/JvmtiTest/JvmtiTest.cpp, +#define JVMTI_ERROR_CHECK(str,res) if (res != JVMTI_ERROR_NONE) { printf(str); printf("%d\n",res); return res;} +#defi

Re: JDK-8176828: jtools do not list VM process launched with the debugger option suspend=y

On 11/28/18 4:12 PM, Chris Plummer wrote: On 11/28/18 11:52 AM, Gary Adams wrote: https://bugs.openjdk.java.net/browse/JDK-8156537   - Added a fix for module naming https://bugs.openjdk.java.net/browse/JDK-8176533   - Fixed a regression from JDK-816537 that prevented "jcmd " from sending

Re: RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode

On 11/28/18 15:16, dean.l...@oracle.com wrote: It sounds like the test could also fail with C2 if the fields are in a virtual object that was eliminated.  I'm OK with your fix, but I would feel a little better if we only relaxed the check for Graal

Re: RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode

It sounds like the test could also fail with C2 if the fields are in a virtual object that was eliminated.  I'm OK with your fix, but I would feel a little better if we only relaxed the check for Graal. I guess you'd need to use the whitebox api for that. dl On 11/28/18 2:28 PM, Igor Veresov

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Alright, we fixed: - The minor issues that Kim reported in shared-gc - A lot of fixes in shared-tests according to Leonid's review - Disabled SA heapdumping similar to ZGC as Per suggested Some notes: Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually correct. The @requires there mea

Re: RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode

Oh, I haven’t understood your idea before pressing reply. Yes, we can match the objects by matching their shape, but it’s also not an exact solution prone to erroneous matches. Especially considering the iteration API does callbacks for the fields out of order - it does primitives, strings, arra

Re: RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode

I don’t see a better way, really. If there is a less hacky way that is allowed by the iteration API, I’m definitely open to suggestions. igor > On Nov 28, 2018, at 1:27 PM, serguei.spit...@oracle.com wrote: > > Hi Igor, > > It looks like a hack but Okay with me. > > Thanks, > Serguei > >

Re: RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode

I don’t think there is a way to identify an untagged object. There is nothing that is passed in the callback to allow that. igor > On Nov 28, 2018, at 1:32 PM, dean.l...@oracle.com wrote: > > I'm guessing Graal creates Constant boxes of the individual fields and not of > the test objects? I

Re: RFR JDK-8195639: [Graal] nsk/jvmti/PopFrame/popframe009 fail with Graal in -Xcomp

On 11/28/18 13:43, dean.l...@oracle.com wrote: I guess even with -Xcomp, there are still compiles triggered by profiled code, otherwise I don't see why changing policy()->event() helps. Another problem I see with this change is that it will make the real problem harder to reproduce. True. B

Re: RFR JDK-8195639: [Graal] nsk/jvmti/PopFrame/popframe009 fail with Graal in -Xcomp

I guess even with -Xcomp, there are still compiles triggered by profiled code, otherwise I don't see why changing policy()->event() helps. Another problem I see with this change is that it will make the real problem harder to reproduce. dl On 11/28/18 12:36 PM, Alex Menkov wrote: Hi guys,

Re: RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode

I'm guessing Graal creates Constant boxes of the individual fields and not of the test objects?  If so, can't we fix the matching so that it checks that all fields of an object match?  I guess that would mean moving the "expected" and "found" counts up from fields[] to objects_info[]. dl On 1

Re: RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode

Hi Igor, It looks like a hack but Okay with me. Thanks, Serguei On 11/28/18 13:13, Igor Veresov wrote: When doing heap iteration with JVMTI the way the object identity is tracked is by tagging. This particular test checks if it can observe an untagged object. Since there is no way to truly

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Thank you for your fixes and additional testing. I'll check new version  in the round-2. Leonid On 11/28/18 10:36 AM, Roman Kennke wrote: Hi Leonid, I looked at the tests changes only. It seems that  a some tests might start failing if JDK built without Shenandoah GC. Also some test are

RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode

When doing heap iteration with JVMTI the way the object identity is tracked is by tagging. This particular test checks if it can observe an untagged object. Since there is no way to truly track the identity of an untagged object the test validates the identity by checking the value of the field

Re: JDK-8176828: jtools do not list VM process launched with the debugger option suspend=y

On 11/28/18 11:52 AM, Gary Adams wrote: https://bugs.openjdk.java.net/browse/JDK-8156537   - Added a fix for module naming https://bugs.openjdk.java.net/browse/JDK-8176533   - Fixed a regression from JDK-816537 that prevented "jcmd " from sending to https://bugs.openjdk.java.net/browse/

Re: JNI - question about jmethodid values.

Not sure if this discussion is diverging but to be clear there is no way for a JNI programmer to check whether a jmethodid is valid or not. The onus is one the programmer to ensure classes are not unloaded while there are pre-computed jmethodid's. It's a quality of implementation issue, to me,

Re: RFR JDK-8195639: [Graal] nsk/jvmti/PopFrame/popframe009 fail with Graal in -Xcomp

Hi guys, I was able to reproduce the issue only with Graal + -Xcomp and only with debug build (I tried Graal + -Xint, Graal without Xcomp/Xint, just -Xcomp (i.e. C1 is used)). --alex On 11/28/2018 01:27, serguei.spit...@oracle.com wrote: On 11/28/18 01:07, dean.l...@oracle.com wrote: OK, r

Re: RFR (S) 8212207: runtime/InternalApi/ThreadCpuTimesDeadlock.java crashes with SEGV in pthread_getcpuclockid+0x0

On Wed, Nov 28, 2018 at 8:53 PM Kim Barrett wrote: > > > On Nov 28, 2018, at 2:26 AM, David Holmes wrote: > > On 28/11/2018 4:30 pm, Thomas Stüfe wrote: > >> P.s. > >> ConcurrentGCThread::ConcurrentGCThread() : > >> _should_terminate(false), _has_terminated(false) { > >> }; > >> I was surprised

Re: RFR (S) 8212207: runtime/InternalApi/ThreadCpuTimesDeadlock.java crashes with SEGV in pthread_getcpuclockid+0x0

> On Nov 28, 2018, at 2:26 AM, David Holmes wrote: > On 28/11/2018 4:30 pm, Thomas Stüfe wrote: >> P.s. >> ConcurrentGCThread::ConcurrentGCThread() : >> _should_terminate(false), _has_terminated(false) { >> }; >> I was surprised to see no invocation to the base class ctor in the >> initializer l

Re: JDK-8176828: jtools do not list VM process launched with the debugger option suspend=y

https://bugs.openjdk.java.net/browse/JDK-8156537 - Added a fix for module naming https://bugs.openjdk.java.net/browse/JDK-8176533 - Fixed a regression from JDK-816537 that prevented "jcmd " from sending to https://bugs.openjdk.java.net/browse/JDK-8176828 - Requests that "jcmd -l" s

Re: JDK-8176828: jtools do not list VM process launched with the debugger option suspend=y

Sorry, meant to say "before JDK-8176533". Chris On 11/28/18 10:11 AM, Chris Plummer wrote: Hi Gary, This seems reasonable. I just want clarification on one thing first. Before JDK-8176828, it listed the suspend=y process, but could you do anything with it? I'm assuming no, and therefore it m

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Leonid, > I looked at the tests changes only. It seems that  a some tests might > start failing if JDK built without Shenandoah GC. Also some test are not > going to be selected as expected. > > Unfortunately logic of '@requires' and @run in jtreg tests doesn't > always work well for specific

Re: JDK-8176828: jtools do not list VM process launched with the debugger option suspend=y

Hi Gary, This seems reasonable. I just want clarification on one thing first. Before JDK-8176828, it listed the suspend=y process, but could you do anything with it? I'm assuming no, and therefore it makes sense not to list it at all. thanks, Chris On 11/28/18 8:33 AM, Gary Adams wrote: I

Re: JNI - question about jmethodid values.

On 11/28/18 11:46 AM, JC Beyler wrote: The biggest issue is that the JNI spec has no means of "gracefully" exiting when a jmethodID is NULL, take the call static methods, the spec says: "RETURNS: Returns the result of calling the static Java method. THROWS: Exceptions raised during the exec

Re: JNI - question about jmethodid values.

What I meant was that since we already pay for the memory leak, we could just change this behavior and handle NULL methodIDs gracefully. We do this already for JVMTI. Otherwise, if we do not what to do this check and consider this to be the caller's responsibility, I do not see the point of keepin

JDK-8176828: jtools do not list VM process launched with the debugger option suspend=y

I'd like to close JDK-8176828 as will not fix. https://bugs.openjdk.java.net/browse/JDK-8176828 This bug was originally thought to be associated with a regression fix in JDK-8176533, but I believe there is simply a misunderstanding of how the "suspend=y" behavior is supported for the jdwp agent

Re: JNI - question about jmethodid values.

On Wed, Nov 28, 2018 at 4:19 PM wrote: > > > > On 11/28/18 10:08 AM, Thomas Stüfe wrote: > > On Wed, Nov 28, 2018 at 4:03 PM wrote: > >> > >> > >> On 11/28/18 10:00 AM, Thomas Stüfe wrote: > >>> On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe > >>> wrote: > Hi Coleen, > > (moved to

Re: JNI - question about jmethodid values.

On 11/28/18 10:08 AM, Thomas Stüfe wrote: On Wed, Nov 28, 2018 at 4:03 PM wrote: On 11/28/18 10:00 AM, Thomas Stüfe wrote: On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe wrote: Hi Coleen, (moved to svc-dev since David did shoo us off discuss before :-) Just to be sure I understand: If

Re: JNI - question about jmethodid values.

On Wed, Nov 28, 2018 at 4:03 PM wrote: > > > > On 11/28/18 10:00 AM, Thomas Stüfe wrote: > > On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe > > wrote: > >> Hi Coleen, > >> > >> (moved to svc-dev since David did shoo us off discuss before :-) > >> > >> Just to be sure I understand: > >> > >>> If th

Re: JNI - question about jmethodid values.

On 11/28/18 10:00 AM, Thomas Stüfe wrote: On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe wrote: Hi Coleen, (moved to svc-dev since David did shoo us off discuss before :-) Just to be sure I understand: If the class is unloaded, the jmethodID is cleared. Native code should first test wheth

Re: JNI - question about jmethodid values.

On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe wrote: > > Hi Coleen, > > (moved to svc-dev since David did shoo us off discuss before :-) > > Just to be sure I understand: > > > If the class is unloaded, the jmethodID is cleared. Native code should > > first test whether it's NULL. I think that is

Re: JNI - question about jmethodid values.

Hi Coleen, (moved to svc-dev since David did shoo us off discuss before :-) Just to be sure I understand: > If the class is unloaded, the jmethodID is cleared. Native code should > first test whether it's NULL. I think that is the predictable behavior > that the spec requires. Wait, really? S

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

>> Hi Per, >> >>> Hi Roman, >>> >>> On 11/26/18 10:39 PM, Roman Kennke wrote: >>> [...]    *) shared-serviceability   - The usual code to support another GC >>> >>> Just had a quick look

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

On 11/28/18 3:00 PM, Roman Kennke wrote: Hi Per, Hi Roman, On 11/26/18 10:39 PM, Roman Kennke wrote: [...]   *) shared-serviceability - The usual code to support another GC Just had a quick look at

Re: RFR (S) 8212207: runtime/InternalApi/ThreadCpuTimesDeadlock.java crashes with SEGV in pthread_getcpuclockid+0x0

On Wed, Nov 28, 2018 at 8:59 AM David Holmes wrote: > > On 28/11/2018 5:46 pm, Thomas Stüfe wrote: > > Are you sure? > > No. I'm completely confusing myself - too many different "thread id's" :( A cheerful multitude :) What throws me off usually is not that we have two of them, but that, on Linu

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Per, > Hi Roman, > > On 11/26/18 10:39 PM, Roman Kennke wrote: > [...] >>   *) shared-serviceability >> >> >> - The usual code to support another GC > > Just had a quick look at the SA part. I was thinkin

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Roman, On 11/26/18 10:39 PM, Roman Kennke wrote: [...]  *) shared-serviceability     - The usual code to support another GC Just had a quick look at the SA part. I was thinking you'd have the same proble

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Kim, >> On Nov 27, 2018, at 4:46 AM, Roman Kennke wrote: >> >> Hi Kim, >> Sections to review (at this point) are the following: *) shared-gc - This is mostly boilerplate that is common to any GC - referenceProcessor.cpp has a little change to make one assert not

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Kim, >> On Nov 26, 2018, at 4:39 PM, Roman Kennke wrote: >> *) shared-gc >> - This is mostly boilerplate that is common to any GC >> - referenceProcessor.cpp has a little change to make one assert not fail >> (next to CMS and G1) >> - taskqueue.hpp has some small adjustments to e

Re: RFR JDK-8195639: [Graal] nsk/jvmti/PopFrame/popframe009 fail with Graal in -Xcomp

On 11/28/18 01:07, dean.l...@oracle.com wrote: OK, reconsidering solution 1, I have a couple more questions: The bug report says the problem is reproducible with -Xcomp, but I don't see the policy()->event() path taken with -Xcomp. Instead, -Xcomp uses CompilationPolicy::compile_if_required, s

Re: RFR JDK-8195639: [Graal] nsk/jvmti/PopFrame/popframe009 fail with Graal in -Xcomp

OK, reconsidering solution 1, I have a couple more questions: The bug report says the problem is reproducible with -Xcomp, but I don't see the policy()->event() path taken with -Xcomp.  Instead, -Xcomp uses CompilationPolicy::compile_if_required, so I don't see how Solution 1 fixes the problem

RE: RFR : [XS] 8214373: adjust usage of ReleaseLongArrayElements in MacosxDebuggerLocal

Hi Thomas and JC , thanks for the reviews ! Best regards, Matthias From: JC Beyler Sent: Dienstag, 27. November 2018 16:48 To: Baesken, Matthias Cc: hotspot-dev Source Developers ; serviceability-dev@openjdk.java.net Subject: Re: RFR : [XS] 8214373: adjust usage of ReleaseLongArrayElements i

Re: RFR (S) 8212207: runtime/InternalApi/ThreadCpuTimesDeadlock.java crashes with SEGV in pthread_getcpuclockid+0x0

On 28/11/2018 5:46 pm, Thomas Stüfe wrote: Are you sure? No. I'm completely confusing myself - too many different "thread id's" :( On Linux, pthread id is set in the parent thread, after pthread_create returns. Only the kernel thread id is set by the child (I find this duality confusing). thr