core-libs-dev
Subject: [External] : Re: Streams, parallelization, and OOME.
Thanks Viktor, this was what I was looking for.
Ok, so due to existing difficulties in translating push to pull, it makes sense
why this wouldn't work.
I really look forward to upgrading my codebase soon. Gathe
Thanks Viktor, this was what I was looking for.
Ok, so due to existing difficulties in translating push to pull, it makes
sense why this wouldn't work.
I really look forward to upgrading my codebase soon. Gatherers fixed window
completely negates this problem. At least, it appears to.
On Mon, Oc
Hi David,
Stream::spliterator() and Stream::iterator() suffer from inherent limitations
(see https://bugs.openjdk.org/browse/JDK-8268483 ) because they attempt to
convert push-style streams into pull-style constructs (Iterator, Spliterator).
Since the only way to know if there's something to pu
But *not letting any of them through into the forEach loop.
On Sat, Oct 19, 2024, 9:36 AM David Alayachew
wrote:
> So to be clear, I added a logger to my BufferedReader. So I know for a
> fact that it is reading data.
>
> And as for the code, it is a very simple parallel forEach.
>
> someStream.
So to be clear, I added a logger to my BufferedReader. So I know for a fact
that it is reading data.
And as for the code, it is a very simple parallel forEach.
someStream.parallel().forEach(**work**);
I only wanted to change the execution from sequential to parallel.
So I have millions and mill
Hi David. I am not a core libs team but I guess I can have some clues :).
It is hard to tell without the code, but I assume that there are a few
layers to it.
1. Stalling. I would assume it is caused mostly by GC pauses taking too
long (forever) if GC does not have any computational powers to run
