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

[Thomas Stüfe]

Hi all,

This is a retry - I posted the original RFR in March but got no reaction so
far.

Bug: https://bugs.openjdk.java.net/browse/JDK-8220762
cr:
http://cr.openjdk.java.net/~stuefe/webrevs/8220762--rewrite-eventlog-system/webrev.00/webrev/

The Eventlog system keeps an array of events which almost completely
consist of variable sized string messages.

The message buffer consists of fixed-sized records with a fixed-sized char
array for those messages. This is not a good fit. Mostly, those buffers are
too large and we waste space. Then, occasionally a message text is too
large and we truncate. To avoid truncation, stopgap solutions have been
added in the past (e.g. JDK-8204551) which would just increase the array
size, therefore avoiding truncation (for now) but increasing memory waste.

A better solution would be to hold the strings in var-length buffers. We do
not want strdup since that is too expensive and events may be written in
situations where C heap is flaky.

So we developed a solution where the strings live outside the event records
in a FIFO buffer of variable length strings - each string just uses exactly
as much memory as needed, and truncation is not a problem anymore. This
allows us also to increase the number of event records held.

In addition, we added an explicit jcmd to display events (VM.events) -
right now the only way to display events is via hs-err file or VM.info,
which is really cumbersome. The command has a number of options, e.g. it
allows to filter for one log only or to show entries in reverse order.

Example output of VM.events:
http://cr.openjdk.java.net/~stuefe/webrevs/8220762--rewrite-eventlog-system/vm.events-example-output.txt

------

Note that this is not a simple addition, but a rewrite (not a very big one,
the event log system is not huge). The coding complexity is simplified by
this patch which I think makes it more maintainable. I did this by
abandoning the templatized event record idea in favor of a simple record
structure. The old solution allowed event logs to define their own record
structure, but in practice this was a feature almost never used. So IMHO it
makes sense to un-templatize this and reap the benefits of much simpler
coding.

If you guys think this is not a worthwhile contribution I'll stop hawking
it. But I think it makes sense.

jdk-submit tests went through, and I saw no issues in our nightlies.

Thanks & Best Regards, Thomas

(Not sure which mailing lists this would go to - obviously hs-runtime, but
gc log and compiler log are affected too - feel free to redirect)