8205132: Remove Thread.countStackFrames()

[Alan Bateman]

On 24/10/2019 17:32, seth lytle wrote:
> The use case that's always interested me is checking to see if a
> callback to a recursive method (eg during parsing) is "too deep" so
> you can bail out (eg, to a non-recursive one or using message
> passing). For that purpose, it's already suspended and the native
> method is close to what I'd like if it wasn't deprecated.
>
> You started this discussion by claiming that "The StackWalker API is a
> much better solution for code that is interested in the number of
> stack frames". Seems like a benchmark is a critical part of that
> claim. The stack walker approach looked 8x-ish slower for deep stacks
> (eg, 1000 and 5000), which is about what I expected given all the
> unnecessary object allocations. The walker API also seemed more prone
> to stack overflows, but I didn't take the time to quantify that.
> Here's one example run (java 11 with defaults):
Thread::countStackFrames is specified to throw 
IllegalThreadStateException when the thread is not suspended. The spec 
doesn't make an exception for the current thread. I just checked JDK 8 
and JDK 13 and Thread.currentThread().countStackFrames() throws the 
exception as specified. However, it seems the behavior flip flopped in 
the intervening releases due to changes to get it to work with 
Thread-SMR and then again when it was changed to use the TL handshake 
implementation. So I think you got lucky and the results would be 
different if there was thread suspension in the benchmark. Your initial 
paragraph mentions "already suspended" so maybe that is a different 
scenario.

It's good to push on StackWalker as there may be additional use-cases 
that need attention.


> :
>
> What would be even more useful than stack depth would be an estimate
> of the number of bytes remaining in the stack, esp if it was fast. Any
> chance that that could get added to the stack walker API ?
>
I don't think that needs a stack walk. It might be useful to start a new 
discussion to make a case for code that could potentially avoid SO. In 
the distant past there was a tiny number of cases in the JDK libraries 
that alloc'ed on the stack but it hasn't been needed in recent time 
(partly due to improvements in the stack banging and zones at the end of 
the stack, partly due to reduced use of the stack in the JNI methods).

-Alan