8010309 : PlatformLogger: isLoggable performance / waste due to HashMap<Integer, Level (original) (raw)

Laurent Bourgès bourges.laurent at gmail.com
Thu Mar 28 12:55:08 UTC 2013

My benchmaks are also OK: run: -XX:+AggressiveOpts -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=268435456 -XX:MaxHeapSize=268435456 -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal -XX:+UseCompressedKlassPointers -XX:+UseCompressedOops -XX:+UseParallelGC mars 28, 2013 1:53:57 PM test.PlatformLoggerBenchmark ############################################################## SEVERE: PlatformLogger started

Java: 1.8.0-internal-bourgesl_2013_03_19_14_35-b00

VM: OpenJDK 64-Bit Server VM 25.0-b22 (mixed mode)

OS: Linux 2.6.35.14-106.fc14.x86_64 (amd64)

CPUs: 4 (virtual)

#-------------------------------------------------------------

isLoggableFinest: run duration: 5 000 ms

Warm up:

1 threads, Tavg = 2,94 ns/op (σ = 0,00 ns/op) [ 2,94]

1 threads, Tavg = 2,93 ns/op (σ = 0,00 ns/op) [ 2,93]

Measure:

        1 threads, Tavg =      2,93 ns/op (σ =   0,00 ns/op) [     2,93]
        2 threads, Tavg =      3,25 ns/op (σ =   0,01 ns/op) [

3,24, 3,26] #

java.util.logging enabled

#-------------------------------------------------------------

isLoggableFinest: run duration: 5 000 ms

Warm up:

1 threads, Tavg = 3,24 ns/op (σ = 0,00 ns/op) [ 3,24]

1 threads, Tavg = 3,24 ns/op (σ = 0,00 ns/op) [ 3,24]

Measure:

        1 threads, Tavg =      3,23 ns/op (σ =   0,00 ns/op) [     3,23]
        2 threads, Tavg =      3,64 ns/op (σ =   0,06 ns/op) [

3,58, 3,70] # #-------------------------------------------------------------

END.

############################################################## BUILD SUCCESSFUL (total time: 40 seconds)

Mandy, could you submit your changeset to the mercurial repository ?

Do you plan to apply the fix on JDK7 updates ?

Regards, Laurent

2013/3/28 Peter Levart <peter.levart at gmail.com>

On 03/28/2013 10:19 AM, Laurent Bourgès wrote:

the following method in JavaLoggerProxy also caught my eye:

void doLog(Level level, String msg, Object... params) { if (!isLoggable(level)) { return; } // only pass String objects to the j.u.l.Logger which may // be created by untrusted code int len = (params != null) ? params.length : 0; Object[] sparams = new String[len]; for (int i = 0; i < len; i++) { sparams [i] = String.valueOf(params[i]); } LoggingSupport.log(javaLogger, level.javaLevel, msg, sparams); } I think this could be improved if the DefaultLoggerProxy.formatMessage() is used instead of turning each parameter into a String. The method could be moved up to abstract LoggerProxy and used in both implementations so that common formatting is applied regardless of back-end used.

Let's do this in a separate clean up as it's better to keep 8010309 focus on performance improvement (although we have mixed this bag with some renaming). I disagree Peter: JUL has its own formatting code: patterns ... and more efficient than DefaultLoggerProxy.formatMessage(). The good question relies in the comment: why convert object args into String early as JUL can do formatting / conversion? What does mean: // only pass String objects to the j.u.l.Logger which may // be created by untrusted code ? to avoid security issues ? I think so. j.u.logging has a pluggable API and a reference to a security-sensitive information could get passed to untrusted code via a carelessly written logging statement. The fact that PlatformLogger is platform-internal API might give an impression that it is secure. So it should be. I don't know how this formatting actually works in current implementation of PlatformLogger delegating to j.u.l.Logger and pre-converting the arguments into strings. Isn't formatting in j.u.logging type sensitive? Regards, Peter Laurent

More information about the core-libs-dev mailing list