Proposed API for JEP 259: Stack-Walking API

[forax at univ-mlv.fr]

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