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

[Thomas Stüfe]

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