8205132: Remove Thread.countStackFrames()
seth.lytle at gmail.com
Tue Oct 29 16:58:25 UTC 2019
Was there a technical reason that the method was specified to fail
when called from within the same thread ? Ie, is there a race
condition or something similar that can happen, perhaps because the
JVM relocates the stack ?
On Tue, Oct 29, 2019 at 12:26 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 23/10/2019 08:25, Alan Bateman wrote:
> > Thread::countStackFrames has been deprecated for 20+ years and has
> > been marked for-removal since Java SE 9. I'd like to remove it for
> > Java SE 14. It's was never a well-defined method and I've been unable
> > to find anything that uses it. The StackWalker API is a much better
> > solution for code that is interested in the number of stack frames.
> Joe Darcy has suggested degrading the method in advance of its removal.
> We did the same with stop(Throwable) when we changed it to throw UOE in
> Java SE 8 before finally removing it in 11. Here is the updated webrev
> and CSR. The CSR will need to be re-reviewed. The method description is
> brief and the same as what we did for stop(Throwable).
> Also just to summarize the discussion/objection from Seth Lytle. I think
> we've established that that it was a regression in JDK 10 that allowed
> that example to work. The method has always been specified to fail when
> the thread is not suspended.
More information about the hotspot-runtime-dev