More tutorial notes
Realtime Programming on the Java Platform
This was an information-dense walkthrough of the realtime spec and how to use realtime implementations. The realtime spec makes no changes to the language as such, however it does require a special version of the runtime and the underlying OS and hardware must also support realtime. Typically, an application will get roughly a 30% reduction in throughput when it is ported to realtime.
For real-world applications, it's infeasible to provide cast-iron real-time guarantees. However, for applications that justify it, a system can be written (with a lot of effort) that meets realtime goals (which will typically firm bounds on things like response times) with high probability.
A lot of the effort goes into ensuring that non-realtime threads and garbage collection do not interfere with realtime threads. At the highest level, you can define realtime threads that are not allowed to read from the Java heap at all (any attempt causes a runtime exception). These threads are only allowed to use specially defined storage that is allocated before they run and is effectively immortal (and immune from garbage collection). The API for defining special memory contexts as specified is more over-elaborate.
The Sun realtime Java product offers realtime garbage collection. This works by running GC as a realtime thread and ensuring that the GC operation never needs to move objects. Thus the GC can be pre-empted at any time by a higher-priority thread with no corruption of heap state.
Of note: apparently financial companies think they care about "soft" realtime until they understand they need to pay a penalty in throughput. When they do, they nearly always decide they'll accept rare high latency in exchange for constantly high throughput.
Erlang / OTP
Really, OTP is an important part of the Erlang story. Despite the name, OTP has little to do with telephony and everything to do with abstracting common usage scenarios. There's a common pattern whereby the OTP module (e.g. genserver, genfsm) controls the lifecycle, and the application code is implemented in callback functions that are called appropriately. Thus, OTP can take care of setup and (particularly important) error handling. The OTP philosophy for handling errors is to kill the offending process. A supervisor process is then responsible for handling the crash, often by restarting the process (in a known good state). Application design is largely about designing trees of supervisor and so-called worker processes.
This was about the problem of choosing combinations of input parameters (considered abstractly, so they could include things like machine state, OS version, etc.) Full coverage of all combinations is infeasible, but you want to cover some combinations. Covering all combinations of all pairs turns out to be good enough in practice much of the time. Surprisingly, choosing even these is not a solved problem. Various tools exist that come up with reasonable but often varying results. The presenter's favourites were PICT and (as honorable mention) Jenny. For all the tools, the results they generate are pretty basic and some effort is required to use them to generate actual test data.