options: ======== want verbose spmt option use libconfig migrate all options from sablespmt to libconfig make options pointer a static global possibly want module-specific options generate libspmt options code in sablevm/tr if repetitive build system: ============= ignore generated files in subversion make indent make svnclean [0.0.1] * Make a library with hello() plus a simple main() to call it. automatic header file generation -- makeheaders.c? buildbot cruisecontrol xrefactory [0.0.1] * pkg-config [0.0.1] * find good debugging, profiling, optimization, and cpp flag sets. [0.0.1] * move repeated main() into tests/main.c and tests/all.h into tests/main.h -mtune=opteron (magic), -mtune=pentium4 (string), -mcpu=970 (ibook) strip [0.0.1] * Stop -g -O2 from getting set in CFLAGS... use svn:keywords for all files, without changing the files if possible test all possible libspmt configurations automatically system testing: =============== autotest dejagnu look at libtool test framework look at m4 test framework diapergluforth for shared objects splint keep sablespmt working with libspmt set up automatic testing system with sablespmt and libspmt unit testing ============ [0.0.1] * Check gcov CppUnit CUT CUTest autounit malloc debugging: ================= efence valgrind dmalloc -- AM_WITH_DMALLOC mprof mpatrol portability: ============ [0.0.1] * __i386__ [0.0.1] * __x86_64__ [0.0.1] * __POWERPC__ Other systems: http://www.testdrive.hp.com/ http://sourceforge.net/docs/E02/ documentation: ============== doxygen docbook boostbook (doxygen-->docbook converter) texinfo help2man libraries: ========== libhoard -- fast MT malloc replacement refactoring =========== use enums per indian hill switch to block comments per indian hill performance testing =================== want some kind of interface for performance testing. find a way to fit data points to a curve. maybe want a more accurate timer with CPUID for tests. could execute benchmark function many times in a loop. maybe want to keep cycle counts / performance numbers... valgrind + kcachegrind oprofile + prospect linux trace toolkit (LTT) gprof system design ============= allow for init as well as create methods so that objects can be inlined. performance: use restrict keyword for efficiency papers ====== 1) Library, multiple client VMs. (submitted to VEE'07) 2) Speedup. Effect of multiple children, or nested speculation. Elimination of overhead by methods other than not incurring overhead (measure this using a fork always setting). 3) Compiler optimizations for SpMT. JIT-specific optimizations, such as code specialization. sources of overhead =================== speculative code executes slower than regular code -- buffer calls -- safety checks -- buffering stack frames -- async checks child joins -- signalling and waiting -- buffer verification -- predictor updates adaptive predictors =================== hypothesis: for a given callsite, there is statically a best predictor -- try to choose this predictor adaptively new speculation modes ===================== -- loop-based speculation might actually be possible using the current design -- lock-based speculation, possibly following the design in welc-06-revocation