RFR: 8355636: Speed ​​up Throwable::printStackTrace by reducing object allocation [v3]

Shaojin Wen swen at openjdk.org
Sat Apr 26 09:21:33 UTC 2025


On Sat, 26 Apr 2025 08:41:28 GMT, Eirik Bjørsnøs <eirbjo at openjdk.org> wrote:

> Even if that was the case, for any printing to be useful to any human beeing it would require IO to disk, database or have some form of external effect rather than just printing it to a NullOutputStream which is what the benchmark here does. Factor IO into the equation and my guess is those 10% are a lot closer to zero.
> 
> Doing the wrong thing faster is not the way to go.

![image](https://github.com/user-attachments/assets/917e0e84-7a36-4c35-80fd-903cf2268859)

When the input is incorrect, an exception will be thrown. For example, the parameter check Integer.parseInt. Another example is that the index passed in is incorrect, which leads to an array or ArrayList boundary check exception. These are not the normal paths we expect. When abnormal external calls occur, such as OpenAPI, Java Web backend code processes the json input by the front end, exceptions will often occur.

In many framework codes, when an exception occurs, the Log library will be used to print the exception to make the problem easier to diagnose, rather than ignoring the exception. At this time, printStackTrace needs to pay attention to performance issues.


In the entire process of throwing an exception and PrintStackTrace, Throwable::getOutStackeTrace and Throwable::fillStackTrace take up about 1/3 of the time, and more time is consumed in the printStackTrace method itself, so we need to optimize this.

@eirbjo found that using NullOutputStream in performance testing is not good, so I changed it to FileOutputStream.

Changing from NullOutputStream to FileOutpuStream, the performance improvement increased from 11% to 5%~9%. Because PrintStream uses BufferedWriter, it will cache a certain amount of data before flushing, so using FileOutpuStream will affect performance, but not much.

Here are the performance numbers on the MacBook Pro M1 Max

git remote addd wenshao https://github.com/wenshao/jdk
git fetch wenshao

# baseline
git checkout 53873fb2178add153d1a6edb932a915fc1c63dc6
make test TEST="micro:java.lang.Throwables"

# current
git checkout e40726c1c0dfcbc284010b187e3203617afef519
make test TEST="micro:java.lang.Throwables"




# baseline 53873fb2178add153d1a6edb932a915fc1c63dc6
-Benchmark                           Mode  Cnt       Score      Error  Units
-Throwables.printEnclosedStackTrace  avgt   15   69365.403 ± 2026.607  ns/op
-Throwables.printStackTrace          avgt   15  109287.777 ± 5074.292  ns/op

# current e40726c1c0dfcbc284010b187e3203617afef519
+Benchmark                           Mode  Cnt       Score      Error  Units
+Throwables.printEnclosedStackTrace  avgt   15   65948.100 ± 3869.844  ns/op +9.99%
+Throwables.printStackTrace          avgt   15  103575.966 ± 4825.130  ns/op +5.51%

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24864#issuecomment-2831985668


More information about the core-libs-dev mailing list