Re: RFR (XS) 8215495: Always set isCopy

2018-12-17 Thread David Holmes
LGTM. Thanks, David On 18/12/2018 8:53 am, JC Beyler wrote: Sounds good to me: For the odd corner case: Webrev: http://cr.openjdk.java.net/~jcbeyler/8215495/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215495 Thanks! Jc

Re: RFR: [XS] 8215411: some GetByteArrayElements calls miss corresponding Release

2018-12-17 Thread David Holmes
Correction ... On 18/12/2018 8:25 am, David Holmes wrote: Hi Matthias, On 17/12/2018 6:59 pm, Baesken, Matthias wrote: Hello, please review the following change. I noticed that we miss at some places (for example in case of early returns) where GetByteArrayElements is used,  the corresponding

Re: RFR: JDK-8051349: nsk/jvmti/scenarios/sampling/SP06/sp06t003 fails in nightly

2018-12-17 Thread Chris Plummer
On 12/17/18 2:30 PM, David Holmes wrote: On 18/12/2018 8:22 am, Chris Plummer wrote: I think you need to set interruptReady inside the synchronized block. Otherwise checkReady() can still get to the interrupt() call before testedMethod() gets to the wait(). That is not an issue. You can inter

Re: RFR (XS) 8215495: Always set isCopy

2018-12-17 Thread JC Beyler
Sounds good to me: For the odd corner case: Webrev: http://cr.openjdk.java.net/~jcbeyler/8215495/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215495 Thanks! Jc On Mon, Dec 17, 2018 at 2:39 PM David Holmes wrote: > Hi Jc, > > On 18/12/2018 8:12 am, JC Beyler wrote: > > Hi David, >

Re: RFR (XS) 8215495: Always set isCopy

2018-12-17 Thread David Holmes
Hi Jc, On 18/12/2018 8:12 am, JC Beyler wrote: Hi David, I understand the rationale behind the "If the method does return NULL, then isCopy's value is undefined". But what about the DEFINE_GETSCALARARRAYELEMENTS case? It does this:   if (len == 0) { \     /* Empty array: legal but useless

Re: RFR: JDK-8051349: nsk/jvmti/scenarios/sampling/SP06/sp06t003 fails in nightly

2018-12-17 Thread David Holmes
On 18/12/2018 8:22 am, Chris Plummer wrote: I think you need to set interruptReady inside the synchronized block. Otherwise checkReady() can still get to the interrupt() call before testedMethod() gets to the wait(). That is not an issue. You can interrupt at any time independent of owning th

Re: RFR: [XS] 8215411: some GetByteArrayElements calls miss corresponding Release

2018-12-17 Thread David Holmes
Hi Matthias, On 17/12/2018 6:59 pm, Baesken, Matthias wrote: Hello, please review the following change. I noticed that we miss at some places (for example in case of early returns) where GetByteArrayElements is used, the corresponding ReleaseByteArrayElements call. In VirtualMachineImpl.c I

Re: RFR: JDK-8051349: nsk/jvmti/scenarios/sampling/SP06/sp06t003 fails in nightly

2018-12-17 Thread Chris Plummer
I think you need to set interruptReady inside the synchronized block. Otherwise checkReady() can still get to the interrupt() call before testedMethod() gets to the wait(). Chris On 12/15/18 12:24 PM, gary.ad...@oracle.com wrote:

Re: RFR (XS) 8215495: Always set isCopy

2018-12-17 Thread JC Beyler
Hi David, I understand the rationale behind the "If the method does return NULL, then isCopy's value is undefined". But what about the DEFINE_GETSCALARARRAYELEMENTS case? It does this: if (len == 0) { \ /* Empty array: legal but useless, can't return NULL. \ * Return a pointer to somet

Re: RFR (XS) 8215495: Always set isCopy

2018-12-17 Thread David Holmes
Hi Jc, On 18/12/2018 3:42 am, JC Beyler wrote: Hi all, Could I get a review for this webrev: Webrev: http://cr.openjdk.java.net/~jcbeyler/8215495/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215495 isCopy only has to be set if the method executes successfully "If isCopy is not

Re: RFR (XS) 8215495: Always set isCopy

2018-12-17 Thread Daniel D. Daugherty
Adding hotspot-runtime-dev@... since this is JNI. Dan On 12/17/18 12:42 PM, JC Beyler wrote: Hi all, Could I get a review for this webrev: Webrev: http://cr.openjdk.java.net/~jcbeyler/8215495/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215495 Thanks, Jc

RFR: [XS] 8215411: some GetByteArrayElements calls miss corresponding Release

2018-12-17 Thread Baesken, Matthias
Hello, please review the following change. I noticed that we miss at some places (for example in case of early returns) where GetByteArrayElements is used, the corresponding ReleaseByteArrayElements call. In VirtualMachineImpl.c I also removed a check for isCopy (is the returned byte array a