hi, I take it from the "gc.h" reference you're using island? gc.h is an internal detail really, the RTL uses it to allocate (it's a gc so it will clean up as soon as you clear all references to it)
is where it hooks up the gc, boehm, to the allocator code.
This is the code that gets called for "new" (There's a different one for arrays and delegates under it)
But really from a usage perspective this shouldn't require anything from you, the gc and the compiler will take care of it. Now if you are allocating large memory blocks and need full control over allocation and freeing there's always malloc/free (Posix) or ExternalCalls.malloc/ExternalCalls.free (Windows).
The thing with gc vs manual is that both have tradeoffs. The gc does most things in a background thread, it does a minimal amount of "stop of the world" for marking, this is from the boehm description:
Performance of the nonincremental collector is typically competitive with malloc/free implementations. Both space and time overhead are likely to be only slightly higher for programs written for malloc/free (see Detlefs, Dosser and Zorn's Memory Allocation Costs in Large C and C++ Programs.) For programs allocating primarily very small objects, the collector may be faster; for programs allocating primarily large objects it will be slower. If the collector is used in a multithreaded environment and configured for thread-local allocation, it may in some cases significantly outperform malloc/free allocation in time.
hope that explains it.