Frequently Asked Questions

Q: Who can benefit from HnxGC?
A: Most C++ programmers can benefit from HnxGC as well as programmers of some other languages. HnxGC relieves the burdon on programmers of manually handling the memory management. The pause-less feature and its portability especially benefit software developers of real-time critical programs.

Q: How can I use HnxGC?
A: Basically, you need to download the binary package or source code of HnxGC, include several HnxGC header files in your C++ application, develop your application and link with the HnxGC library.

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 as controllable as a traditional C++ program.

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 change to a new language, we encourage programmers to stay with their existing codes (C++ classes) as far as possible, only switch some of them to HnxGC class when it is hard to manage them manually. Native C/C++ code can easily cooperate seamless with HnxGC library, such as RAII are both welcomed by HnxGC and traditional C++.

Q: Is HnxGC a freeware? or a GNU open-sourced project?
A: No. 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, the source code of HnxGC is available for reference upon request. For a non-commercial educational purpose, you may be granted free to use, copy and distribute the software and its documentations.

Technical Questions

Q: How do you collect circular referenced garbage?
A: HnxGC use a 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. 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.

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: For C++ application, a traverse function should be provided by programmers to tell the system which objects are referred from the specific object. Several helper macros are provided to ease the task, for example:

class CFoo {
public:
    int                     m_nAge;
    CMemberPtr<CFoo>        m_pNext;    // a smart pointer to "CFoo" object
    int                     m_nData[50];
    HNXGC_TRAVERSE(CFoo){
        // tell HnxGC which objects are referenced by `this' object.
        HNXGC_TRAVERSE_PTR(m_pNext);
    }
};

Actually, 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, ActiveX 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 "determinist 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() call. 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 some or none objects that only use native binary methods, which can be smoothly handled by the final garbage collection 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.

Show Comments >>>

HnxGC - an accurate, pauseless & deterministic garbage collector

News:

Main Menu

Algorithm

Languages

Frequently Asked Questions

On This Page