News for hackers. Stuff that matters.
Re:Treadmill garbage collector by H. Baker by nemo1618 on Monday July 25, 2022 @11:40PM (#32233992)
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?
Re:Treadmill garbage collector by H. Baker by moonchild on Monday July 25, 2022 @11:47PM (#32234029)
No. Most languages with good gcs do not have pointer arithmetic, and many good gcs, especially real-time ones, have a read barrier.
Re:Treadmill garbage collector by H. Baker by pjmlp on Tuesday July 26, 2022 @01:22AM (#32234571)
.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.

Re:Treadmill garbage collector by H. Baker by comex on Tuesday July 26, 2022 @01:52AM (#32234759)
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.
Re:Treadmill garbage collector by H. Baker by ErikCorry on Tuesday July 26, 2022 @04:38AM (#32235799)
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.

Re:Treadmill garbage collector by H. Baker by aardvark179 on Tuesday July 26, 2022 @05:10AM (#32235974)
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.
Re:Treadmill garbage collector by H. Baker by moonchild on Tuesday July 26, 2022 @06:34AM (#32236489)
'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.
Re:Treadmill garbage collector by H. Baker by pjmlp on Tuesday July 26, 2022 @07:02AM (#32236679)
JNI and Unsafe also exist, it isn't only about the language alone.
Re:Treadmill garbage collector by H. Baker by ErikCorry on Tuesday July 26, 2022 @07:23AM (#32236829)
Oh cool, I didn't realize the stack maps were so advanced. Now I'm trying to imagine which optimizations made this necessary/useful.
Re:Treadmill garbage collector by H. Baker by Someone on Tuesday July 26, 2022 @03:21AM (#32235364)
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...)

Re:Treadmill garbage collector by H. Baker by twic on Tuesday July 26, 2022 @05:56AM (#32236288)
Java doesn't even have subobjects in this sense, so you're quite right, you can't do this!
Re:Treadmill garbage collector by H. Baker by pjmlp on Tuesday July 26, 2022 @07:03AM (#32236692)
It has JNI, Unsafe, and incoming, Panama.

All provide ways to shoot yourself if not used properly.

Re:Treadmill garbage collector by H. Baker by oecumena on Monday July 25, 2022 @11:52PM (#32234059)
I guess it is not more widely used, because more complex generational collectors are often more efficient.