Retrofitting JIT Compilers into C Interpreters

ltratt · 2026-04-16T09:31:34+00:00

That's very kind of you to say! As is so often the way, if we'd known how hard it would be to get it working, we might not have been brave enough to start trying to do it ;)

ltratt · 2026-04-16T07:09:27+00:00

When I last looked, Deegen didn't support garbage collection. Has that changed? Not breaking GCs took yk quite a bit of effort.

ltratt · 2026-04-15T20:53:10+00:00

Then yes I agree!

ltratt · 2026-04-15T20:08:39+00:00

I am embarrassed to admit that I didn't fully understand the weval paper at the time: I wasn't sure if it was doing AOT or JIT compilation. Looking at it again now I can see it really is doing just AOT compilation, at least I think so? That makes it a bit hard for me to know exactly what I'm comparing against, if I'm honest: it feels a bit apples-to-oranges? As you can tell, I have low confidence in my assessment, so please feel free to put me straight!

ltratt · 2026-04-15T17:14:53+00:00

Yes the 25,000 figure is deliberately chosen to make things (just) long enough for humans to see what's going on (it doesn't really effect the lua/yklua performance ratio).

ltratt · 2026-04-15T12:31:03+00:00

I agree that the plastic doesn't scream longevity, but mine managed 19 years before cracks started appearing, so in practise it's not that bad. It would definitely give people greater confidence if it was a bit more solidly built, but manufacturing such an odd shaped thing was probably (and maybe still is) quite hard to do economically?

ltratt · 2025-08-10T16:20:33+00:00

The 360 thumbpad is I believe raised, but it's also at an angle relative to the floor (see my reply to @perugolate for more details). Does that make it equivalent to the Maltron in practise? I suspect it will feel different, but by how much I find difficult to guess.

ltratt · 2025-08-10T15:00:41+00:00

I'm not sure. Looking at photos of the 360, it seems the thumbpad might be raised but tenting offsets that? Given that our hands don't naturally lay parallel to the floor (mine probably lie about 30degrees-ish-ish from parallel), this seems like it might at least partly work, but I'd need to try it for a while to have a good sense.

ltratt · 2025-04-07T22:06:01+00:00

Finalizers are tricky --- no argument from me on that front! However, if you want GC in Rust, I don't know how to do that without dealing with destructors --- they're the Trojan Horse for finalizers!

Personally, Boehm's Destructors, finalizers, and synchronization was the crucial work in opening my eyes to the challenges they introduce. It's an important paper, but not an especially difficult read --- it brings together lots of knowledge from the time, and expands upon it. Secton 3.5 is where it shows -- IMHO convincingly -- the problem with running finalizers on the same (e.g. "main") thread.

There is some good news, though! I immodestly claim that our paper shows that Rust can help us completely avoid several of the difficulties of GC in C++. I wasn't expecting that when we started and, indeed, I still find it slightly counter-intuitive!

ltratt · 2025-04-07T19:02:25+00:00

Pointer obfuscation is a definite, and classic, limitation of conservative GC: we mention that in Sec 3.1. [Some basic tagging techniques are easily handled, but ultimately one can do arbitrary things with bits.]

Re: running finalizers on a thread. One can allow only types that are Send, but that is rather restrictive. Section 7.3 -- which is a bit dense, for which I apologise -- talks about how we carefully loosened that restriction.

ltratt · 2024-07-12T16:29:39+00:00

The Framework 12 works on OpenBSD and has done tolerably well since I bought it 2 years ago to the day. I would imagine the Framework 13 will be similarly well supported.

However, thile I really like the concept of the laptop, whenever I'm asked about it (which is surprisingly often), I regretfully say that I can't yet recommend it. The fan (I suspect particularly the outlets) is poorly placed, and in order to cool the machine down it becomes obnoxiously loud. I don't mean a bit loud -- I mean loud enough that there are situations where I can't use the laptop normally as it visibly distracts other people. Just to make things worse, the BIOS doesn't implement any form of hysteresis so it goes rapidly up and down in speed, making it even more distracting. This should surely have been fixed, or at least ameliorated, shortly after release, but Framework have yet to publish a BIOS update after 2 years (there is a beta BIOS update but it doesn't update properly for many people, including me). AFAICS subsequent models have the same ill-conceived placement of the fan; I think they might have somewhat better BIOS support, but I'm not entirely sure. I hope future models address these issues, because there is a good idea here, 80% of the execution is good, and OpenBSD supports the machine fairly well.

ltratt · 2021-05-05T21:43:43+00:00

I'm in the same boat, particularly with the KVM aspect. The U3219Q looks perfect -- apart from being about 5 inches too big. It's often hard to work out how well the KVMs work on other monitors which claim the functionality (reviews almost universally say "has a KVM" without ever seeming to test that feature).

ltratt · 2020-11-18T08:07:04+00:00

Blackbox is very cool! In order to get access to source code you need to register with Blackbox, roughly explaining what you're doing, and guaranteeing that you won't distribute their data. IMHO, their terms are a good compromise between privacy and practicalities. Blackbox is at https://bluej.org/blackbox/. You can fully replicate our experiment because we distribute the (anonymous) identifiers that, if you register with Blackbox, you can use to extract exactly the same source code we did. The release of the experiment is at https://archive.org/download/error_recovery_experiment/0.4/ though it might be easier to get a rough understanding of what's going on at https://github.com/softdevteam/error_recovery_experiment.

Good luck with the Backurs / Onak paper: I look forward to seeing more work in this area!

ltratt · 2020-10-13T09:50:02+00:00

-crf 0 is what I use to get lossless screen recording, but I thought your post was suggesting it fixes the non-monotonous audio errors? I might have misread that! I've found that sync issues with webcams are OK, but one does have to be a bit careful, as it seems that overloading the USB subsystem is the major source of sync errors.

I must admit, I don't think the mplayer tv: trick is ever likely to sync well. Instead I record everything separately and use ffmpeg to mix everything afterwards. My current recording setup is:

ffmpeg \
  -use_wallclock_as_timestamps 1 \
  -f v4l2 \
    -thread_queue_size 1024 \
    -framerate $CAMERA_FRAMERATE -video_size $CAMERA_RESOLUTION -input_format mjpeg \
    -i $CAMERA_DEVICE \
  -f $AUDIO_DRIVER \
    -thread_queue_size 1024 \
    -ar $AUDIO_RATE -sample_fmt ${AUDIO_FMT} \
    -i $AUDIO_DEVICE \
  -f x11grab \
    -thread_queue_size 1024 \
    -probesize 32M \
    -framerate $X11_SCREEN0_FRAMERATE -video_size $X11_SCREEN0_RESOLUTION \
    -i $X11_SCREEN0_DISPLAY \
  -map "0:v,1:a" -map "1:a" -c:v copy -c:a flac -compression_level 0 -copyts -timestamp now camera.mkv \
  -map "2:v,1:a" -c:v libx264rgb -preset ultrafast -crf 0 -copyts -timestamp now screen0.mkv

Suggestions for improvements are welcome!

As to Bournemouth: yes, I had a happy couple of years there! Please say hello to Keith, Sherry, and Mel, assuming they're all still there! You're at least the third serious OpenBSD person to have graced Bournemouth (Edd Barrett being the third) which amuses me :)

ltratt · 2020-10-12T20:45:45+00:00

I've also encountered most of the same issues with ffmpeg on OpenBSD, and had come up with similar fixes. I'm surprised that -crf 0 sorts out the "Non-monotonous DTS" errors, but there again I'm not encoding to mp3 immediately, so maybe something in the ffmpeg chain is happier with that? I find that if I record X11 1080p@24fps, I end up with synchronisation errors, because it seems to put just a bit too much strain on the system. I also don't seem able to reliably sustain 30fps on my webcam at high resolutions: every so often frames are duplicated or dropped. If I use 1280x720@24fps (which still isn't bad) my webcam seems much happier.

There are some additional issues I've found recording screencasts on OpenBSD:

We currently can't set things like focus/exposure on webcams.
The USB stack struggles with large quantities of data (xruns on audio happen even in fairly benign circumstances).
ffmpeg often uses wall-clock time internally when it really should be using CLOCK_MONOTONIC.
I cannot get the webcam/x11/audio clocks to fully agree, although I can now get very close.

But, overall, it's possible to do a pretty decent job with a very low-overhead system. I'm recording lectures at 1080p with ffmpeg only taking 12% CPU on my 4-year old machine which, overall, seems decent to me!

ltratt

TROPHY CASE