8205132: Remove Thread.countStackFrames()

[Daniel D. Daugherty]

On 10/29/19 12:26 PM, Alan Bateman 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).
>
> http://cr.openjdk.java.net/~alanb/8205132/webrev.02/

make/hotspot/symbols/symbols-unix
     No comments.

src/hotspot/share/include/jvm.h
     No comments.

src/hotspot/share/prims/jvm.cpp
     No comments.

src/java.base/share/classes/java/lang/Thread.java
     No comments.

src/java.base/share/native/libjava/Thread.c
     No comments.

test/jdk/java/lang/Thread/CountStackFrames.java
     No comments.

test/hotspot/jtreg/runtime/Thread/CountStackFramesAtExit.java
     Deleted file. No comments.

Thumbs up.


> https://bugs.openjdk.java.net/browse/JDK-8232654
>
> 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.

I believe that regression is due my work on Thread-SMR (Safe Memory
Reclaimation).

Do we need a bug filed against JDK1[012] to document the regression?

Dan


>
> -Alan