ParallelStream Vs Stream Digest, Vol 113, Issue 94
Prakhar Makhija
matcdac at gmail.com
Fri Sep 30 04:24:16 UTC 2016
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-request at openjdk.java.net> wrote:
> Send core-libs-dev mailing list submissions to
> core-libs-dev at 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-request at openjdk.java.net
>
> You can reach the person managing the list at
> core-libs-dev-owner at 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.srinivasan at oracle.com>
> To: Alan Burlison <Alan.Burlison at oracle.com>, Volker Simonis
> <volker.simonis at gmail.com>
> Cc: "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, build-dev
> <build-dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net
> "
> <ppc-aix-port-dev at openjdk.java.net>, Chris Bensen
> <chris.bensen at oracle.com>, core-libs-dev
> <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build
> Message-ID: <57ED540B.9010906 at 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.wth at gmail.com>
> To: core-libs-dev at openjdk.java.net
> Subject: Proposal to introduce method "Instrumentation.getInstance()"
> to instrument the current VM
> Message-ID:
> <CA+DM0An3HSfHBh66zbbJ2dMuL1kd2A5RBqOdZoRLnJ4ijnqWxg at 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.kozlov at oracle.com>
> To: Volker Simonis <volker.simonis at gmail.com>
> Cc: s390x-port-dev at openjdk.java.net, porters-dev at openjdk.java.net,
> build-dev <build-dev at openjdk.java.net>, HotSpot Open Source
> Developers
> <hotspot-dev at openjdk.java.net>, Java Core Libs
> <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JEP draft for Linux/s3990x port
> Message-ID: <6261447a-fc39-4ea6-2ccf-3f0dcc396a36 at 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.kozlov at 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 <shade at redhat.com>
> To: Rafael Winterhalter <rafael.wth at gmail.com>,
> core-libs-dev at openjdk.java.net
> Subject: Re: Proposal to introduce method
> "Instrumentation.getInstance()" to instrument the current VM
> Message-ID: <3ad03f40-47e6-1b74-eb24-214ae3975c54 at 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.Bateman at oracle.com>
> To: Rafael Winterhalter <rafael.wth at gmail.com>,
> core-libs-dev at openjdk.java.net
> Subject: Re: Proposal to introduce method
> "Instrumentation.getInstance()" to instrument the current VM
> Message-ID: <8235b50a-7f93-a60a-10b1-c661d9638bc9 at 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.hegarty at oracle.com>
> To: Hamlin Li <huaming.li at oracle.com>, core-libs-dev
> <core-libs-dev at 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-E6190ABE7837 at oracle.com>
> Content-Type: text/plain; charset=utf-8
>
> On 29 Sep 2016, at 16:25, Chris Hegarty <chris.hegarty at 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 <forax at univ-mlv.fr>
> To: Alan Bateman <Alan.Bateman at oracle.com>, Rafael Winterhalter
> <rafael.wth at gmail.com>, core-libs-dev at openjdk.java.net
> Subject: Re: Proposal to introduce method
> "Instrumentation.getInstance()" to instrument the current VM
> Message-ID: <B4A457CA-3A0C-46DC-9CAE-3217D6256E63 at univ-mlv.fr>
> Content-Type: text/plain; charset=UTF-8
>
>
>
> On September 29, 2016 9:06:12 PM GMT+02:00, Alan Bateman <
> Alan.Bateman at 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
> **********************************************
>
More information about the core-libs-dev
mailing list