Hacker News Reader

Comment by nemo1618 | Hacker News Reader

Am I correct in assuming that "no pointer arithmetic" and "read barrier on every pointer access" are the reasons this approach isn't more widely used?

View on HN

No. Most languages with good gcs do not have pointer arithmetic, and many good gcs, especially real-time ones, have a read barrier.

.NET, Go, Java, Eiffel and Common Lisp all expose ways to do pointer arithmetic, either via unsafe code blocks, or unsafe runtime APIs.

I bet there isn't a language around (with GC) that tops their GC implementations.

The question isn’t whether there’s some way to do arithmetic on raw pointers, but whether you can take a pointer to a subobject and expect the GC to keep the object alive for you. In Go you can do this, but you can’t in Java or C#, I believe.

For .NET, https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

For Java,

https://docs.oracle.com/en/java/javase/18/docs/specs/jni/des...

https://github.com/openjdk/jdk/blob/master/src/java.base/sha...

And as bonus since you didn't ask for it, Eiffel

https://www.eiffel.org/doc/solutions/CECIL_-_Eiffel_to_C

The Java link doesn't describe a way to have a pointer to a subobject. In Java you must always point at the start of an object.

In Go, objects are segregated by allocation size, so the GC can round subobject pointers to keep the surrounding object alive.

Although it isn't visible from the language level the JVM internally does have "derived pointers" which are normally stored on the stack and point to an offset within an object. The GC can figure this out because it has a map for what the stack entries mean.

'The' JVM can internally have whatever it likes; so long as it is not exposed at the language level, nothing prevents an implementation from being devised which does not have such things internally, and which has a treadmill.

JNI and Unsafe also exist, it isn't only about the language alone.

Oh cool, I didn't realize the stack maps were so advanced. Now I'm trying to imagine which optimizations made this necessary/useful.

Java used to do something like that for strings, where taking a substring of a string created an object that pointed into the original string, but that only was for strings, and didn’t expose the pointer, so the implementation could keep a pointer to the original string around for the GC to use.

C# has Span<T>, nowadays, but is guaranteed to only live on the stack, making it easier for the GC to keep the object it points into alive while the Span lives (https://docs.microsoft.com/en-us/dotnet/api/system.span-1?vi...)

Java doesn't even have subobjects in this sense, so you're quite right, you can't do this!

It has JNI, Unsafe, and incoming, Panama.

All provide ways to shoot yourself if not used properly.

I guess it is not more widely used, because more complex generational collectors are often more efficient.

Reply on news.ycombinator.com