This week, I've been working mainly on finishing the CTF Input plugin for the State History library, which would make it possible to read CTF traces as input (via the shiny new Java CTF parser) and build a State History from these.

As I mentionned a couple weeks back, to main difficulty was to access event fields. For this, I ended up cooking an API for the CTF parser (which for now lives here, and is waiting to be merged upstream). With this we can now easily read content from CTFEvent's (including their fields) with basic Java types. Unfortunately it's not yet possible to access Event contexts, since the parser itself does not yet have support for it.


With this in hand, I was now able to rebase my CTF input plugin on this API. My initial plan was to add a wrapper to the CTFEvent which would allow it to be used just like a VSTFEvent in my kernel event handler. Turns out this was not so simple. Matching event types was not too hard to do, but then the fields wouldn't necessarily be the same between VSTF (which come from LTTng 0.x traces) and CTF/LTTng 2.0. For example, the field types could differ (long vs. int), their names or meaning, and finally the order would be completely different.

In LTTng 0.x, each event type had a specific order for its fields, which would get accessed as an array (getField(0), getField(1), and so on). With CTF, at least after going throught the parser, the fields would be stored in a HashMap, so converting them to an array wouldn't guarantee the relative ordering of the fields! So it did not make sense anymore to refer to fields by index.

This completely changed my vision of things: since it was not really possible for two input plugins to share event handlers, then why not include the event handler iself with the input plugin? Before, I would think of input plugins as "trace event inputs", which could then use a given event handler. But after thinking about it for a bit, it becomes obvious that Event handlers can't really be shared accross trace types. For example, a kernel CTF trace couldn't share the same event handlers as a UST CTF trace : even if the trace format is the same, the event types, names, and matching state changes would be completely different.

So this made me change the definition of State History input plugins, from "trace event input" to "state change input". In practice this did not affect the code much (simple move/renames). It might even allow simplifications in the future, notably dropping my ITraceEvent interface since now it does not matter where state changes come from.
Another new possibility is for a single input plugin to ship many alternative Event Handlers, depending on the types of analyses we want to run for example.


Next I will have to redo an Event Handler for the CTF kernel input, but I can simply adapt the existing VSTF Event handler. In parallel I've been taking very large CTF traces (up to 500 GB!) on an external hard drive. This means I will soon be able to confirm if the State History really scales well to *really* big trace sizes!