On This Page
HnxGC is an accurate (precise) garbage collector for C++. It guarantees all garbage will be collected and their destructors be called.
Given an ISO C++ compliant compiler (need to support template), HnxGC can help you to build your application programs that all unreachable objects / garbage will be automatically detected and collected. Resources associated with the object is released in user-defined destructor routine, which will be called by HnxGC system prior to reclaiming the object.
We don't require C++ compiler to provide specific information, such as class and pointer layout, for the garbage collection. We use smart pointer to wrap all effective pointers to objects, and transparently report required information to HnxGC. Therefore, you can choose the best compiler for your platform, such as Intel C++ compiler for x86, without the lost of garbage collection experience.
We don't even need to know the location of a member pointer in an object, just knowing which objects are referenced by the object is enough. So HnxGC can support and manage objects that have hidden-pointers, union, COM object, and those have opaque internal structure to the garbage collector.
See Also:HnxGC give you a clean and secure running environment that is free of interference from garbage collector. Unlike other traditional garbage collector, which will suspend your application thread to finish their garbage collection now and then, lasting long or short, HnxGC guarantees that it will never do that. Now, you are free from worries about whether or not, or when your critical program will be interrupted by garbage collection.
HnxGC can be explicitly set to a background collecting mode, or automatic switch to that mode when it detects more than one application threads are created. A dedicate thread for garbage collector will be created and run concurrently with your application threads. Most of time, the collector is just blocked and waiting for requests from application threads. When it is time to perform garbage collection, such as there are too many objects, the system will automatically trigger the collector to run.
Garbage collection is performed in a full-concurrent manner, which application threads are allowed to run as well as the collector thread. By our unique design, we don't need to suspend an application thread to determine references in execution stacks of the thread and in the registers of processors. Also, garbage collection can start immediately without need to wait for all application threads reach a rendezvous point.
We have also optimized the synchronization mechanism between application threads and the collector thread, such as using some lock-free techniques to remove synchronization primitives such as mutexes or semaphores in critical paths, e.g. during the pointer assignment, there is no mutexes or semaphores being involved.
This non-suspension and non-blocking design make it easier for application to prevent priority inversion problem, as no thread is forced to wait for a suspended thread to complete.
HnxGC is perfect for real-time or multi-media interactive applications. Our testing data shows that, as a critical real-time win32 thread concurrently running with a garbage collection, HnxGC has no delay detected by current off-the-shelf hardware, while it is easy to observe that .NET and other GCs have dozens of delays from tens to a hundred milliseconds.
See Also:In HnxGC, when the last reference to an object is being dropped, the system will detect that and then perform reclamation on the object. That is, when an object loss all references to it, it becomes "zero-referenced" garbage, and the system will reclaim it immediately.
This behavior conforms to traditional reference counting convention. Programmers know when and where an object will become zero-referenced and to be reclaimed. This kind of reclamation is very lightweight, no need to perform a thorough garbage collection just to determine an object is live or dead.
For circular referenced garbage, HnxGC will collect them via a tracing collection periodically. Unlike Java and .NET, we provide extra API to control the order in which unreachable objects are collected. Therefore, an object's destructor routine can access other objects, no worries about these objects have already been destructed.
If you are sure an object will no longer be accessed, you can instruct HnxGC to destruct the object immediately. The system guarantees that an object will only be destructed once, no matter a concurrent collection is running or not.
More advanced API give you control on object reclamation, such as designate an object to be only destructed by a specific thread, or postpone destruction of zero-referenced objects to next HnxGC system call.
These features help people focus on their application logic design, and free the burden of explicitly destructing objects, especially releasing unmanaged resources associated with these objects. You can depend on HnxGC to release unmanaged resources when it founds these objects are no longer used. Therefore, it is nature and easy to use C++ RAII, COM, etc in your HnxGC application program.
See Also:HnxGC allow a managed object be nested into another object, such as being used as member field, base object of derived object of multiple-inheritance or single-inheritance, or a element in an object array. This style is better than .NET and Java in saving memory space and improving performance by reducing cache-miss probabilities, since there is no so large amount of small objects and indirect accesses as in Java and .NET applications.
Managed objects in HnxGC can be directly accessed from native code. There is no need to 'pin' and 'unpin' an object for native access, or use high-cost API to wrap them as it is in .NET and Java. Therefore, if your application depends heavy on native code, such as calling operating system services or 3rd parties' C/C++ libraries, HnxGC may help you a lot.
Your HnxGC C++ program is directly compiled into machine code, runs faster than an interpreter language, and maximum optimization can be applied without concerning about the time-consuming issue as most JIT compilers often confront.
In HnxGC, acyclic garbage will be detected immediately and ready for reclamation. So the memory and associated resource can be quickly reused for these cases. If all objects are acyclic referenced, then there is no waste of memory or resources pending for collection, and the occupancy of memory and system resources is kept in an ideal minimum level, the best efficiency in space.
Because HnxGC need not to suspend application threads to perform garbage collection, the minimum cost of garbage collection can drop to a very low level (1-2 orders of magnitudes lower than .NET, and almost 3 orders of magnitudes lower than BDW). Thus, with the SubHeap concept for isolation objects as groups, garbage collection can complete very fast, even you can perform a collection with every allocation without too much degradation on performance.
We have optimized HnxGC in many ways to improve performance. Such as, encourage using weak pointer to access objects that have known to be live during the access; using "move" semantic to remove reference counting cost; gather trifling works and finish them in one stroke to reduce lock/unlock cost; try to put objects in internal caches and re-use them as more as possible; use lock-free mechanism to synchronize collector and mutator threads; use Global Memory Fence technique to further reduce memory ordering cost in multi-processors environment; ...
Our testing data shows that, for medium or large size of objects, and those objects with destructor defined to release other scarce resources, HnxGC is much better than .NET. In some cases, we even got more than 100 times faster result. For small size objects without destructor defined, .NET is faster than HnxGC standard mode, but if the application can sacrific some coding convenience to use optimized HnxGC object pool, then HnxGC can perform to the same degree of speed of .NET (or even a little faster than it), better than Sun's Java2 HotSpot and some other GCs. Above all, HnxGC is faster than traditional C/C++ manual malloc/free calls.
See Also:| Features |
|---|
| Features of HnxGC |
| Features Comparison |
| About HnxGC |
|---|
| Overview |
| Download HnxGC |
| Installation |
| "Hello World" |
| Programming Guide |