Internal and External truncation conditions
forax at univ-mlv.fr
Sun Feb 10 06:28:19 PST 2013
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.
More information about the lambda-libs-spec-observers