Proposed API for JEP 259: Stack-Walking API

[David M. Lloyd]

On 11/04/2015 07:15 PM, Mandy Chung wrote:
> [...]
> For short-circuiting, I also think it’s reasonable to expect the user know how many remaining frames it expects to traverse and it may not need to increase the batch size i.e. it might not need to update the remainingNeeded over time.  The user to supply the estimate number of frames needed may be adequate for it (like what you suggest previously having the walk method to take an initial batch size for the simple case).
>
> Walking the entire stack (or almost all stack frames) is the use case that this hint may help in performance   since the stack depth is unknown and it’s a tradeoff between memory and runtime.   Throwable::init and AccessControlContext are the use cases that need to be performant.  It’s better to wait for more experience of using the StackWalker and see if any other use cases need adaptive sizing .  I propose to drop this walk(Function, IntUnaryFunction) for now and decide to add such ability later.

Yeah I agree, and furthermore I strongly suspect that there is only one 
"best" batch size for the majority of whole-stack traversals.

> For taking the estimated number of consumed frames, one option is to have a walk(int initialFramesNeeded, Function function) method.  The other option is to have the
>     StackWalker(int minDepth, int maxDepth, Set<Option> options)
>
> It’s cheap to have one StackWalker for each kind of stack walking.  Having the constructor to take an additional minDepth (or estimate minimum number of frames to be traversed) seems a better option.
>
> Any thought?

That seems like a reasonable hint to expect of the user, as long as it 
*is* a hint and not a hard limit, and even better if the hint is optional.

-- 
- DML