12.8.2 Memory Allocation
AllApplicationManualNameSummaryHelp

  • Documentation
    • Reference manual
      • Foreign Language Interface
        • Notes on Using Foreign Code
          • Memory Allocation
            • PL_malloc()
            • PL_realloc()
            • PL_free()
            • Boehm-GC support
              • PL_malloc_atomic()
              • PL_malloc_uncollectable()
              • PL_malloc_atomic_uncollectable()
              • PL_malloc_stubborn()
              • PL_end_stubborn_change()
    • Packages

12.8.2.1 Boehm-GC support

This section is obsolete. Although the Boehm-GC interfaces still exist, it turns out that the scalability is not good enough for SWI-Prolog. It is unlikely that SWI-Prolog will ever switch to Boehm-GC.

To accommodate future use of the Boehm garbage collector186http://www.hpl.hp.com/personal/Hans_Boehm/gc/ for heap memory allocation, the interface provides the functions described below. Foreign extensions that wish to use the Boehm-GC facilities can use these wrappers. Please note that if SWI-Prolog is not compiled to use Boehm-GC (default), the user is responsible for calling PL_free() to reclaim memory.

void* PL_malloc_atomic(size_t bytes)
void* PL_malloc_uncollectable(size_t bytes)
void* PL_malloc_atomic_uncollectable(size_t bytes)
If Boehm-GC is not used, these are all the same as PL_malloc(). With Boehm-GC, these map to the corresponding Boehm-GC functions. Atomic means that the content should not be scanned for pointers, and uncollectable means that the object should never be garbage collected.
void* PL_malloc_stubborn(size_t bytes)
void PL_end_stubborn_change(void *memory)
These functions allow creating objects, promising GC that the content will not change after PL_end_stubborn_change().