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
