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 AM, <core-libs-dev-requ...@openjdk.java.net> wrote: > Send core-libs-dev mailing list submissions to > core-libs-dev@openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > or, via email, send a message with subject or body 'help' to > core-libs-dev-requ...@openjdk.java.net > > You can reach the person managing the list at > core-libs-dev-ow...@openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of core-libs-dev digest..." > > > Today's Topics: > > 1. Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > (Kumar Srinivasan) > 2. Proposal to introduce method "Instrumentation.getInstance()" > to instrument the current VM (Rafael Winterhalter) > 3. Re: RFR: JEP draft for Linux/s3990x port (Vladimir Kozlov) > 4. Re: Proposal to introduce method > "Instrumentation.getInstance()" to instrument the current VM > (Aleksey Shipilev) > 5. Re: Proposal to introduce method > "Instrumentation.getInstance()" to instrument the current VM > (Alan Bateman) > 6. Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable > tests fail intermittently due to "Port already in use" (Chris > Hegarty) > 7. Re: Proposal to introduce method > "Instrumentation.getInstance()" to instrument the current VM > (Remi Forax) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 29 Sep 2016 10:48:59 -0700 > From: Kumar Srinivasan <kumar.x.sriniva...@oracle.com> > To: Alan Burlison <alan.burli...@oracle.com>, Volker Simonis > <volker.simo...@gmail.com> > Cc: "Lindenmaier, Goetz" <goetz.lindenma...@sap.com>, build-dev > <build-...@openjdk.java.net>, "ppc-aix-port-...@openjdk.java.net > " > <ppc-aix-port-...@openjdk.java.net>, Chris Bensen > <chris.ben...@oracle.com>, core-libs-dev > <core-libs-dev@openjdk.java.net> > Subject: Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > Message-ID: <57ed540b.9010...@oracle.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > +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 to depend on. Volker was instead proposing what > >> you describe. > > > > Ah right, in which case we are in violent agreement ;-) > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 29 Sep 2016 19:50:18 +0200 > From: Rafael Winterhalter <rafael....@gmail.com> > To: core-libs-dev@openjdk.java.net > Subject: Proposal to introduce method "Instrumentation.getInstance()" > to instrument the current VM > Message-ID: > <CA+DM0An3HSfHBh66zbbJ2dMuL1kd2A5RBqOdZoRLnJ4ijnqWxg@mail.gmail. > com> > Content-Type: text/plain; charset=UTF-8 > > 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 > with Java 9 where the Attach API is also part of any regular VM. > > Currently, such self-attachment is a rather flaky procedure: > > 1. Locate the "tools.jar" relatively to the Java Home. > 2. Create a new URLClassLoader for this jar. > 3. Locate the VirtualMachine type. > 4. Parse the process Id from the JMX ManagementBean. > 5. Load an agent that stores the instrumentation instance in a public > field. > 6. Locate this type from the class loader and read the field to receive the > instance. > > I maintain a library offering an API for such self-attach and we can do > some amazing things with it. For example, the Mockito library (ca. 400k > downloads/month) now allows for mocking of final methods and types by > inlining the mocking logic into a class what avoids class creation to > create mocks by a subclass with virtual method overrides. Or cache > libraries can call the objectSize method to limit memory usage by a given > number in byte. > > Due to the need of publicly exposing the instrumentation API in a public > field when using the above approach, this is however also a security risk > and the procedure is also less stable as it should be as it needs I/O. In > Java 9, this improves as there is an API for reading the current process id > and for accessing the classes of tools.jar but the situation is still far > from ideal. Within any library that uses for example EhCache, the instance > can be stolen by any application on the class path by simple (public) > reflection what then allows instrumenting the security manager to gain all > privileges. > > 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 check > return getInstance0(redefine, retransform, nativePrefix); > } > } > > This would increase security as the instance is only available aftrer a > check and does not need to be exposed. Also, it would speed up the > attachment process and avoid the I/O involved. Finally, it would make > convenience APIs like the one I implemented unneccessary. > > What do you think of this? > > Thank you for considering my proposal. > Best regards, Rafael > > > ------------------------------ > > Message: 3 > Date: Thu, 29 Sep 2016 11:25:29 -0700 > From: Vladimir Kozlov <vladimir.koz...@oracle.com> > To: Volker Simonis <volker.simo...@gmail.com> > Cc: s390x-port-...@openjdk.java.net, porters-...@openjdk.java.net, > build-dev <build-...@openjdk.java.net>, HotSpot Open Source > Developers > <hotspot-...@openjdk.java.net>, Java Core Libs > <core-libs-dev@openjdk.java.net> > Subject: Re: RFR: JEP draft for Linux/s3990x port > Message-ID: <6261447a-fc39-4ea6-2ccf-3f0dcc396...@oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > 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 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 are still working on > > simplifying it. The current version looks as follows: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2016/s390x/ > 9000016-constant_table_offset.patch > > > > What are the next steps? Should I add a "jdk9-fc-request" label to t > > he JEP and add a corresponding "FC Extension Request" comment to it? > > Or will this be done automatically once I move it to "Candidate"? > > > > Is there anything left to do before I can move it to "Candidate" state? > > > > Thanks a lot and best regards, > > Volker > > > > > > > > > > On Tue, Sep 27, 2016 at 8:15 PM, Vladimir Kozlov > > <vladimir.koz...@oracle.com> wrote: > >> On 9/27/16 10:49 AM, Volker Simonis wrote: > >>> > >>> Hi, > >>> > >>> can you please review and endorse the following draft JEP for the > >>> integration of the Linux/s390x port into the jkd9 master repository: > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8166730 > >> > >> > >> Good. > >> Add links to webrevs in a comment. It will help to get umbrella FC > extension > >> approval. > >> > >>> > >>> As detailed in the JEP, the Linux/s390x requires very few shared > >>> changes and we therefore don't foresee any impact on the existing > >>> platforms at all. Following you can find a short description of the > >>> planned changes: > >>> > >>> hotspot: > >>> ======= > >>> > >>> Out for review: > >>> 8166560: [s390] Basic enablement of s390 port. > >>> http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/ > hotspot.wr01/ > >>> > >>> Reviewed: > >>> 8166562: C2: Suppress relocations in scratch emit. > >>> http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01/ > >>> > >>> Will send RFR soon (depends on 8166560): > >>> 8166561: [s390] Adaptions needed for s390 port in C1 and C2. > >>> http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01 > >> > >> > >> Wrong link. > >> > >> Thanks, > >> Vladimir > >> > >> > >>> > >>> We are still investigating the need of these shared changes: > >>> > >>> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/ > hotspot/9000011-pass_PC_to_retAddrOffset.patch > >>> > >>> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/ > hotspot/9000016-constant_table_offset.patch > >>> > >>> And finally the patch with the s390x-only platform files. We are still > >>> editing these to get them into OpenJdk style and shape. > >>> Hotspot passes most jck, jtreg and spec tests with these. > >>> > >>> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/ > hotspot/9000101-zFiles.patch > >>> > >>> top-level repository: > >>> =============== > >>> > >>> The following is just adding some s390x specific compiler flags to > >>> flags.m4 > >>> 8166800: [s390] Top-level build changes required for Linux/s390x > >>> https://bugs.openjdk.java.net/browse/JDK-8166800 > >>> > >>> jdk repository: > >>> ============ > >>> > >>> This one just adds a new jvm.cfg file for s390x > >>> 8166801: [s390] Add jvm.cfg file for Linux/s390x > >>> https://bugs.openjdk.java.net/browse/JDK-8166801 > >>> > >>> > >>> And finally we plan to do one more change which fixes the jtreg test > >>> on Linux/s390x. But this is mainly for the correct detection of the > >>> platform and for excluding the tests which are not appropriate for > >>> s390x. > >>> > >>> Thank you and best regards, > >>> Volker > >>> > >> > > > ------------------------------ > > Message: 4 > Date: Thu, 29 Sep 2016 20:43:03 +0200 > From: Aleksey Shipilev <sh...@redhat.com> > To: Rafael Winterhalter <rafael....@gmail.com>, > core-libs-dev@openjdk.java.net > Subject: Re: Proposal to introduce method > "Instrumentation.getInstance()" to instrument the current VM > Message-ID: <3ad03f40-47e6-1b74-eb24-214ae3975...@redhat.com> > Content-Type: text/plain; charset=utf-8 > > 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 believe that this approach will grow in popularity > > with Java 9 where the Attach API is also part of any regular VM. > > > interface Instrumentation { > > static Instrumentation getInstance(boolean redefine, boolean > retransform, > > boolean nativePrefix) { > > // security manager check > > return getInstance0(redefine, retransform, nativePrefix); > > } > > } > > I would like to second this proposal. > > Our very own JOL [1] uses self-attach [2] to get Instrumentation > instance for carefully polling Object instance sizes. Self-attach > enables JOL usage as the library dependency without requiring command > line tweaks. > > Thanks, > -Aleksey > > [1] http://openjdk.java.net/projects/code-tools/jol/ > [2] > http://hg.openjdk.java.net/code-tools/jol/file/b5653b56d154/jol-core/src/ > main/java/org/openjdk/jol/vm/InstrumentationSupport.java > > > > ------------------------------ > > Message: 5 > Date: Thu, 29 Sep 2016 20:06:12 +0100 > From: Alan Bateman <alan.bate...@oracle.com> > To: Rafael Winterhalter <rafael....@gmail.com>, > core-libs-dev@openjdk.java.net > Subject: Re: Proposal to introduce method > "Instrumentation.getInstance()" to instrument the current VM > Message-ID: <8235b50a-7f93-a60a-10b1-c661d9638...@oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > 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 check > > return getInstance0(redefine, retransform, nativePrefix); > > } > > } > > > The original intention, back in JSR 163, was that java.lang.instrument > be for instrumentation agents, not applications. This is why the API > deliberately does not include a method to get the Instrumentation object > along the lines you have propose. Sure, you can leak it from an agent > started on the command line or attached at runtime but that is not the > original intention. So I think introducing this method is a very > significant change that would require a lot of consideration (previous > requests to provide a way for applications to get the Instrumentation > object without an agent in the picture were resisted). > > Separately, introducing this method creates a complication for runtimes > that do not have JVM TI support (the JPLIS agent is based on JVM TI). As > things stand then it's possible to create a runtime that does not have a > means to start agents from the command-line (the spec allows this) and > so there is no need to have the implementation support for this API. So > if a method like this is every introduced then it would either have to > be optional or it would require changes to the JVM TI spec to make it > non-optional (or is based on an alternative JPLIS implementation that > doesn't use JVM TI). > > -Alan > > > ------------------------------ > > Message: 6 > Date: Thu, 29 Sep 2016 20:09:43 +0100 > From: Chris Hegarty <chris.hega...@oracle.com> > To: Hamlin Li <huaming...@oracle.com>, core-libs-dev > <core-libs-dev@openjdk.java.net> > Subject: Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable > tests fail intermittently due to "Port already in use" > Message-ID: <e4e9cba7-4ec3-4cae-ad9c-e6190abe7...@oracle.com> > Content-Type: text/plain; charset=utf-8 > > On 29 Sep 2016, at 16:25, Chris Hegarty <chris.hega...@oracle.com> 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 create the server channel on an ephemeral port and report it > back to the test, i.e. remove the free port pattern. > > http://cr.openjdk.java.net/~chegar/8085192_webrev/ > > 1) The port number is reported from rmid to the test over stdout. > > 2) All tests pass except CheckAnnotations.java, which looks for stderr > ( see 3 below ). I think the stderr check can be removed, and the > just check stdout. > > 3) rmid, when using inheritChannel, redirects stderr to a tmp file, so > it is not possible to get the processes stderr over the processes > stderr pipe. I did?t find that this was an issue when testing ( other > than having to clear out /tmp ) > > 4) This could be expanded to other tests, outside of activation, to > remove more usages of free port. > > This is not yet complete, I just want to share the idea to see if it is a > runner, or not. > > -Chris. > > > > ------------------------------ > > Message: 7 > Date: Thu, 29 Sep 2016 19:22:10 +0000 > From: Remi Forax <fo...@univ-mlv.fr> > To: Alan Bateman <alan.bate...@oracle.com>, Rafael Winterhalter > <rafael....@gmail.com>, core-libs-dev@openjdk.java.net > Subject: Re: Proposal to introduce method > "Instrumentation.getInstance()" to instrument the current VM > Message-ID: <b4a457ca-3a0c-46dc-9cae-3217d6256...@univ-mlv.fr> > Content-Type: text/plain; charset=UTF-8 > > > > On September 29, 2016 9:06:12 PM GMT+02:00, Alan Bateman < > alan.bate...@oracle.com> 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 Instrumentation getInstance(boolean redefine, boolean > >retransform, > >> boolean nativePrefix) { > >> // security manager check > >> return getInstance0(redefine, retransform, nativePrefix); > >> } > >> } > >> > > I've a code that also does that for implementing a Repl like JShell. > > >The original intention, back in JSR 163, was that java.lang.instrument > >be for instrumentation agents, not applications. This is why the API > >deliberately does not include a method to get the Instrumentation > >object > >along the lines you have propose. Sure, you can leak it from an agent > >started on the command line or attached at runtime but that is not the > >original intention. So I think introducing this method is a very > >significant change that would require a lot of consideration (previous > >requests to provide a way for applications to get the Instrumentation > >object without an agent in the picture were resisted). > > > >Separately, introducing this method creates a complication for runtimes > > > >that do not have JVM TI support (the JPLIS agent is based on JVM TI). > >As > >things stand then it's possible to create a runtime that does not have > >a > >means to start agents from the command-line (the spec allows this) and > >so there is no need to have the implementation support for this API. So > > > >if a method like this is every introduced then it would either have to > >be optional or it would require changes to the JVM TI spec to make it > >non-optional (or is based on an alternative JPLIS implementation that > >doesn't use JVM TI). > > Having it optional seams fine. > Perhaps it has to be activated by a command line argument too. > > > > >-Alan > > R?mi > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > > End of core-libs-dev Digest, Vol 113, Issue 94 > ********************************************** >
