Regression (b95): OOM on filter/limit operation on unbound/parallel stream
paul.sandoz at oracle.com
Fri Jun 21 02:40:09 PDT 2013
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!
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:
>> 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.
More information about the lambda-dev