RFR(m): 8220762: Rework EventLog message string handling and provide VM.events command

[Thomas Stüfe]

Polite Ping...

All submit tests passed.

..Thomas

On Sun, Mar 17, 2019 at 9:26 AM Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

> Dear all,
>
> may I please have thoughts and reviews for this medium-ish change:
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8220762
> CR:
> http://cr.openjdk.java.net/~stuefe/webrevs/8220762--rewrite-eventlog-system-to-reduce-footprint-and-to-not-truncate-output/webrev.00/webrev/
>
> The Eventlog system keeps records which mostly consist of string messages.
> These records are fixed-sized which is not such a good fit for an event
> system.
>
> When writing the occasional large message, we get truncations when hitting
> the max string size. In the past, the solution to that had been increasing
> the buffer size (see https://bugs.openjdk.java.net/browse/JDK-8204551),
> but that is a bit unsatisfying since we waste much of that memory for
> records whose messages are usually shorter.
>
> This patch changes the event log system and replaces the fixed-length
> string array with a var-length fifo buffer for strings. The advantage is
> that we use exactly as much space as we need for that particular message -
> short messages won't waste a whole fixed-length record text - while
> avoiding truncation on long messages.
>
> This is done by introducing a new var-length string fifo buffer. An event
> log record now just holds a reference to a string in this buffer; so an
> EventLog now consists of two Fifos: the traditional EventLogRecord-Fifo and
> an associated variable-length-string-Fifo.
>
> --
>
> I also took the liberty to cleanup and simplify the coding a bit:
>
> The old EventLog system made it possible to define ones own event log
> records, being templatized. However, that feature was - with one tiny
> exception - never used. Almost all child classes of EventLog just use the
> EventLog system in its pure form : a record consisting of [timestamp,
> thread info, message text].
>
> This also makes sense since a lot of the information we write to the log
> is volatile - it exists when we log but may not exist anymore when we print
> the log - and if one were to store it in the record, one would have to take
> care to keep it alive somehow or copy it. In practice, it is usually too
> much hassle with low benefits, so it has been easier to just printf() those
> information to the record right away and be done with it.
>
> The only exception from this was the GC event log, which kept a boolean
> flag in the event log message designating whether that record was logged
> "before" or "after" a GC. But since the sole purpose of this flag was to
> print "before" or "after" at the printing point, it could have done so
> right away when logging.
>
> So I decided to scratch the templatization here and go with a much simpler
> system, which is easier to read and maintain. What do you think?
>
> --
>
> Finally, I added a new diagnostic command to jcmd, called "VM.events", to
> print out the event log. Before, we could only get this via VM.info; I
> think it is worth a separate command, especially since this does not add
> much code.
>
>
>
> Cheers, Thomas
>
>