Proposed API for JEP 259: Stack-Walking API (original) (raw)

forax at univ-mlv.fr forax at univ-mlv.fr
Sat Oct 31 19:37:09 UTC 2015

You're right, the JVM never stops to amaze me !

It's not that hard to believe, Thread.currentThread and Object.getClass() are both intrinsics and the current thread pointer is stored at the bottom (top) of the stack and getClass is just an indirection.

thanks, Rémi

----- Mail original -----

De: "Peter Levart" <peter.levart at gmail.com> À: "Remi Forax" <forax at univ-mlv.fr>, "Mandy Chung" <mandy.chung at oracle.com> Cc: core-libs-dev at openjdk.java.net Envoyé: Samedi 31 Octobre 2015 20:23:14 Objet: Re: Proposed API for JEP 259: Stack-Walking API

On 10/31/2015 07:29 PM, Remi Forax wrote:

> also instead of Optional.orElse, orElseGet is better because it avoids to > evaluate

> Thread.currentThread().getClass() if not necessary.

> So the example should be:

> walk(s -> s.map(StackFrame::getDeclaringClass) > .findFirst()).orElseGet(() -> Thread.currentThread().getClass());

It might be hard to believe, but the evaluation of constant lambda expression is approx. equally expensive as the expression it encapsulates in this example, so it really is an overkill here:

Benchmark Mode Cnt Score Error Units LambdaVsCurrentThreadBench.getCurrentThreadClass avgt 10 2.202 ± 0.058 ns/op LambdaVsCurrentThreadBench.getCurrentThreadClassSupplier avgt 10 2.196 ± 0.159 ns/op

@BenchmarkMode(Mode.AverageTime) @Fork(1) @Warmup(iterations = 5) @Measurement(iterations = 10) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class LambdaVsCurrentThreadBench { @Benchmark public Class<?> getCurrentThreadClass() { return Thread.currentThread().getClass(); }

@Benchmark public Supplier<Class<?>> getCurrentThreadClassSupplier() { return () -> Thread.currentThread().getClass(); } }

Regards, Peter

More information about the core-libs-dev mailing list