5 ms·

I am surprised so few interpreters are written in garbage collected languages, which would give the interpreted language a GC for free. The main interpreter loo

by ori_b 8y ago

I am surprised so few interpreters are written in garbage collected languages, which would give the interpreted language a GC for free. The main interpreter loop (or jitted code, for that matter) shouldn't allocate, so there is no inherent cost to the approach. And a tuned, mature GC is likely better than yet another MVP reimplementation.

masklinn 8y ago
> I am surprised so few interpreters are written in garbage collected languages, which would give the interpreted language a GC for free. 1. not exactly, you're now doubling your allocations as you're allocating a native object which has to create sub-structues representing the guest object, unless you're using the rpython technique of the interpreter being fed into a magical thing of magic which spits out a "native" runtime 2. the GC of the host language doesn't necessarily match what you want for the guest 3. and not being able to manipulate and interact with the GC can make efficiently implementing the guest difficult
- ori_b 8y ago
  > 1. not exactly, you're now doubling your allocations as you're allocating a native object which has to create sub-structues representing the guest object Those sub structures can live within the same allocation. And in many cases, the object passed to the interpreter can be the undecorated native object. > 2. the GC of the host language doesn't necessarily match what you want for the guest It's almost certainly better than recounting or naive mark and sweep, which is what you get when someone reimplements a GC for an interpreter.
RReverser 8y ago
Not sure if this was meant as a generic comment, or specifically about our engine, but our interpreter doesn't allocate at all during execution.
chrisseaton 8y ago
> would give the interpreted language a GC for free That's great if the language you're using has the same GC semantics as the language you're implementing, and a pretty major problem if it doesn't.
- ori_b 8y ago
  Yes, it would. What languages have materially different GC semantics, other than Python on the cpython vm? (PyPy loses the fast collection at the end of scope for efficiency reasons)
  - chrisseaton 8y ago
    Python is the key one you already mentioned - it has deterministic semantics and most other language do not. Ruby also exposes parts of its GC, and allows it to be hooked by C extensions, so when I implemented it on top of the JVM I had to basically reimplement half of it in Java in order to implement those parts of the language.
  - masklinn 8y ago
    Erlang's allocation pattern is markedly different than e.g. Java's, in no small part because it's completely impossible for an object to refer to a more recent allocation than itself. More generally, immutability-heavy language would have quite different needs than mutation-heavy ones.
  - ridiculous_fish 8y ago
    Finalizers and resurrection is a big way that GCs can differ. There's also exotic reference types: Java has WeakReference, SoftReference, PhantomReference...
  - naasking 8y ago
    > What languages have materially different GC semantics Others have mentioned a few, and I'll mention another: GC support for concurrency. Try writing a performant Go interpreter in OCaml, for instance.
  - 8y ago
skybrian 8y ago
For fun, I tried porting the Wren interpreter from C to Go and it was about 3x slower. There are a couple of issues: - Giant switch statements are not optimized as well as C. - In C you can do tricks like NaN encoding to create a union between floats and pointers. In Go, this doesn't work and you have to use an interface. There might be a garbage-collected language that lets you write efficient interpreters (perhaps Julia?) but I don't think you can take this for granted.
- jashmatthews 8y ago
  Java. JRuby is a great example of our performing a C based implementation.
  - skybrian 8y ago
    Very true, but that's also not a pure interpreter anymore. In languages that support eval() or generating and loading bytecode, it's leveraging the JIT compiler and effectively generating native code.
Matthias247 8y ago
It also comes at the the downside of removing some of the sandboxing abilities from that interpreter. Now the interpreted programs memory is the native programs memory, and the abilities to monitor and limit the interpreted programs memory might be decreased.
- deleted 8y ago
  [deleted]
stcredzero 8y ago
I am surprised so few interpreters are written in garbage collected languages, which would give the interpreted language a GC for free. There have been Smalltalk implementations written in other Smalltalk implementations which have used this approach. In those cases, the GC is very appropriate for the language implemented.

by ori_b 8y ago

masklinn 8y ago

> I am surprised so few interpreters are written in garbage collected languages, which would give the interpreted language a GC for free. 1. not exactly, you're now doubling your allocations as you're allocating a native object which has to create sub-structues representing the guest object, unless you're using the rpython technique of the interpreter being fed into a magical thing of magic which spits out a "native" runtime 2. the GC of the host language doesn't necessarily match what you want for the guest 3. and not being able to manipulate and interact with the GC can make efficiently implementing the guest difficult

ori_b 8y ago
> 1. not exactly, you're now doubling your allocations as you're allocating a native object which has to create sub-structues representing the guest object Those sub structures can live within the same allocation. And in many cases, the object passed to the interpreter can be the undecorated native object. > 2. the GC of the host language doesn't necessarily match what you want for the guest It's almost certainly better than recounting or naive mark and sweep, which is what you get when someone reimplements a GC for an interpreter.

RReverser 8y ago

Not sure if this was meant as a generic comment, or specifically about our engine, but our interpreter doesn't allocate at all during execution.

chrisseaton 8y ago

> would give the interpreted language a GC for free That's great if the language you're using has the same GC semantics as the language you're implementing, and a pretty major problem if it doesn't.

ori_b 8y ago
Yes, it would. What languages have materially different GC semantics, other than Python on the cpython vm? (PyPy loses the fast collection at the end of scope for efficiency reasons)
- chrisseaton 8y ago
  Python is the key one you already mentioned - it has deterministic semantics and most other language do not. Ruby also exposes parts of its GC, and allows it to be hooked by C extensions, so when I implemented it on top of the JVM I had to basically reimplement half of it in Java in order to implement those parts of the language.
- masklinn 8y ago
  Erlang's allocation pattern is markedly different than e.g. Java's, in no small part because it's completely impossible for an object to refer to a more recent allocation than itself. More generally, immutability-heavy language would have quite different needs than mutation-heavy ones.
- ridiculous_fish 8y ago
  Finalizers and resurrection is a big way that GCs can differ. There's also exotic reference types: Java has WeakReference, SoftReference, PhantomReference...
- naasking 8y ago
  > What languages have materially different GC semantics Others have mentioned a few, and I'll mention another: GC support for concurrency. Try writing a performant Go interpreter in OCaml, for instance.
- 8y ago

skybrian 8y ago

For fun, I tried porting the Wren interpreter from C to Go and it was about 3x slower. There are a couple of issues: - Giant switch statements are not optimized as well as C. - In C you can do tricks like NaN encoding to create a union between floats and pointers. In Go, this doesn't work and you have to use an interface. There might be a garbage-collected language that lets you write efficient interpreters (perhaps Julia?) but I don't think you can take this for granted.

jashmatthews 8y ago
Java. JRuby is a great example of our performing a C based implementation.
- skybrian 8y ago
  Very true, but that's also not a pure interpreter anymore. In languages that support eval() or generating and loading bytecode, it's leveraging the JIT compiler and effectively generating native code.

Matthias247 8y ago

It also comes at the the downside of removing some of the sandboxing abilities from that interpreter. Now the interpreted programs memory is the native programs memory, and the abilities to monitor and limit the interpreted programs memory might be decreased.

deleted 8y ago
[deleted]

stcredzero 8y ago

I am surprised so few interpreters are written in garbage collected languages, which would give the interpreted language a GC for free. There have been Smalltalk implementations written in other Smalltalk implementations which have used this approach. In those cases, the GC is very appropriate for the language implemented.