This is a public service announcement: DON’T FORGET TO RENEW YOUR DOMAINS IN TIME! Thanks to Brian for getting classpath.org back online.

The 2006 OLS paper Perfmon2: A flexible performance monitoring interface for Linux by Stéphane Eranian gives an overview of designing a generic interface for hardware monitoring for a diverse test of processors. Modern processors have all kinds of support to collect information about cpu cycles used, instruction pipelines, on-chip caches, etc.

Since the Performance Monitoring Unit (PMU) on different processor architectures are so different and support collecting very different sets of events designing a generic interface is pretty hard. But it looks like perfmon2 does present a nice, although somewhat complex, common interface to program the Performance Monitoring Configuration (PMC) registers and read the data collected in the Performance Monitoring Data (PMD) registers. And it provides a somewhat nicer way to program and collect data than having to go through the raw hardware. It provides things like generic 64-bit counters for events (and in gneeral makes sure that all data structures use fixed-size data types), even if the underlying hardware has smaller counters (doing emulation in software when the hardware counters overflow). And most importantly makes it available to user space in a secure manner, so one doesn’t need direct hardware access in privileged mode and prevents “data leaks” between untrusted processes.

The interface allows for both counting and profiling (sampling) events on a per-thread or per-cpu basis. But whole-process or whole-system profilling is left up to the user (through ptrace attaching a thread and tracking clone events, although exec events do automatically carry over monitoring contexts. Maybe a utrace based framework would make things simpler here, but currently it seems the perfmon2 and utrace patches don’t mix). The paper is somewhat vague on how and when one can use a mixed per-thread and per-cpu environment, which is somewhat unfortunate since it looks like if an admin is using per-cpu monitoring a self-monitoring process cannot simultaneously use the MPD counters. Self-monitoring is interesting since it means a dynamic runtime environment like hotspot that dynamically regenerates code can easily see “hot code paths”. One limitation seems to be that threads using this technique need to be tied to one processor since the monitoring context cannot migrate between CPUs.

The paper gives a good overview of the various techniques used to detect and access the various events supported by the CPU and expose the counters through new system calls, translation files in /sys/kernel from logical registers to actual register names and mapping in read only shared buffers between kernel and user space for self-monitoring threads. The event sets and multiplexing of events is interesting but very abstract. The paper doesn’t contain any code samples and one is assumed to know the kind of performance event counters modern CPUs support. Things become a little easier if one reads this paper while having access to a system with pfmon tool (and the perfmon2 kernel patch) installed or reading the pfmon manual to look at examples to make things a bit more concrete.

From Lillian on the OpenJDK distro-pkg-dev mailinglist about IcedTea 1.1

We are proud to announce the release of IcedTea 1.1. This release represents the stabilization of Crypto and SSL support.

The IcedTea project provides a harness to build the source code from OpenJDK (http://openjdk.java.net) using Free Software build tools and provides replacements libraries for the binary plugs with code from the GNU Classpath project. More information on IcedTea can be found here: http://icedtea.classpath.org

What’s new?

• GNU Crypto security providers have been merged from GNU Classpath.
• SSL support by means of the IcedTls security provider.
• DebugInfo is always generated.
• Initial graphics work: Color management and raster fixes for compatibility with LittleCMS, and work to satisfy libt2k requirements with Freetype.
• Uses OpenJDK build 15.
• Various bug fixes: http://icedtea.classpath.org/bugzilla/

The tarball and nosrc RPM can be downloaded here: http://icedtea.classpath.org/download/

The following people helped with this release:
Gary Benson, Thomas Fitzsimmons, Kyle Galloway, Andrew Haley, Francis Kung, Casey Marshall, Mark Wielaard and Lillian Angel.

We would also like to thank the bug reporters and testers!

Nice work!

Arnaldo Carvalho de Melo wrote an interesting paper for OLS: The 7 dwarves: debugging information beyond gdb. Dwarves is a DWARF debugging information library and a set of tools that uses the DWARF information inserted in ELF binaries. The tools can help you understand DWARF and the debug information available in programs (and the kernel) to do such fun things as finding holes in data structures, cacheline alignment, pack those structures (it can actually decode the debug info and generate C source code for you and explain why and how it moved the fields around) and it can analyse inline decissions made by the compiler and tell you what functions got inlined by the compiler and which were marked for inlining by the programmer. You can also get something like japitools for C/C++ with the codiff utility that inspects data structures and function changes between different versions of a binary. One interesting thing is ctracer that can use the information on structs and functions to automatically track changes in those datastructures when it moves through the code. Currently this only works for the kernel and uses raw kprobes to collect statistics. But one idea is to extend this to automatically generate systemtap scripts to gain all the safety guards that systemtap provides for statistics collection of a running kernel and with uprobes coming it will then extend to user space also.

Another nice paper about DWARF is Introduction to the DWARF Debugging Format, by Michael Eager