4 ms·
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?
by nemo1618 4y ago
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?
- moonchild 4y agoNo. Most languages with good gcs do not have pointer arithmetic, and many good gcs, especially real-time ones, have a read barrier.
- pjmlp 4y ago.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.
- comex 4y agoThe 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.
- pjmlp 4y agoFor .NET, https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/fixed-statement https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... For Java, https://docs.oracle.com/en/java/javase/18/docs/specs/jni/design.html#implementing-local-references https://docs.oracle.com/en/java/javase/18/docs/specs/jni/des... https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/misc/Unsafe.java 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 https://www.eiffel.org/doc/solutions/CECIL_-_Eiffel_to_C
- ErikCorry 4y agoThe 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.
- aardvark179 4y agoAlthough 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.
- moonchild 4y ago'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.
- pjmlp 4y agoJNI and Unsafe also exist, it isn't only about the language alone.
- ErikCorry 4y agoOh cool, I didn't realize the stack maps were so advanced. Now I'm trying to imagine which optimizations made this necessary/useful.
- Someone 4y agoJava 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?view=net-6.0 https://docs.microsoft.com/en-us/dotnet/api/system.span-1?vi...)
- twic 4y agoJava doesn't even have subobjects in this sense, so you're quite right, you can't do this!
- pjmlp 4y agoIt has JNI, Unsafe, and incoming, Panama. All provide ways to shoot yourself if not used properly.
- oecumena 4y agoI guess it is not more widely used, because more complex generational collectors are often more efficient.