Proposed API for JEP 259: Stack-Walking API

[David M. Lloyd]

On 10/30/2015 11:24 PM, Mandy Chung wrote:
>On Oct 30, 2015, at 3:38 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> (that's what I was looking for before), or maybe even ToIntFunction<X> where X is something that might inform the next batch size based on the work that has already been done - maybe even a Stream<StackFrame> that consists only of the current batch?
>>
>> Or another idea:
>>   <T> T walk(BiFunction<Stream<StackWalker.StackFrame>, IntConsumer, T> function);
>>
>> where the IntConsumer can be called at any time to update a minimum number of remaining frames needed, which in turn can (with the knowledge of how many elements have been consumed by the stream) inform the next batch size.
>
> The stack walker won’t get the next batch until all frames of the current batch are consumed.  I think the current walk methods would cover what this one does.  There are other ideas to add other variants of the walk methods and short-cut for performance.        I keep these ideas in mind and consider them once more feedback is collected.

I think there are two problems with the current approach:

1. The function for getting the next batch size is not coupled to the 
function actually doing the work.  I think it is just as likely (if not 
more so) that any information about the optimum number of frames to be 
gathered per batch can only be sensibly determined as a result of the 
current work being done.  In this case, you'd have to do something odd 
like use a captured shared AtomicInteger or similar to pass information 
back and forth, which is not good.

2. The fact that frames are acquired in batches is an implementation 
detail.  I do not believe it's a reasonable expectation of a user to 
know the optimum batch size; the API should not be exposing 
implementation details like this.  On the other hand, the user might be 
reasonably expected to be able to inform the stack walker as to how many 
more frames are expected to be needed.  The stack walker could easily 
use this information, even if it fetches in batches, by keeping a 
"remainingNeeded" counter of number of remaining frames expected to be 
used, which is decremented each time the stream returns an item, and 
read when a new batch is needed: it could (for example) use Math.min(10, 
remainingNeeded).

-- 
- DML