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

[Thomas Stüfe]

Thank you Dean.

I can easily remove the jcmd  addition from the patch and do it later, but
that would not really remove much since it is tiny.

Splitting the var sized part from the code simplification will be more
complicated. I have to think this through.

Let’s first see if there is any interest in this improvement.

Cheers, thomas


On Fri 17. May 2019 at 22:00, <dean.long at oracle.com> wrote:

> Hi Thomas.  Have you considered breaking this up into three parts:
> variable-sized, jmd, and removing templates?  It seems like they can all
> be done independently.
>
> dl
>
>
> On 5/17/19 9:44 AM, Thomas Stüfe wrote:
> > 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)
>
>