RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs

Hi, Please review this changset that makes jlink multi-release jar aware. issue: https://bugs.openjdk.java.net/browse/JDK-8156499 webrev: http://cr.openjdk.java.net/~sdrach/8156499/webrev.00/index.html

Re: RFR: 8161379: Force inline methods calling Reflection.getCallerClass

Thanks! Up to 12-15x on some reflection micros, but it varies wildly. This change does not improve the best case performance, but rather eliminates a cause for degradation and high run to run variance. /Claes Mandy Chung skrev: (5 augusti 2016 14:55:59 GMT-07:00) > >> On Aug 5, 2016, at 1:22

Re: RFR: 8161379: Force inline methods calling Reflection.getCallerClass

> On Aug 5, 2016, at 1:22 PM, Claes Redestad wrote: > > http://cr.openjdk.java.net/~redestad/8161379/jdk.02/ > Looks fine. How much improvement do you see from the benchmark run with this patch? Mandy

Re: RFR: 8161379: Force inline methods calling Reflection.getCallerClass

On 08/05/2016 11:22 PM, Claes Redestad wrote: > On 08/05/2016 12:56 PM, Aleksey Shipilev wrote: >> I wouldn't mind to have a comment at @ForceInline line mentioning this >> is for Reflection.getCallerClass() optimization. But, it might be >> recoverable from the source control anyway. > > Sure, ho

Re: RFR: 8161379: Force inline methods calling Reflection.getCallerClass

On 08/05/2016 12:56 PM, Aleksey Shipilev wrote: This looks good to me, Claes. Thanks! I wouldn't mind to have a comment at @ForceInline line mentioning this is for Reflection.getCallerClass() optimization. But, it might be recoverable from the source control anyway. Sure, how about: @Forc

Re: RFR: 8161379: Force inline methods calling Reflection.getCallerClass

This looks good to me, Claes. I wouldn't mind to have a comment at @ForceInline line mentioning this is for Reflection.getCallerClass() optimization. But, it might be recoverable from the source control anyway. Thanks, -Aleksey On 08/05/2016 10:37 PM, Claes Redestad wrote: > Anyone? > > On 07/1

Re: RFR: 8161379: Force inline methods calling Reflection.getCallerClass

Anyone? On 07/19/2016 08:16 AM, Claes Redestad wrote: Hi, most @CallerSensitive methodscall Reflection.getCallerClass(), which turn out to have problematic performance characteristics when it fails to inline. Making @CallerSensitive imply @ForceInline actually works rather well across benchmar

Re: RFR: 8161588: MemberName::resolveOrNull cause and hide NoSuchMethodErrors

Withdrawing this as clearing exceptions actually doesn't seem to get rid of overhead(!), making this change moot. The overhead for my use case is small but annoying. Sorry for the noise. /Claes On 07/19/2016 12:17 PM, Claes Redestad wrote: Hi, please review this bug fix to ensure MemberName::

Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

Hi Frank, Looks good overall. Thanks for adding runs with/without SM, that's a lot of tedious work! I wish there's a way to do this in a general configuration. But it's fine since it does serve the purpose. Thanks, Joe On 8/5/16, 6:26 AM, Frank Yuan wrote: Hi Joe and Daniel Please review t

Re: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration

Sent from my iPad > On Aug 4, 2016, at 11:18 PM, Alan Bateman wrote: > >> On 04/08/2016 10:33, Patrick Reinhart wrote: >> >> Hi Paul, >> >> I was quit busy lately and this comes a bit late, I guess you do not have >> less work ;-) >> >> On 15.07.2016 17:10, Paul Sandoz wrote: When I u

Re: RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

IIRC pausing the receiver was introduced to prevent an LDAP client (with limited memory) from being overwhelmed by server results and having no opportunity to transmit an abandon request. The 80% value was chosen to balance maximising queue capacity against the risk of an OOME. If that behaviour

Re: RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Hi Sean, I agree that the 80% reflects the previous coding and is ok. I don't have enough background on this code to know whether the 80% is now spurious and confusing and could be removed. Roger On 8/5/2016 11:46 AM, Seán Coffey wrote: Sorry - cc'ed the wrong Pavel earlier. Corrected. I

RFR 9: JDK-8155102: Process.toString could include pid, isAlive, exitStatus

Hi Andrey, I added a test to test/java/lang/ProcessBuilder/Basic.java. Every change must have a test. http://cr.openjdk.java.net/~rriggs/webrev-process-8155102/ I can handle the extension request. Addition review comments welcome. Roger On 8/2/2016 1:30 AM, Andrey Dyachkov wrote: Roger,

Re: RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Sorry - cc'ed the wrong Pavel earlier. Corrected. I thought the consumer/producer model was best served by delegating to the BlockingQueue. Is there a need to synchronize as a result ? The 80% logic is only implemented in the rare case where the com.sun.jndi.ldap.search.replyQueueSize ldap co

Re: RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Hi Sean, Looks like a cleaner solution to synchronize writer and readers. I don't quite understand the 80% capacity value. It is related to the obsolete highWatermark but that does not seem relevant with the update. If the caller is going to specify a replyQueueCapacity then why should it b

RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Hoping to get a review on this issue that's been sitting on my plate for a long while. Pavel drew up the bulk of the edits for this one (Thanks) The fix basically delegates polling and timeout management to the BlockingQueue.poll(timeout.. ) method. As a result it makes Connection readReply lo

Re: Review request for JDK-8163266 : Doc for ValidationEvent#getSeverity()

looks fine. Roger On 8/5/2016 6:48 AM, Abhijit Roy wrote: Hi all, Please review a fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8163266 Bug - Doc for ValidationEvent#getSeverity() should say it returns a constant from ValidationEvent instead of ValidationError Webrev - http://cr.o

RE: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

Hi Joe and Daniel Please review the update: http://cr.openjdk.java.net/~fyuan/8067170/webrev.04/ In this version, I 1. made all tests run twice, to pass in the different argument to the jtreg TestNG test, it has to run in othervm(jaxp test also run in othervm before this but it's possible to run

Review request for JDK-8163266 : Doc for ValidationEvent#getSeverity()

Hi all, Please review a fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8163266 Bug - Doc for ValidationEvent#getSeverity() should say it returns a constant from ValidationEvent instead of ValidationError Webrev - http://cr.openjdk.java.net/~ntv/ababroy/8163266/webrev.00/