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 <clinit> ############################################################## 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.lev...@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 > > >