3 ms·

This code won't work. It scans heap memory, and if a word looks like it points into allocated memory, it's assumed to point into allocated memory, and that mem

This code won't work. It scans heap memory, and if a word looks like it points into allocated memory, it's assumed to point into allocated memory, and that memory is marked as used. When dealing with numbers, such as times, file sizes, etc, you will inevitably store an integer value that looks like a pointer into a valid block. The reason you can do mark and sweep in Java, is that there is a distinct wrapper for all pointers, so you can disambiguate pointers from data. You can't do that in this algorithm, it's impossible. This is also the same reason that disassembly of executables is so hard; it's not always clear what's data and what's instructions.

webkike 12y ago
This has been discussed before. It's the distinction between the collector being precise and conservative. Conservative collectors are fine because they err on the side of retaining memory rather than freeing it. As I stated before, intuitively the odds of an integer containing a pointer-like value is 1/4 (on a 32 bit machine), but they actually tend to be much lower. Even libgc has this issue and it is impossible to resolve in C.
- cygx 12y ago
  s/unprecise/conservative/
  - webkike 12y ago
    Thank you.
chrisseaton 12y ago
"there is a distinct wrapper for all pointers" That's not why the JVM can do this - the JVM knows the location of pointers in objects on the stack, and it only scans them. They aren't wrapped in any way.
- cygx 12y ago
  Your point about the VM being aware of stack layout is of course correct. That aside, Java references can be more complex than a simple pointer to the referenced object. In particular: In some of Oracle’s implementations of the Java Virtual Machine, a reference to a class instance is a pointer to a handle that is itself a pair of pointers: one to a table containing the methods of the object and a pointer to the Class object that represents the type of the object, and the other to the memory allocated from the heap for the object data. http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.7 http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.htm...
  - nly 12y ago
    That's not really to enable garbage collection. In C++, for example, objects with dynamic storage duration will be referenced off the stack by a pointer to your object, which in turn, if the object is of polymorphic type, contains a pointer to the class vtable and runtime type information. That's not so much wrapping as required infrastructure for runtime polymorphism, interfaces etc... even if you replicate the same features in C. Presumably the major difference in Java with re: GC is that there's enough introspection left in the RTTI after compilation for the GC to identify internal references.

webkike 12y ago

This has been discussed before. It's the distinction between the collector being precise and conservative. Conservative collectors are fine because they err on the side of retaining memory rather than freeing it. As I stated before, intuitively the odds of an integer containing a pointer-like value is 1/4 (on a 32 bit machine), but they actually tend to be much lower. Even libgc has this issue and it is impossible to resolve in C.

cygx 12y ago
s/unprecise/conservative/
- webkike 12y ago
  Thank you.

chrisseaton 12y ago

"there is a distinct wrapper for all pointers" That's not why the JVM can do this - the JVM knows the location of pointers in objects on the stack, and it only scans them. They aren't wrapped in any way.

cygx 12y ago
Your point about the VM being aware of stack layout is of course correct. That aside, Java references can be more complex than a simple pointer to the referenced object. In particular: In some of Oracle’s implementations of the Java Virtual Machine, a reference to a class instance is a pointer to a handle that is itself a pair of pointers: one to a table containing the methods of the object and a pointer to the Class object that represents the type of the object, and the other to the memory allocated from the heap for the object data. http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.7 http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.htm...
- nly 12y ago
  That's not really to enable garbage collection. In C++, for example, objects with dynamic storage duration will be referenced off the stack by a pointer to your object, which in turn, if the object is of polymorphic type, contains a pointer to the class vtable and runtime type information. That's not so much wrapping as required infrastructure for runtime polymorphism, interfaces etc... even if you replicate the same features in C. Presumably the major difference in Java with re: GC is that there's enough introspection left in the RTTI after compilation for the GC to identify internal references.