RFR: 8138916: Logging write function does not allow for long enough messages (original) (raw)

Mikael Gerdin mikael.gerdin at oracle.com
Tue Oct 27 12:57:05 UTC 2015

On 2015-10-27 12:52, Dmitry Samersoff wrote:

Rachel,

In worst case (windows, overflow) the code would parse format string four times. Also NEWCHEAPARRAY takes a lock and might become a performance bottleneck.

NEW_C_HEAP_ARRAY does not take any VM lock but is dependent on the libc ::malloc function. If your libc only provides a ::malloc which takes a lock on every allocation then you should switch OS (or use libumem on Solaris). /Mikael

POSIX equivalent of vscprintf(fmt, args) is vsnprintf(NULL, 0, fmt, args) So it might be better to create os::logvcprintf(fmt, args), then write code at log.hpp as: int buflen = os::logvcprintf(fmt, args); assert(buflen < 2*pagesize, "Stack overflow in logging"); char buf[buflen]; vsprintf(buf, fmt, args); -Dmitry

On 2015-10-26 23:58, Rachel Protacio wrote: Hello, all, Please review this fix to the faulty write function from the Unified Logging framework. Summary: In logging/log.hpp, the logging vwrite function previously asserted that the buffer remains within 512 characters, which is too short for logging message of non-pre-determined length, e.g. for vtable and itable function names. Now, the function resizes the buffer to the appropriate length, asserting only that the resulting buffer is valid. Includes tag "logtest" to test that logging can print an output of 518 characters. Open webrev: http://cr.openjdk.java.net/~rprotacio/8138916/ Bug: https://bugs.openjdk.java.net/browse/JDK-8138916 Includes own acceptance test, and passes JPRT and remote hotspot/test tests. Thank you, Rachel

More information about the hotspot-runtime-dev mailing list