It does own the memory, just that there is no reference to the beginning of the
allocated segment, but to somewhere in the middle.
If I think about it more, it might be doable, because the GC must just keep
internal administration of blocks and then check if pointer values found
match in an existing allocation. It makes determining and comparing
references maybe a bit more costly, and the risk on false positives is
larger (the space of allowed pointer values might become larger), but it
should be possible I think.
... but maybe not using the common Boehm implementation (libgc)
Doing that on the front might not be a problem, but how to throw that away
at the end of the life? That's what the GC is supposed to do.
The GC would be in near complete control (a few pretty static allocations
on startup, before GC initialization and maybe TLS as exceptions)
The language provides reference counting, but only for non-nestable types.
(iow not for classes, these are manually allocated). Most of these objects
are allocated over the memmanager that is plugged by the GC. I don't think
the internally allocated objects are the problem, except for the above
reference_points_to_somewhere_in_the_block problem. described above
The externally allocated objects are typically COM (or JNI/Corba whatever),
and I assume these are situation in memory managed by windows, so if the GC
limits itself to mapped mem of the app, these shouldn't be a problem.