I created https://bugs.openjdk.java.net/browse/JDK-8189752 to track this.
Mandy
On 10/20/17 10:35 AM, Rafael Winterhalter wrote:
Hei Mandy,
thank you for your quick reply.
The benchmark is already only capturing the stack frame object. I ran
the benchmark with the transformation as a comparis
This would could also make sense for asynchronous logging with Log4j 2. We
currently disabled capturing location information for asynchronous logging as
capturing the information before passing the information to the thread doing
the logging is fairly expensive. Being able to capture the stack t
Hei Mandy,
thank you for your quick reply.
The benchmark is already only capturing the stack frame object. I ran the
benchmark with the transformation as a comparison and it is indeed slower
due to extra work. The JIT code suggests the native method plus monitor to
be the major cost here but it is
Hi Rafael,
Thanks for the feedback. We did some investigation in understanding the
overhead of Throwable if it used StackWalker API [1]. It did come to
mind whether the StackWalker API should provide a way to walk the
backtrace which we should do the investigation with JDK-8141239.
The ben
> > Envoyé: Vendredi 20 Octobre 2017 15:32:33
> > Objet: Decreased latency performance with Stack Walker API compared to
> sun.misc.JavaLangAccess
>
> > Hello,
> >
> > a typical patern when reading the stack of the current thread in tooling
> > like per
oyé: Vendredi 20 Octobre 2017 15:32:33
> Objet: Decreased latency performance with Stack Walker API compared to
> sun.misc.JavaLangAccess
> Hello,
>
> a typical patern when reading the stack of the current thread in tooling
> like performance monitoring used to imply the creati
Hello,
a typical patern when reading the stack of the current thread in tooling
like performance monitoring used to imply the creation of an instance of
Throwable and to process this instance's attached stack in another thread.
The performance cost is shared about 10/90 for creating a new throwabl
