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
>
>
>
