Primitive streams and optional

[Doug Lea]

On 11/28/12 10:59, Remi Forax wrote:
> On 11/28/2012 04:27 PM, Doug Lea wrote:
>> On 11/26/12 15:43, Brian Goetz wrote:
>>
>>> 1.  Ban nulls.  This is equivalent to adding
>>>     .tee(e -> { if (e == null) throw new NPE(); }
>>> between all stages of a pipeline.
>>>
>>> 2.  Ignore nulls.  This is what Doug is proposing, and is equivalent to adding
>>>     .filter(e -> e != null)
>>> between all stages of a pipeline.
>>>
>>> 3.  Tolerate nulls.  This treat nulls as "just another value" and hopes that
>>> lambdas and downstream stages can deal.

>> (They do vary a little:  #3 will sometimes be the most expensive,
>> since the lack of a pre-null-check forces twistier code paths
>> to be generated later on first dereference of a field.)
>
> Yes, for #3, if someone call any stream pipelines without sending null, it's ok.
> If there is just one codepath that sends one null through one pipeline, the user
> will pay a high tax once because the VM may have to deoptimize a lot of pipeline
> codes (not just the code of one pipeline).

Mostly an aside: Hoisting various null checks (including especially
whether the supplied lambdas are null) in the specialized CHM
FJ tasks gives a consistent 5% speedup. 5% is not huge, but
for a heavily used core library class, it's worth the effort.
For some of the task classes, I have more lines of code doing
the hoisted null and bounds checks than actual foreach etc code.
The main reason it is effective is that the VM cannot hoist
them further because it must unpack from the task objects,
which sometimes entails some volatiles/atomics, forcing rereads.
(Digressing further: A paper at Splash last month showed
that you could avoid this in most cases by using stack frames
for task closures and using exception mechanics for dealing with
steals and stolen tasks. This would require major surgery on
JVMs though.)

-Doug