Stefan Marr

Associate Professor (Senior Lecturer)
and Royal Society Industry Fellow

Stefan Marr I am working at the School of Computing at the University of Kent. My work focuses on programming language implementation techniques, complex concurrent systems, and tooling.

Much of work revolves around making interpreters faster, detecting and preventing concurrency bugs at run time, and use modern language runtime systems to provide programmers with better tooling.

For contact details see my page at the School of Computing.

Archive of posts with the tag just-in-time

Oct 23, 2015: JIT Data Structures, Fully Reflective VMs, and Meta-Circular Meta-Tracing

The year leading up to SPLASH has been pretty busy. Beside my own talks on Tracing vs. Partial Evaluation and Optimizing Communicating Event-Loop Languages with Truffle, there are going to be three other presentations on work I was involved in.
Nov 19, 2014: SOM Performance Numbers

Today, I got a few more benchmarks running to get a better idea of where RTruffleSOM and TruffleSOM stand in terms of their absolute performance.
Sep 22, 2014: Are We There Yet? Simple Language-Implementation Techniques for the 21st Century

The first results of my experiments with self-optimizing interpreters was finally published in IEEE Software. It is a brief and very high-level comparison of the Truffle approach with a classic bytecode-based interpreter on top of RPython. If you aren’t familiar with either of these approaches, the article is hopefully a good starting point. The experiments described in it use SOM, a simple Smalltalk.
Nov 2, 2011: OOSPLA 2011 @SPLASH2011, Day 3

The third day started with Brendan Eich’s keynote on JavaScript’s world domination plan. It was a very technical keynote, not very typical I suppose. And he was rushing through his slides with an enormous speed. Good that I have some JavaScript background. Aside all the small things he mentioned, interesting for me is that he seemed to be very interested to get Intel’s RiverTrail approach to data-parallelism into ECMAScript in one or another form. That is kind of contradicting the position I heard so far, that ECMAScript would be done with having WebWorkers as a model for concurrency and parallel programming.