Currently, the associated chain for a leak candidate (called the leak context edge) is stored as a pointer in the mark word. With Lilliput, this will not work.

Providing another hashtable works fine to solve this problem, but the overhead might not fully warrant it. The default hashtable has 1009 buckets IIRC, but the number of leak candidates (samples) found during heap traversal might only be a relatively small number (default queue size is 256).

A solution is to still use space available in the markword, since we have already provisioned to use this as a "scratch area" as part of setup - but it is now limited to accommodate for Lilliput (i.e. restricted to only use the lower 32-bits). Instead of storing a pointer to the leak context edge, we store an index into an array.