Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Received-SPF: pass (athena.apache.org: domain of jhuxhorn@googlemail.com
 designates 74.125.83.51 as permitted sender)
Date: Mon, 29 Jul 2013 11:47:39 +0200
From: =?UTF-8?Q?J=C3=B6rn_Huxhorn?= <jhuxhorn@googlemail.com>
To: Log4J Developers List <log4j-dev@logging.apache.org>
Cc: 
Message-ID: 
 <etPan.51f63a3b.66334873.13699@LBFRA-0705-JHuxhorn-244-MBP15.local>
In-Reply-To: <3B27DC37-53F0-4A8A-9594-9F5EC980B481@dslextreme.com>
References: 
 <etPan.51f244a8.643c9869.13699@LBFRA-0705-JHuxhorn-244-MBP15.local>
 <3B27DC37-53F0-4A8A-9594-9F5EC980B481@dslextreme.com>
Subject: =?UTF-8?Q?Re=3A_Relfection.getCallerClass?=
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm highly concerned about speed.

The workaround in the logback pull-request has some benchmarks regarding =
alternative ways to get the required info and those are quite shocking:

> This solution was found from http://stackoverflow.com/questions/421280/=
in-java-how-do-i-find-the-caller-of-a-method-using-stacktrace-or-reflecti=
on and 1,000,000 calls of all alternatives were measured as follows :
> Reflection: 10.195 ms.
> Current Thread StackTrace: 5886.964 ms.
> Throwable StackTrace: 4700.073 ms.
> SecurityManager: 1046.804 ms.

The =22best=22=C2=A0solution=C2=A0using SecurityManager is still 100x slo=
wer than the original Reflection call while the Throwable solution is abo=
ut 470x slower. D:
This is a disaster, especially for our logging use-case with lots and lot=
s of calls.

This is also causing issues for Groovy=C2=A0http://jira.codehaus.org/brow=
se/GROOVY-6279 but it's a lot less severe since the code won't get execut=
ed nearly as often as in our case.

My hope was that, together, we could probably make a difference.
I also thought that a bigger =22audience=22 would increase the likeliness=
 that some of us knows one of the responsible persons personally - which =
would probably have more impact than just a message on a mailing list. An=
yway, I just subscribed to the core-list. Didn't even know about it. I ho=
pe that =22open=22 in open-jdk isn't just PR=E2=80=A6 *sigh*

Cheers,
J=C3=B6rn.

On 27. Juli 2013 at 17:53:19, Ralph Goers (ralph.goers=40dslextreme.com) =
wrote:

Thanks=C2=A0J=C3=B6rn,

This was first reported to us in May in LOG4J2-245. =C2=A0Nick sent a mes=
sage to the openjdk list at that time =5B1=5D but it seemed to be ignored=
. =C2=A0How would you propose we convince Oracle=3F =C2=A0To be honest, I=
 would much prefer that I be able to get a stack trace from a Throwable t=
hat has the Class objects in it, instead of just the class names.

Ralph


=5B1=5D=C2=A0http://mail.openjdk.java.net/pipermail/java-se-8-spec-commen=
ts/2013-May/000014.html

On Jul 26, 2013, at 2:43 AM, J=C3=B6rn Huxhorn wrote:

Hi everyone.

I wanted to inform you about the following Logback issues since their roo=
t causes will also impact log4j:

http://jira.qos.ch/browse/LOGBACK-885
https://github.com/qos-ch/logback/pull/136

In short:
sun.reflect.Reflection.getCallerClass
- changed behavior in Java7u25 since the stack frames have changed. http:=
//bugs.sun.com/view=5Fbug.do=3Fbug=5Fid=3D8016814
- will throw an=C2=A0UnsupportedOperationException in upcoming Java7u40.=C2=
=A0http://bugs.sun.com/view=5Fbug.do=3Fbug=5Fid=3D8014925
- will be removed in Java8 with no replacement. http://bugs.sun.com/view=5F=
bug.do=3Fbug=5Fid=3D8020785

https://github.com/qos-ch/logback/pull/136 contains a way to get similar =
informations but, unfortunately, it is 100x slower than=C2=A0sun.reflect.=
Reflection.getCallerClass.

http://bugs.sun.com/view=5Fbug.do=3Fbug=5Fid=3D8014925 contains the follo=
wing text:
=22JEP-176 proposes to remove sun.reflect.Reflection.getCallerClass(int) =
that has incompatibility concern since there are existing applications de=
pending on this private API such as Oracle Diagnostic Logging and jidesof=
t library that breaks Oracle Primavera.

The jdk part of JEP-176 has been backported to 7u25 but keep sun.reflect.=
Reflection.getCallerClass(int) as the mitigration plan (JDK-8014745) in 7=
u25.

The following describes the transition plan to allow customers to migrate=
 their applications away from this private API:
1. Disable sun.reflect.Reflection.getCallerClass(int) in 7u40 and provide=
 a flag to re-enable it
2. Determine how this private API is being used and the use cases
3. Remove this private API if there is no valid use case or there is a pr=
oper replacement for it. Allow at least 2 CPU releases to allow customers=
 to make appropriate change. =C2=A0So the earliest for the removal is 7u5=
5. =C2=A0If there are valid use cases but no proper replacement, we may k=
eep this private API in jdk7u for longer.=22
I consider the use of this API in logging frameworks a very valid use cas=
e, especially since the only replacements available would have severe imp=
act on the performance (other techniques like generating a Stacktrace via=
 Throwable are even slower than the SecurityManager workaround in the pul=
l request) - so we should probably all try to convince Oracle that a prop=
er replacement, ideally in a public API, is needed.

Cheers,
J=C3=B6rn.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe=40logging.apache.org
=46or additional commands, e-mail: log4j-dev-help=40logging.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org