Proposed API for JEP 259: Stack-Walking API

[Mandy Chung]

> On Oct 30, 2015, at 3:38 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> On 10/30/2015 03:39 PM, Mandy Chung wrote:
>>> On Oct 30, 2015, at 12:59 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>> Since this is very likely to be a one-implementation API, is there a reason to have a separate WalkerOption interface and Option enum?  Seems like you could just skip the interface.
>> 
>> Locals and operands is one experimental feature in mind that is not target for JDK 9.   But it would be an interesting feature for e.g. Fibers to experiment.  This will also allow JDK-specific capability to be implemented in the future.
> 
> Ah, that makes sense, I forgot about cases where the JDK itself might have non-spec extensions.  It should probably be specified in the docs that unrecognized options are either ignored or rejected though.

I decide to take out WalkerOption interface, as I didn’t like that as much for supporting one single known extension at the moment.  I found another way doing it (by a factory method to return a StackWalker instance with extended capability).

> 
>>> All that boxing seems unnecessary... the next best candidate I can see though is IntToLongFunction.  I wonder why we didn't do an IntToIntFunction in JSR 335.  Or maybe the stream itself should be somehow made aware of the optimum batch size.  What's the use case for changing the batch size as you iterate?
>>> Is the traversal *that* expensive?
>> 
>> Altering the first batch size would be useful for Log4J and Groovy use cases that filter implementation classes and finds the caller.   Altering subsequent batch size is more as a flexible option.  One can simple have the function to return the same batch size.
> 
> Maybe an overload of walk() which accepts an int (initial batch size) in addition to the function for the simple case?
> 

Maybe.  It’d be good to get further feedback and use cases to decide adding another variant.

>> I do think IntSupplier is probably a better choice that won’t restrict to supply only the initial batch size.   The last batch size parameter is solely for information.
> 
> UnaryOperator is a good option too

Yup.  I have updated the API to use that.

> (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.

thanks
Mandy