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

Baesken, Matthias matthias.baesken at sap.com
Mon May 20 12:02:49 UTC 2019


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.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Hello  ,  I like the added jcmd  command !   Would be great to have it, I thought about why it is not there  just  last week !

Additionally,   I  like  the space  reduction,  especially   because I want to add a couple  more  even  log calls   in the future .






(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)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------





I think it would be good to add hotspot-dev .





Best regards, Matthias











More information about the hotspot-runtime-dev mailing list