Studying the Performance and Memory Usage Effects of Adding Reference Counting to Rotor

Component-level reference counting, as provided by Microsoft's Component Object Model (COM), allows for finalization of resources deterministically, but only when it was used properly from the client, including the breaking of cycles. Reference tracking, as implementing in Rotor, has no trouble with reference cycles and has a much more optimized scheme for memory management, but requires programmers to learn and properly use a per-class notification protocol to notify objects with non-memory resources to return them for reuse. Clearly, the advantages of both ref-counting and ref-tracking are desirable in a single system, since neither covers all cases satisfactorily.

 

By adding ref-counting to ref-tracking, Rotor should be able to combine the advantages of ref-tracking, i.e. optimized memory management and cycle management, with the advantages of ref-counting, i.e. deterministic finalization in the absence of cycles without the need to manage cycles or fragment the heap. Of course, the idea of adding ref-counting to a virtual machine is not a new one. In fact, anecdotal evidence suggests that the initial implementer of the CLI had many heated debates about producing a system that did just that, citing time and space overhead for why they ultimately decided against it.

 

The main goal of this research is to provide an initial implementation of ref-counting in Rotor and to study the resulting overhead as applied to simulations of heavy-use systems, e.g. multi-user access to a database, heavy use of unmanaged resources like large bitmaps and several transactions per second against a web site.

 

http://www.sellsbrothers.com/