It depends how you implement the garbage collector.
Java didn't used to be able to handle circular references (in 1.1), but they changed it so that instead of just strong references, Java could handle different kinds - soft, weak and phantom. This way the garbage collector can determine if a specific object is accessible any more or if its status can be changed to allow it to be GC'd. (although it's up to the VM to decide when, if at all, it is GC'd).
I imagine that in BlitzMax all references are strong, and that's why, when you create a circular reference, you will have to break it yourself when you want the GC to clean up your objects - which isn't such a big deal if you build that capability into your design.
So in Max, read -> circular references are a potential memory leak.
Java didn't used to be able to handle circular references (in 1.1), but they changed it so that instead of just strong references, Java could handle different kinds - soft, weak and phantom. This way the garbage collector can determine if a specific object is accessible any more or if its status can be changed to allow it to be GC'd. (although it's up to the VM to decide when, if at all, it is GC'd).
I imagine that in BlitzMax all references are strong, and that's why, when you create a circular reference, you will have to break it yourself when you want the GC to clean up your objects - which isn't such a big deal if you build that capability into your design.
So in Max, read -> circular references are a potential memory leak.