Home

Distribution

In order to package and distribute a HashLink application, you need to the following files (on Windows):

• hl.exe which can safely be renamed to YourGame.exe
• libhl.dll for the HL runtime
• msvcr120.dll(for the later use eitherWindows/System32for HL 64 bits orWindows/SysWOW64` for HL 32)
• yourgame.hl (compiled bytecode) to rename to hlboot.dat so it's automatically executed by hl.exe
• the .hdll files you are using
  • fmt.hdll for PNG/JPG/ZIP/etc. support
  • ssl.hdll for HTTPs support
  • some others (see below)

Other dependencies:

• if you are using Heaps you need openal.hdll ui.hdll uv.hdll as well as OpenAL32.dll (from OpenAL Soft)
• if you are using SDL support (-lib hlsdl) you need sdl.hdll and SDL2.dll
• if you are using DirectX support (-lib hldx) you need directx.hdll and d3dcompiler_47.dll (version 6.3, since version 10.x that comes with Windows 10 also requires Universal CRT)
• if you are using Steam support you need steam.hdll steam_api.dll (from steamworks sdk) and msvcp120.dll (see remarks regarding msvcr120)

You can change the exe icon using rcedit with the following command rcedit YourGame.exe --set-icon myicon.ico

GC Notes

The HashLink Garbage Collector is a mark-and-not-sweep collector. The implementation is available in src/alloc.

He allocates system pages multiple of GC_PAGE_SIZE (64 KB) aligned memory.

Pages are discriminated by a type consisting of:

• some pages are of fixed size blocks, (the first GC_FIXED_PARTS of GC_SIZES), some other are of variable size blocks multiples of the other GC_SIZES
• whether the blocks allocated are vdynamic compatible (MEM_KIND_DYNAMIC = 0)
• whether the blocks are not vdynamic compatible but might still contain pointers (MEM_KIND_RAW = 1)
• whether the blocks do not contains any pointers (MEM_KIND_NOPTR = 2)
• whether the blocks contain a finalizer function callback (MEM_KIND_FINALIZER = 3, implies RAW and NOPTR)

Pages are looked up using the gc_pages static.

Blocks have a bitmap consisting of a single mark bit per block. gc_mark() will mark all reachable blocks by scanning the C stack and the roots.

Variable block size pages have an extra sizes field which is a unsigned byte which is the number of physical blocks used for each logical allocation. A size of 0 mean that we're inside a logical block or a not allocated one.

Allocation uses CPU bit counting functions to lookup the bitmap for either the first unset bit (fixed size pages, see gc_alloc_fixed) or the first K unset bits (variable size pages, see gc_alloc_var).

The GC is mostly precise so it's using information provided by the type system (mark_bits) to only lookup for pointers. This prevents some double or int to be mistaken as a valid pointer and create a leak.