RTGC Future Enhancements
Generally, it works the way it is. Here are a few things I think
might change in the future. Not sure whether they will be
beneficial or not though, which is why I haven't done them yet.
- Custom Allocatorwriting or modifying the malloc
routines so that the reclaim thread can more efficiently place
them back on the heap. This could help with the problem above,
also. A 2-phase delete process would call operator delete,
which wouldn't actually free the object and then place the
object on the heap once all objects in the cycle are deleted.
The draw-back is that the custom allocator must be used in order
for it to work.
- Work out how to pass an argument that is a DREF without
incrementing the reference count. Could use a const Dref but
that would mean const pointers aren't possible. Need to be able
to pass a DREF without incrementing the count but passing an
IREF should increment the count.
- WREFs may make it necessary to put a mutex on each object at
the OrphanRec level now. There may be a small window during
which the application can get a pointer and then use it after it
has been freed. Need to verify whether or not this is the case.
- Review locking. Currently there is only one lock used,
which is normally fine for single CPU systems since there is
little or no I/O going on; however, this will cause systems to
multiple CPUs to run basically as tho there was only one from
the allocation subsystem's point of view.
- Need a way to create a reference to an instance by
overriding Void::orphaned() and stop the instance from actually
L. Favor Last modified: Fri Dec 19 18:23:35 CST