Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

On 29/09/2016 08:03, Volker Simonis wrote: Sorry, but that doesn't sound like a solution to me at all. I think we should keep the OpenJDK sources self-contained. I don't want to depend on yet another non-standard, third party library which doesn't even exist now. Unless I'm completely

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Hi Hamlin, One more suggested improvement. Instead of two copy/paste copies of the launch with options code, it would cleaner to create a separate RMID.launch(String[] options) method that would be passed the extra arguments. Use it in forceLogSnapshot.java and ShutdownGracefully.java. The

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

On 2016-09-29 16:54, Alan Burlison wrote: On 29/09/2016 08:03, Volker Simonis wrote: Sorry, but that doesn't sound like a solution to me at all. I think we should keep the OpenJDK sources self-contained. I don't want to depend on yet another non-standard, third party library which doesn't

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

I have asked Hamlin to hold off on this for a day or so. I have an alternative proposal that eliminates the free port anti-pattern. -Chris. > On 29 Sep 2016, at 14:55, Roger Riggs wrote: > > Hi Hamlin, > > One more suggested improvement. Instead of two copy/paste

Re: RFR: JEP draft for Linux/s3990x port

Hi Vladimir, thanks a lot for reviewing and endorsing the JEP. I've linked all the relevant issues to the JEP (they all have a link to a webrev) and change the state to "Submitted". There's just one more small shared change we need for the port for which we haven't opened a bug now because we

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

A lot of ideas have been thrown around so solve the problem of duplicated code in this situation. And there are other cases that are nearly identical so we need a general solution. The fact is this code should be moved to a common location. Since OpenJDK depends on Posix, Windows API and a few

Re: ParallelStream Vs Stream Digest, Vol 113, Issue 94

The application makes a hit to a core object over and over again. I have to copy this object, i.e. make a clone of it using the Cloneable interface, so that the original object cannot be modified. But since the references of the old object and clone object would be intact, inside the clone method

Re: ParallelStream Vs Stream Digest, Vol 113, Issue 94

On 30/09/2016 2:24 PM, Prakhar Makhija wrote: Hi everyone, I have started using both Stream and ParallelStream, for Set List and Entry of Map. What I can't understand is why Stream is taking lesser time than ParallelStream. Shouldnt ParallelStream be giving better performance than Stream in

Re: ParallelStream Vs Stream Digest, Vol 113, Issue 94

On 30/09/2016 3:07 PM, Prakhar Makhija wrote: The application makes a hit to a core object over and over again. I have to copy this object, i.e. make a clone of it using the Cloneable interface, so that the original object cannot be modified. But since the references of the old object and clone

ParallelStream Vs Stream Digest, Vol 113, Issue 94

Hi everyone, I have started using both Stream and ParallelStream, for Set List and Entry of Map. What I can't understand is why Stream is taking lesser time than ParallelStream. Shouldnt ParallelStream be giving better performance than Stream in terms of Time Complexity? On Sep 30, 2016 12:53

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Hi Joe, Roger, Modified based on your latest comments, please check the new webrev: http://cr.openjdk.java.net/~mli/8085192/webrev.02/ At the same time, I think Chris's idea is great. Thank you -Hamlin On 2016/9/30 7:14, Joseph D. Darcy wrote: If Hamlin's approach is taken in the end, I

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

+1. Kumar On 29/09/2016 16:25, Erik Joelsson wrote: Volker's comment above was directed at the suggestion of taking the problematic AIX specific code out of the OpenJDK repositories and create a separate library with a separate lifecycle somewhere else that OpenJDK for AIX would then need

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

On Thu, Sep 29, 2016 at 5:25 PM, Erik Joelsson wrote: > > > On 2016-09-29 16:54, Alan Burlison wrote: >> >> On 29/09/2016 08:03, Volker Simonis wrote: >> >>> Sorry, but that doesn't sound like a solution to me at all. I think we >>> should keep the OpenJDK sources

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

On 29/09/2016 16:25, Erik Joelsson wrote: Volker's comment above was directed at the suggestion of taking the problematic AIX specific code out of the OpenJDK repositories and create a separate library with a separate lifecycle somewhere else that OpenJDK for AIX would then need to depend on.

Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

Hello, I want to propose adding a method to the instrumentation API to receive an instance of the current VM's instrumentation API. Currently, many applications "self-attach" to gain such access. Unfortunately, this only works on JDK-VMs but I believe that this approach will grow in popularity

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

On 09/29/2016 07:50 PM, Rafael Winterhalter wrote: > I want to propose adding a method to the instrumentation API to receive an > instance of the current VM's instrumentation API. Currently, many > applications "self-attach" to gain such access. Unfortunately, this only > works on JDK-VMs but I

Re: RFR: JEP draft for Linux/s3990x port

You need to wait when Mark (OpenJDK Lead) move it to Candidate (or other) state: http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html Vladimir On 9/29/16 9:55 AM, Volker Simonis wrote: Hi Vladimir, thanks a lot for reviewing and endorsing the JEP. I've linked all the relevant issues to the

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

On 29/09/2016 18:50, Rafael Winterhalter wrote: : Therefore I want to propose adding a static method to the Instrumentation interface: interface Instrumentation { static Instrumentation getInstance(boolean redefine, boolean retransform, boolean nativePrefix) { // security manager

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

On September 29, 2016 9:06:12 PM GMT+02:00, Alan Bateman wrote: >On 29/09/2016 18:50, Rafael Winterhalter wrote: > >> : >> >> Therefore I want to propose adding a static method to the >Instrumentation >> interface: >> >> interface Instrumentation { >>static

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

It would be perfectly fine, in my opinion, to throw an unsupported operation exception, if the feature was unsupported. The method would primarily be used by testing code and tools. In Mockito, we simply do not offer inline mocks (but subclass mocks) if the runtime attachment fails. EhCache or JOL

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

On 29 Sep 2016, at 16:25, Chris Hegarty wrote: > > I have asked Hamlin to hold off on this for a day or so. I have an > alternative proposal that eliminates the free port anti-pattern. It is possible to use the inheritedChannel mechanism to have the rmid process

Re: Review Request: JDK-8166238 Update jdeps for GNU-style long form options

On 28/09/2016 01:58, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8166238/webrev.00/index.html This patch renames the following options added in JDK 9 jdeps --gen-module-info => —generate-module-info -inverse => —-inverse -requires =>

Re: RFR: 8166842: String.hashCode() has a non-benign data race

On 29/09/16 05:31, David Holmes wrote: > > On 29/09/2016 10:49 AM, Carsten Varming wrote: >> Because String has final fields there is a freeze action at the end >> of construction so that String instances are always safely published >> even if not "safely published". >> >> >> I

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

Hello, From my point of view, now that I better understand what aix/porting actually was/is, I would say go for it. Put something together the way you would like it. I doubt there will ever be much code needed in this new entity so it can go in the top level repo without problems. There is

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

On Wed, Sep 28, 2016 at 8:54 PM, Chris Bensen wrote: > > On Sep 28, 2016, at 11:50 AM, Thomas Stüfe wrote: > > > > On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz > wrote: >> >> On Wed, Sep 28, 2016 at 9:33 AM, Volker

Re: RFR: 8166842: String.hashCode() has a non-benign data race

On 09/29/2016 02:58 AM, Vitaly Davidovich wrote: On Wednesday, September 28, 2016, Carsten Varming wrote: Dear David, See inline. On Wed, Sep 28, 2016 at 7:47 PM, David Holmes > wrote:

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Hello, Without commenting on the particulars, I'm happy to see work being done to address this issue in running the RMI tests. A fix here should greatly increase the reliability of the JDK test suite! Thanks, -Joe On 9/29/2016 12:09 PM, Chris Hegarty wrote: On 29 Sep 2016, at 16:25, Chris

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

If Hamlin's approach is taken in the end, I think having a smaller retry count (5 or 10 rather than 20) would be more appropriate to avoid making the worst-case running time longer than necessary. Cheers, -Joe On 9/29/2016 6:55 AM, Roger Riggs wrote: Hi Hamlin, One more suggested

Re: RFR: 8165944 jar utility doesn't process more than one -C argument

We discovered that the last webrev subtly changed the behavior of jar tool with respect to the JDK 8 jar tool, so that was fixed, along with some more simplification, and additional test cases were added to demonstrate consistent behavior across releases. Here is the newest webrev.

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Hi Jonathan, all, I've started to look at this changeset. I'm looking at the one Patrick Reinhart posted a couple weeks ago (! sorry): http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.01/ I looked at only a few files and I'm already starting to have questions. Not because anybody