RFR: 8146793: logStream::write re-formats string

John Rose john.r.rose at oracle.com
Tue Jan 19 23:55:36 UTC 2016


On Jan 12, 2016, at 7:25 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> Please review this fix to some problems in logStream::write and the
> facilities used to implement it.
> 
> 1. logStream::write no longer attempt to reformat the already
> formatted accumulated output.  [Fixing this led to the discovery of
> the issues below.]
> 
> 2. Fixed Log<>::vwrite test for overflow of the initial buffer, which
> didn't allow for the trailing NUL.
> 
> 3. Fixed Log<>::vwrite to copy the va_list arguments before first
> format attempt and use that copy if a second format attempt is
> needed, rather than incorrectly reusing the original (now possibly
> modified) va_list.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8146793
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8146793/webrev.00/
> 
> Testing:
> JPRT
> Locally verified printing a "%" to a log stream works, by running
> TestPrintGCDetailsVerbose (after fixing it for JDK-8146728).

The previous logging facility includes, at the corresponding cut point,
optimizations for no-% and %s-only format strings, to avoid trips
through the sprintf engine and needless copying.  Please see:

http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/share/vm/utilities/ostream.cpp#l90 <http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/share/vm/utilities/ostream.cpp#l90>

In other words, let's not do the buffer-buffer rhumba if we don't need to.

This is an excellent moment to incorporate those optimizations
in the new logging system.

Nice catches on the va_copy and buffer overrun.  How did you find
the log_func(foo) instead of log_func("%s", foo)?  Please tell me it
was a gcc warning; if not then we have some software rot going on.

Reviewed.

— John


More information about the hotspot-dev mailing list