This week marks the finalization (for now) of the CTF parser API, and the performance results of the State History using CTF traces as input. *BIG* CTF traces. Chart lovers rejoice! Once again, I will split this week's update in two parts since it's quite lenghty. This first part will talk about the parser's API, the second about the test results.
While I thought the Java CTF parser... okay this is getting tedious, we need to come up with a name for this "Java CTF parser library". JBabeltrace? Any suggestion? Anyway...
While I thought the "Jabbeltrace" API I've been working on for the past week was now complete, it turns out I was not completely right. LTTng 2.0 traces do contain event fields other than CTF integers and strings. Namely Arrays and Sequences of integers.
For example, the "comm" names for processes are represented by Arrays of 1-byte integers, encoded in UTF-8. Since comm names in the kernel are truncated to 16 characters anyway, it's more efficient to store them this way rather than variable-size strings. And since I use process names in state changes, it was desirable to have such support.
So I added support for the "CTFIntegerArrayField" type. Note that in CTF, you can have Arrays of pretty much anything. This new field type can only handle Arrays of *integers*. Adding separate field types would be required to support other types of arrays (and since we want to export to native Java types, generics don't really help). However, LTTng 2.0 only uses Arrays of integers at the moment, so this support should be sufficient. For now. I hope.
Once this was done, the only field type present in LTTng 2.0 traces but not supported by the parser were Sequences of integers. It is seldomly used, in the block_rq family of events, which come from tracepoints in the block layer.
For the sake of completion I went on to add support for this too, which was relatively simple : it would export to either a string (if the bytes were encoded in UTF-8) or a long array, exactly like IntegerArray fields.
I had some fun debugging those Sequences however. I thought I had done something wrong, until I realised Babeltrace (the real one) was also having problems parsing Sequence fields. After some talks with upstream about it, and several git commits later, LTTng would now export those fields as Sequences of 64-bit integers, which Babeltrace would print as hex strings (like "0xA1").
For the sake of simplicity, in Jabbaltrace I import them into straight long's. If a Java trace analysis client using block layer events(!) ever has problems because of this, ring me up.
That's it, we now support every type of event field currently used in LTTng 2.0! (Un)fortunately, extended system call tracing is coming up, so this might not stay true for long...
Additionally, this API work did get merged upstream. Thank you Matthew! I think we could set up a proper repo on git.dorsal.polymtl.ca soon. Of course this is getting integrated into TMF, but we've made sure so far that is stays quite generic, so that it can be used in other projects too.