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

[Yasumasa Suenaga]

Hi Thomas,

Thank you for handling this issue.
I have some comments to your change.


   - StringFifoBuffer::wrap() seems not to be used.
     Can you remove it?

   - We will see "Command executed successfully" on console when we run VM.events
     dcmd with unexpected log name (e.g. jcmd <PID> VM.events name=aaa).
     Can you show some error message?
     (It relates to JDK-8165869)

   - Can you add jtreg test(s) for VM.events?


Thanks,

Yasumasa


On 2019/03/26 1:39, Thomas Stüfe wrote:
> 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
>>
>>