Internal and External truncation conditions

[Remi Forax]

On 02/10/2013 03:02 PM, Doug Lea wrote:
> On 02/10/13 08:47, Remi Forax wrote:
>> On 02/10/2013 02:42 PM, Doug Lea wrote:
>
>>> Any per-element lambda supplied to any Stream method can
>>> itself do any kind of async cancel check itself, and throw
>>> an exception rather than returning a result.
>>>
>>> Case closed?
>>
>> No, throwing an exception when the VM thinks that can it can escape 
>> is really slow.
>>
>
> That's my point exactly! If you want to slow down bulk ops
> for the sake of responsiveness, then you should be aware of
> the tradeoffs. In practice, fine-grained cancel-checks
> are rarely worthwhile (you'd often finish 10 times faster,
> and thus usually not need to cancel, without the checks).
> But it should be the user's decision, not ours.
> Otherwise, we cannot internally arrange/support
> cancellation any faster than users can, but would
> penalize ALL users for the sake of those who need it.

yes, you can it's exactly what j.l.i.SwitchPoint does.
Note that we can't transform the whole pipeline to a method handle tree 
because we have no loopy method handle now, but if we have that, you can 
create a method handle tree corresponding to the pipeline and when the 
code will be JITed, with the new lambda form it will, the check will 
disappear and if a user calls cancl, the JITed code will be trashed and 
the execution will go back into the interpreter that will do the check.

>
> -Doug
>
>

Rémi