LTTng-UST bytecode interpreter

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

Hi Alexei,

Following our Plumbers discussion, here are links to
lttng-ust and lttng-tools parts that are relevant to
the bytecode I use for tracepoint filtering:

http://git.lttng.org/?p=lttng-tools.git;a=summary
src/lib/lttng-ctl/filter/*.[ch]
  -> parser of filter expressions to AST, then to
     intermediate representation, followed by
     bytecode generation.

The bytecode is then moved from the client to the
application being traced through the lttng-sessiond
daemon.

http://git.lttng.org/?p=lttng-ust.git;a=summary
liblttng-ust/lttng-filter.c:
  filter "linker" attaching bytecode to tracepoint.
  _lttng_filter_event_link_bytecode() has all the
  steps required to translate a bytecode into
  something the interpreter can use.

liblttng-ust/lttng-filter-specialize.c:
  Perform type specialization of some opcodes. This
  is done after linking to an event fields, now that
  we know their type.

liblttng-ust/lttng-filter-validator.c
  Validation of the bytecode: making sure typing is
  consistent, checks there are no loops (no backward
  jump).

liblttng-ust/lttng-filter-interpreter.c
  Bytecode interpreter, executes quickly without any
  checks, relying on the fact that they were already
  performed by the validator. It is a threaded
  interpreter which has 2 registers aliasing the top
  of its stack.

My general approach is to use an interpreter to deal
with the general case, which makes porting to new
architectures easy. We can then have JIT phases if
we want to eventually translate this bytecode into
native instruction.

Working with a bytecode which has a slightly higher
level semantic allows dealing with strings as a basic
type in addition to integers and floating point values.

Please note that the current bytecode is limited to
64-bit integers. We can eventually extend it to be
more compact (8, 16, 32-bit integers).

Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com