You should absolutely not assume parallel streams are faster than
sequential streams.
http://gee.cs.oswego.edu/dl/html/StreamParallelGuidance.html is pretty much
the iconic document on that subject, and explains circumstances under which
parallelism is good, and when it is likely to be harmful.
On
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 o
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 I
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 te
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
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 think
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
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 improvemen
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
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.
http://cr
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
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 Instrumentation getInstance(boole
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 create the server channel on an
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
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 bel
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 JE
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
wit
+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
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. Vo
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 self-contained. I don't want to d
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 a
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 o
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 eve
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 copies of the
> launch wi
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 misunder
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
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:
On 29/09/2016 3:44 AM, Carsten Varming wrote:
Dear Vitaly and David,
Looking at your webrev the orig
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
al
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 always
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 Simonis
>> wrote:
>>
>> >
>> > I don't think this can be easily done with th
30 matches
Mail list logo