Re: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement.

On 3/13/15, 2:36 PM, serguei.spit...@oracle.com wrote: Coleen, Thank you for review and great idea to use the method name cp index! However, this approach is going stop working if we get rid of the CP merge in the future. Yes, it will. I was just thinking about how to resolve that. We'll ha

Re: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement.

Coleen, Thank you for review and great idea to use the method name cp index! However, this approach is going stop working if we get rid of the CP merge in the future. Thanks, Serguei On 3/13/15 10:40 AM, Coleen Phillimore wrote: Serguei, This looks good. This works a lot harder to find th

Re: RFR(S): 8073794: jdk/test/com/sun/jdi/BadHandshakeTest.java should retry if tcp port is taken

Hi Katja, Thumbs up! -JB- On 13.3.2015 15:23, Yekaterina Kantserova wrote: Hi, Could I please have a review of this fix. bug: https://bugs.openjdk.java.net/browse/JDK-8073794 webrev: http://cr.openjdk.java.net/~ykantser/8073794/webrev.00/ Thanks, Katja

Re: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement.

Serguei, This looks good. This works a lot harder to find the original method than the code used to. Thanks, Coleen On 3/13/15, 1:27 AM, serguei.spit...@oracle.com wrote: Please, review the jdk 9 fix for: https://bugs.openjdk.java.net/browse/JDK-8067662 Open hotspot webrev: http://cr.o

RFR(S): 8073794: jdk/test/com/sun/jdi/BadHandshakeTest.java should retry if tcp port is taken

Hi, Could I please have a review of this fix. bug: https://bugs.openjdk.java.net/browse/JDK-8073794 webrev: http://cr.openjdk.java.net/~ykantser/8073794/webrev.00/ Thanks, Katja

RE: RFR (S) : 8073607 : add trace events for inlining

HI Igor, Looks good! Thanks Markus -Original Message- From: Igor Ignatyev Sent: den 10 mars 2015 17:41 To: Markus Gronlund; erik.gah...@oracle.com >> Erik Gahlin Cc: hotspot-compiler-...@openjdk.java.net compiler; serviceability-dev@openjdk.java.net Subject: Re: RFR (S) : 8073607 : add

Re: inlining AllocateHeap()

Hi, That would require more significant changes to NMT I think I think two changes: 1. Remove AllocateHeap(size_t, MEMFLAGS, AllocFailType) . 2. Add "const NativeCallStack&" to argument of ReallocateHeap() . I think that caller of AllocateHeap() and ReallocateHeap() should give PC to them

Re: inlining AllocateHeap()

On 13/03/2015 6:13 PM, Thomas Stüfe wrote: Hi Yasumasa, David, Maybe it would make sense to make the number-of-frames-to-skip-parameter configurable? That would require more significant changes to NMT I think - plus I don't see how it will help if you have to know a-priori whether inlining h

Re: inlining AllocateHeap()

Hi Yasumasa, David, Maybe it would make sense to make the number-of-frames-to-skip-parameter configurable? Because the direct caller of AllocateHeap or os::malloc may also not be interesting but still a generic wrapper. So, the user doing the allocation trace could finetune this parameter to fit

Re: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure

Martin, Jaroslav: Thank you! > On 12 mar 2015, at 18:47, Martin Buchholz wrote: > > Looks good to me! > > > On Thu, Mar 12, 2015 at 12:18 AM, Staffan Larsen > wrote: > >> On 11 mar 2015, at 20:37, Martin Buchholz > > wrote: >> >>