next up previous contents index
Next: 2.9 Regular expressions Up: 2. Onyx Language Reference Previous: 2.7.2 Explicit synchronization   Contents   Index

2.8 Memory management

Onyx programs do not need to track memory allocations, since memory reclamation is done implicitly via automatic garbage collection. Onyx uses an atomic mark and sweep garbage collector.

The atomic nature of garbage collection may sound worrisome with regard to performance, but in fact there are tangible benefits and no significant negative impacts for most applications. Total throughput is improved, since minimal locking is necessary. Concurrent garbage collection would impose a significant locking overhead.

On the down side, atomic garbage collection cannot make strong real-time guarantees. However, the garbage collector is very efficient, and for typical applications, garbage collection delays are measured in microseconds up to tens of milliseconds on current hardware as of the year 2000. For interactive applications, anything under about 100 milliseconds is undetectable by the user, so under normal circumstances the user will not notice that garbage collection is happening.

There are three parameters that can be used to control garbage collection:

  1. The garbage collector can be turned off for situations where many objects are being created over a short period of time.
  2. The garbage collector runs whenever a certain number of bytes of memory have been allocated since the last collection. This threshold can be changed or disabled.
  3. If no composite objects have been created for an extended period of time (seconds), the garbage collector will run if any composite objects have been allocated since the last collection. This idle timeout period can be changed or disabled.

There is one situation in which it is possible for garbage to never be collected, despite the garbage collector being properly configured. Suppose that a program creates some objects, the garbage collector runs, then the program enters a code path that clobbers object references, such that the objects could be collected, but no new objects are allocated. In such a situation, neither the allocation inactivity timer (period), nor the object allocation threshold will trigger a collection, and garbage will remain uncollected. In practice this situation is unlikely, and is not a significant problem since the program size is not growing.

Garbage collection is controlled via the gcdict dictionary, which is described in Section 2.11.4.


next up previous contents index
Next: 2.9 Regular expressions Up: 2. Onyx Language Reference Previous: 2.7.2 Explicit synchronization   Contents   Index
Jason Evans 2005-03-16