>>54,62
Wow,
you sure are retarded.
So, you just let threads access non-atomically shared objects in C/C++?
Do you
really think that you're
not going to use a specialized GC and sufficiently smart compiler? (yes, the same kind of compiler that makes your C/C++ code go vroom vroom)
analyze the dependency graph and make sure you collect only those objects which are truly garbage.
Your allocator doesn't handle sharing? Enjoy randomly dereferencing null pointers.
You use smart pointers with refcounting? Enjoy your cyclic references.
You don't share? Neither do I, and my sufficiently smart GC and compiler will know.
You use the stack for locals? So does my compiler, thank you.
You have some magical bit set to mark an object as ``local''? (gc:mark-as-local! obj)
You deallocate in-place? (gc:mark-as-dead! obj), it would bump the object's collection priority. Also, enjoy randomly dereferencing null pointers.
You have something else? Nothing that a specialized GC and a little of exposed GC API can't do.
Garbage collected languages like Lisp or Java have a global heap built right into the language requirements. You can't ignore it.
Which chapter of the ANSI Common Lisp Standard specifies the garbage collector? I can't find it. R5RS says nothing, and neither do R6RS and R7RS.
I can't find it in the Java Language Specification, Third Edition, too.
This means you can do what the fuck you want in your implementation: you can use a GC, you can expose whatever allocator API you want, you can just use the stack (if any), you can leak memory, and your implementation will still be conformant.
Thus, how can I ignore something that's not even specified?
Also, enjoy your poor cache locality.
Small heaps can be small enough to fit into the processor's cache. But you clearly live thinking that GCs still use a slow mark-and-copy, with a big, unique global heap traversed every time you need to collect some garbage.