8205132: Remove Thread.countStackFrames()
Alan Bateman
Alan.Bateman at oracle.com
Thu Oct 24 19:41:23 UTC 2019
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
More information about the core-libs-dev
mailing list