Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

Hi Yasumasa, On 18/10/2017 4:34 PM, Yasumasa Suenaga wrote: Hi David, I don't think we need the extra fields, just ensure the existing ones can't be accessed (other than by the tools) after destroy is called. I've added PerfMemory::is_useable() to check whether we can access to PerfMemory. I

Re: RFR: 8189440: Event tracing macros for allocation and weak oops processing

I'm adding hotspot-gc-dev since GC code is touched and not all GC developers are on serviceability-dev (probably just me). Thanks, Erik On 10/18/2017 04:34 AM, Erik Gahlin wrote: Hi, Could I have a review of a change that adds two macros to be used with event-based JVM tracing. Bug: https:

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

Hi David, Thank you for your comment. I uploaded new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.07/ Serguei, please comment about this :-) Yasumasa 2017-10-18 16:09 GMT+09:00 David Holmes : > Hi Yasumasa, > > On 18/10/2017 4:34 PM, Yasumasa Suenaga wrote: >> >> Hi Dav

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

Hi Yasumasa, Sorry for a quite late participation. I looked at the previous webrevs and think that this one is much better. Some concern is if we need any kind of synchronization here, e.g. CAS. But it depends on the PerfMemory cla

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

Hi Serguei, Should we use OrderAccess::load_acquire() to check _initialized and _destroyed? IMHO it do not need because initialize / destroy of PerfMemory seem not to be on multi-threaded. Thanks, Yasumasa. 2017/10/18 午後6:25 "serguei.spit...@oracle.com" : > Hi Yasumasa, > > Sorry for a quit

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

Hi Serguei On 18/10/2017 7:25 PM, serguei.spit...@oracle.com wrote: Hi Yasumasa, Sorry for a quite late participation. I looked at the previous webrevs and think that this one is much better. Some concern is if we need any kind of synchronization here, e.g. CAS. But it depends on the PerfMemo

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

On 18/10/2017 7:43 PM, Yasumasa Suenaga wrote: Hi Serguei, Should we use OrderAccess::load_acquire() to check _initialized and _destroyed? Yes for _initialized. IMHO it do not need because initialize / destroy of PerfMemory seem not to be on multi-threaded. Initialization would normally b

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

Hi David, Thank you for jumping to this review and helping Yasumasa to sort it out! I've just discovered that this issue was already on the table for several months without a significant progress. On 10/18/17 02:48, David Holmes wrote:

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

On 18/10/2017 8:26 PM, serguei.spit...@oracle.com wrote: Hi David, Thank you for jumping to this review and helping Yasumasa to sort it out! I've just discovered that this issue was already on the table for several months without a significant progress. On 10/18/17 02:48, David Holmes wrote:

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

Just to clarify ... On 18/10/2017 10:28 PM, David Holmes wrote: On 18/10/2017 8:26 PM, serguei.spit...@oracle.com wrote: Hi David, Thank you for jumping to this review and helping Yasumasa to sort it out! I've just discovered that this issue was already on the table for several months without

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

Hi David, Serguei, because as soon as we have checked is_usable() and abort happening in another thread may have changed that by calling destroy. This code is basically broken if we hit an abort path instead of a normal VM shutdown. Can we use MutexLocker for initialize() and destroy() ?

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

On 10/18/17 05:28, David Holmes wrote: On 18/10/2017 8:26 PM, serguei.spit...@oracle.com wrote: Hi David, Thank you for jumping to this review and helping Yasumasa to sort it out! I've just discovered that this issue was already on the table for several months without a significant progress.

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

On 10/18/17 05:34, David Holmes wrote: Just to clarify ... On 18/10/2017 10:28 PM, David Holmes wrote: On 18/10/2017 8:26 PM, serguei.spit...@oracle.com wrote: Hi David, Thank you for jumping to this review and helping Yasumasa to sort it out! I've just discovered that this issue was already

RFR: 8189373: jmap -heap exited with error code

My recent CMSHeap extraction has broken the JVM servicability agent. It looks like I actually need a little bit more boilerplate to make it happy: http://cr.openjdk.java.net/~rkennke/8189373/webrev.00/ It does fix the test that's ment

Re: RFR (XS): 8175510 Null pointer dereference in getModuleObject of JPLISAgent.c:790

Is anyone interested to review this simple fix? Otherwise, I'd suggest to push it with one review from David under trivial fix rule. Thanks, Serguei On 10/12/17 18:01, David Holmes wrote: Hi Serguei, Seems quite reasonable. Reviewed. Thanks, David On 13/10/2017 8:21 AM, serguei.spit...@o

Re: RFR: 8189440: Event tracing macros for allocation and weak oops processing

Hi David, Hi Erik, On 18/10/2017 12:34 PM, Erik Gahlin wrote: Hi, Could I have a review of a change that adds two macros to be used with event-based JVM tracing. Bug: https://bugs.openjdk.java.net/browse/JDK-8189440 Webrev: http://cr.openjdk.java.net/~egahlin/8189440_0 Reviewed - though

Re: RFR (XS): 8175510 Null pointer dereference in getModuleObject of JPLISAgent.c:790

I actually took a look at it the other day but never responded. I was wondering if we really want to print a message here. I didn't see any other cases of doing this. Also, if we are out of native memory, do we really want to continue? Chris On 10/18/17 12:15 PM, serguei.spit...@oracle.com wr

Re: RFR (XS): 8175510 Null pointer dereference in getModuleObject of JPLISAgent.c:790

Hi Chris, On 10/18/17 12:34, Chris Plummer wrote: I actually took a look at it the other day but never responded. Thank you for reviewing it! I was wondering if we really want to print a message here.I didn't see any other cases of doing this. I see no harm to print it in this particular

Re: RFR(S): 8189425: Minor updates in support of closed changes

Hi David, Hi Erik, On 18/10/2017 12:23 PM, Erik Gahlin wrote: Hi, Could I have a review of this change that will adjust an assertion and Can you explain the adjustment please. We have closed code that modifies the mark word and then changes it back during a safepoint. When the mark word i

Re: RFR (XS): 8175510 Null pointer dereference in getModuleObject of JPLISAgent.c:790

On 10/18/17 13:02, serguei.spit...@oracle.com wrote: Hi Chris, On 10/18/17 12:34, Chris Plummer wrote: I actually took a look at it the other day but never responded. Thank you for reviewing it! I was wondering if we really want to print a message here.I didn't see any other cases of doing

Re: RFR (XS): 8175510 Null pointer dereference in getModuleObject of JPLISAgent.c:790

On 10/18/17 1:10 PM, serguei.spit...@oracle.com wrote: On 10/18/17 13:02, serguei.spit...@oracle.com wrote: Hi Chris, On 10/18/17 12:34, Chris Plummer wrote: I actually took a look at it the other day but never responded. Thank you for reviewing it! I was wondering if we really want to pri

Re: RFR (XS): 8175510 Null pointer dereference in getModuleObject of JPLISAgent.c:790

On 10/18/17 13:33, Chris Plummer wrote: On 10/18/17 1:10 PM, serguei.spit...@oracle.com wrote: On 10/18/17 13:02, serguei.spit...@oracle.com wrote: Hi Chris, On 10/18/17 12:34, Chris Plummer wrote: I actually took a look at it the other day but never responded. Thank you for reviewing it!

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

On 10/18/17 06:51, Yasumasa Suenaga wrote: Hi David, Serguei, because as soon as we have checked is_usable() and abort happening in another thread may have changed that by calling destroy. This code is basically broken if we hit an abort path instead of a normal VM shutdown. Can we use Mut

Re: RFR(S): 8189425: Minor updates in support of closed changes

Hi Erik, On 19/10/2017 6:04 AM, Erik Gahlin wrote: Hi David, Hi Erik, On 18/10/2017 12:23 PM, Erik Gahlin wrote: Hi, Could I have a review of this change that will adjust an assertion and Can you explain the adjustment please. We have closed code that modifies the mark word and then chan

Re: RFR: 8189440: Event tracing macros for allocation and weak oops processing

On 19/10/2017 5:33 AM, Erik Gahlin wrote: Hi David, Hi Erik, On 18/10/2017 12:34 PM, Erik Gahlin wrote: Hi, Could I have a review of a change that adds two macros to be used with event-based JVM tracing. Bug: https://bugs.openjdk.java.net/browse/JDK-8189440 Webrev: http://cr.openjdk.java

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

Hi Serguei, Would the below work? : 578 static_field(PerfMemory, _initialized, volatile jint) \ It'd be similar to this non-static case: 362 nonstatic_field(ConstantPoolCacheEntry, _f1, volatile Metadata*)

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

Sorry, I have mistake. But I cannot compile yet: diff -r 3e7702cd3f19 src/hotspot/share/runtime/vmStructs.cpp --- a/src/hotspot/share/runtime/vmStructs.cpp Thu Sep 07 15:40:20 2017 +0200 +++ b/src/hotspot/share/runtime/vmStructs.cpp Thu Oct 19 12:21:11 2017 +0900 @@ -578,7 +578,7 @@ sta