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
