Home > FAQ

Frequently Asked Questions

Q: What features has HnxGC got?
A: Basically, HnxGC can be treated as a combination of reference counting and an accurate tracing garbage collector. Once an object loses all references to it, it will be destructed and reclaimed immediately, while circular-referenced garbage are collected by the system without any memory leakage. The system will never ever suspend your application threads, and you will never experience unwanted pauses that traditional garbage collector, such as Java and .NET framework, forcibly deliveres to you. HnxGC performs so well and provides lots of powerful features and wide portability with any C++ compliant compiler.

Q: Who can benefit from HnxGC?
A: Most C++ programmers may benefit from HnxGC, especially those who want garbage collection and also want high performance, strong controllability, real-time responses and wide portablity.

Q: How can I use HnxGC?
A: Just use the HnxGC library as a common C++ library and follow some rules for using smart pointers in your application program.

Q: Does the HnxGC library come with a intrepreter or Just-In-Time compiler?
A: No. Your application is directly compiled into native machine code, no P-code or the like. The HnxGC library is just a set of subroutines similar to C/C++ standard library. Your application will run at full speed and totally controllable.

Q: My existing application has lots of C++ classes defined, have I to upgrade all of them?
A: No, you need't. Unlike Java and .NET that propel C++ programmers to a new language and rewrite all codes, you can switch part or all of them to HnxGC class as you like. Native C/C++ code can easily cooperate seamless with HnxGC library.

Q: Is HnxGC a freeware? or a GNU open-sourced project?
A: No. full-functional HnxGC is *NOT* a freeware. The author of HnxGC has filed several patents of HnxGC in the United States and other countries. Whoever without authority makes, uses, offers to sell, or sells any of these patented invention, within the United States and/or other countries infringes the patent(s). However, a version with less functions or evaluation purposes may be provided free and open sources on linux platform, etc.

Technical Questions

Q: How do you collect circular referenced garbage?
A: HnxGC use a modified mark-and-sweep tracing garbage collector to identify garbage objects that are unreachable from application. Meanwhile, reference counting technique is used to reclaim orphan object when the last reference to the object is dropped. All garbage are guaranted be collected no matter they are acyclic or cyclic referenced.

Q: Do you move my C++ objects during the garbage collection?
A: No, we don't. HnxGC objects are never moved implicitly. Therefore, C/C++ or even assembler code can directly access the data of HnxGC objects at anytime. Comparing to the concepts of .NET platform, HnxGC objects are always "locked" and available for native code all the time.

However, with your explicit requests, some kinds of object can be "moved around" via some API calls, especially with object pool and serialization mechanisms.

Q: How can it be accurate without the compiler providing information for each struct or class or template which tells where the pointers in that entity are located?
A: We use smart pointer to report references to the system and with our unique design, there is no requirement for compiler to provide GC related information. For example:

class CNode {
public:
    HNXGC_ENABLE(CNode)
    gcptr<CNode>        m_pNext;
    int                 m_nData[50];
};
int main() {
    gcptr<CNode> p = gcnew CNode;
}

You can also define a traverse method in your class to report references to the system. Further, HnxGC need *NOT* to know where the pointers in an object are located. It just need to know which objects are referenced by `this' object. This design has an advantage that the system can support hidden-pointers and objects with dynamic-changed layout, such as union, bit-fields, COM component wrappers, etc.

Q: How do you achieve pauseless?
A: A multi-threading HnxGC for uni-processor or multi-processors does achieve pauseless. Basically, the concurrently-running tracing collector use lock-free (non-blocking) multi-threading techniques to cooperate with application threads. In additional, the base algorithm of HnxGC successfully eliminates the scanning of root-set area of application program. Thus, there is no need to suspend application thread to get a snapshot of exeuction status, such as application threads' stack frames, CPU registers, etc. As a result, the application threads are running independently from garbage collector. If the application threads do not yield the control, then garbage collector will never be able to stop and affects the execution of application threads.

Basically, we use primitive atomic operations to share data between application threads and garbage collector, e.g. application threads are using CMPXCHG instruction of x86 platform to access write barrier list of HnxGC. The detail of this mechanism is so complicated as concerning the efficiency on multi-processors environments, and deterministic reclamation of garbages. You can get more information from the Algorithm chapters and from the source code.

Q: How do you avoid root set scanning?
A: Root-set scanning normally is refered to suspend execution of one or more application threads, scan the areas that are always accessible from application program, such as stack frames and CPU registers, to determine the start points of tracing garbage collections. Normally, garbage collector determines references in the root-set areas, then tracing these references and determine the referenced objects as root objects, and then tracing down the graph of reference relationship until all reachable objects are marked.

On the contrary, HnxGC does not determine references in the root-set area when performing a garbage collection. Instead, application threads mark the root objects on behavior of HnxGC with reference counting (which also determine the orphan garbage). Therefore, at the tracing garbage collection phase, the HnxGC just scan managed objects and determine which is root objects, and start off reference traversal from them. There is no need to suspend application threads and scan the stack frames, etc. to determine the start points.

Q: Are there any particular requirements of the compiler, library or system on which the application runs that must be met to achieve "No Pause"?
A: The algorithm of HnxGC does not require any particular compiler, library or system to apply, that means HnxGC can achieve "No Pause" without any particular requirements. But, for convenience of programming, we recommend using a standard C++ compiler at least supporting template for smart pointers in application program development, if you don't have any other pre-processing tools specific designed for HnxGC. We have tested HnxGC on various versions of visual C++, intel C++, GNU C++.

We don't require particular library of system. HnxGC can run well even without VM(virutal memory) support. It can be used in a operating system kernel or an embedded environment. Basic multi-threading mechanism should be available for a multi-threading version of HnxGC, such as Critical Section in Win32, and mutex object in pthread library.

Q: What's the feature of "Deterministic Reclamation"?
A: In HnxGC, the deterministic reclamation includes that,
(1) An object is reclaimed promptly when the last reference to it is dropped, very similar to the scene of regular reference counting;
(2) Application program can control the ordering of reclamation of unreachable objects in some degree, so that programmers can free unused system resources in the destructor of an object, no matter the object will become acyclic or cylic garbage.

The purpose of "deterministic reclamation" is to bring the RAII (Resource Acquisition Is Initialization) design pattern back to application programs that use garbage collection. For example, people can close file handle or GUI window in an object's destructor in HnxGC, no need to resort to specific mechanism or function call, such as DestroyWindow(). The system will automatically close the file handle or GUI window when the object become orphan or be collected by garbage collector.

Q: How is the performance of HnxGC?
A: There are many factors affecting the performance of application program. Garbage collection does introduce some overhead, but HnxGC helps the performance improvements in following areas:
- Using native C/C++ memory model, such as object composition, multiple-inheritance, object array, etc., eliminates the overhead of indirect pointer access and reduces the footprint of memory access;
- Promptly reclaim orphan garbage and associated system resources, improve the whole performance of the system;
- Application programs are directly compiled into native machine code, no interpreter or JIT compiler cost;
- Full-optimization of C++ compiler support, especially for those time-consuming optimizations that are non-suitable for JIT compiler;
- Significant portion of reference counting cost is removed by "moving reference" outside managed heap;

Installation Questions

Q: When I try to build an application, I get an error message "cannot find MSVCR80.DLL", does HnxGC require that DLL and cause the error?
A: This error is caused by FAT32 file system with Visual C++ 2005, no related to HnxGC. The solution is,

change the project settings under: "Project Properties -> Configuration Properties -> Manifest Tool -> General", make sure the "Use FAT32 Work-around" is set to Yes. and then do a rebuild all.

Search the internet for "Ust FAT32 Work-around", you will find more detail explanations of this error.

Q: When I run app. on Linux, I get error message "Error: cannot restore segment prot after reloc: Permission denied"
A: It is the new kernel security extensions that disallows lauching a shared library by default, you can fix it by issuing the command:

chcon -t texrel_shlib_t /.../libhnxgc.so

CLR (Common Language Runtime)

Q: I define a class, when enable final garabage collection at shutdown, the system throw an exception and crash.
A: CLR core dll mscorlib may has been unloaded before the HnxGC performs the final collection at shutdown, when there are uncollected objects having Traverse, OnReclaim or Destructor routines that are compiled into CLR code instead binary code, these routines that is required by HnxGC are not accessible since the CLR runtime has been unloaded. Thus, exception is thrown.

Solution A - using #pragma managed statement to wrap user class declaration, cause Visual C++ compiler generate native binary code. For example:

#ifdef _MANAGED
#pragma managed(push, off)
#endif

class CFoo {
	...  ...
};

#ifdef _MANAGED
#pragma managed(pop)
#endif

Solution B - invoke garbage collection before the .NET Runtime is unloaded, for example, invoking garbage collection before the termination of main() function. Prior to the collection, deliberately make those objects that use managed methods unreachable, such as eliminate the reference path from root set. Therefore, when the collection completes, those objects are collected and only left objects that only use native binary methods, which can be collected without the need of CLR runtime support.

Q: Can I use /clr:safe or /clr:pure compiler options as well as /clr?
A: No, you can't. You have to use /clr compiler option to support native code with common language runtime. The /clr:safe or /clr:pure option disallow generation of native code which is required by HnxGC. It's meaningless to use HnxGC under a pure CLR environment, in which all benefits of HnxGC are lost.

Frequently Asked Questions

On This Page