logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörn Huxhorn <jhuxh...@googlemail.com>
Subject Re: Relfection.getCallerClass
Date Mon, 29 Jul 2013 09:47:39 GMT
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-reflection
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 "best" solution using SecurityManager is still 100x slower than the original Reflection
call while the Throwable solution is about 470x slower. D:
This is a disaster, especially for our logging use-case with lots and lots of calls.

This is also causing issues for Groovy http://jira.codehaus.org/browse/GROOVY-6279 but it's
a lot less severe since the code won't get executed nearly as often as in our case.

My hope was that, together, we could probably make a difference.
I also thought that a bigger "audience" 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. Anyway, I just subscribed to the core-list. Didn't even know
about it. I hope that "open" in open-jdk isn't just PR… *sigh*

Cheers,
Jörn.

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

Thanks Jörn,

This was first reported to us in May in LOG4J2-245.  Nick sent a message to the openjdk list
at that time [1] but it seemed to be ignored.  How would you propose we convince Oracle?
 To be honest, I would much prefer that I be able to get a stack trace from a Throwable that
has the Class objects in it, instead of just the class names.

Ralph



[1] http://mail.openjdk.java.net/pipermail/java-se-8-spec-comments/2013-May/000014.html

On Jul 26, 2013, at 2:43 AM, Jörn Huxhorn wrote:

Hi everyone.

I wanted to inform you about the following Logback issues since their root 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_bug.do?bug_id=8016814
- will throw an UnsupportedOperationException in upcoming Java7u40. http://bugs.sun.com/view_bug.do?bug_id=8014925
- will be removed in Java8 with no replacement. http://bugs.sun.com/view_bug.do?bug_id=8020785

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

http://bugs.sun.com/view_bug.do?bug_id=8014925 contains the following text:
"JEP-176 proposes to remove sun.reflect.Reflection.getCallerClass(int) that has incompatibility
concern since there are existing applications depending on this private API such as Oracle
Diagnostic Logging and jidesoft 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 7u25.

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 proper replacement
for it. Allow at least 2 CPU releases to allow customers to make appropriate change.  So
the earliest for the removal is 7u55.  If there are valid use cases but no proper replacement,
we may keep this private API in jdk7u for longer."
I consider the use of this API in logging frameworks a very valid use case, especially since
the only replacements available would have severe impact on the performance (other techniques
like generating a Stacktrace via Throwable are even slower than the SecurityManager workaround
in the pull request) - so we should probably all try to convince Oracle that a proper replacement,
ideally in a public API, is needed.

Cheers,
Jörn.

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

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


Mime
View raw message