Regression (b95): OOM on filter/limit operation on unbound/parallel stream

[Paul Sandoz]

Hi Christian,

I just pushed some changes to F/J from Doug, and changes to AbstractTask.

I can get the max heap size down to -mx27m before it throws OOME with your test case.

Generally parallel execution will almost always use up more memory than sequential execution, but i think we are down to reasonable levels here. Quite clearly requiring 1g or more is not reasonable!

Thanks,
Paul.

On Jun 20, 2013, at 2:06 PM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:

> 
> On Jun 20, 2013, at 1:34 PM, "Mallwitz, Christian" <christian.mallwitz at commerzbank.com> wrote:
> 
>> Hi,
>> 
>> I'm re-reporting an issue in build 95 (build 1.8.0-ea-lambda-nightly-h4816-20130617-b95-b00).
>> 
>> Same sample program as last time (see below):
>> 
>> using -mx1g: serial stream works, parallel stream throwns OOM - no signs of parallelism
>> using -mx1g -Xint: serial stream still works, parallel stream works with speed up
>> using -mx128m -Xint: serial stream still works, parallel stream throwns OOM
>> 
> 
> Thanks, the spinning should be fixed, still working on the OOM issue, it requires some tweaks to F/J CountedCompleter that i am about to try out.
> 
> Paul.
>