Stefan Marr

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 JavaScript

Oct 30, 2022: Reducing Memory Footprint by Minimizing Hidden Class Graphs

Tomoharu noticed in his work on the eJSVM, a JavaScript virtual machine for embedded systems, that quite a bit of memory is needed for the data that helps us to represent JavaScript objects efficiently. So, we started to look into how the memory use could be reduced without sacrificing performance.
Oct 22, 2016: Language Research with Truffle at the SPLASH'16 Conference

Next weekend starts one of the major conferences of the programming languages research community. The conference hosts many events including our Meta’16 workshop on Metaprogramming, SPLASH-I with research and industry talks, the Dynamic Languages Symposium, and the OOPSLA research track.
Apr 8, 2016: Adding Debugging Support to a Truffle Language

Beside the great performance after just-in-time compilation, the Truffle Language implementation framework provides a few other highly interesting features to language implementers. One of them is the instrumentation framework, which includes a REPL, profiler, and debugger.
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.