CodegenLIR::VarTracker() maintains a set of expressions that are provably non-null for optimization purposes. The set is cleared at labels, and thus the nullcheck optimization is applied over extended basic blocks. It is represented using a hash table, which must be sized sufficiently large to maintain a reasonable load factor and thus efficient access. We have observed pathological cases in which an earlier sizing heuristic failed miserably due to large extended basic blocks in machine-generated (Alchemy) code. A subsequent heuristic conservatively avoided this issue, but sized the table so large that the time to repeatedly clear it was a hot-spot in increased startup (JIT) time. The current heuristic mitigates the failings of both of the earlier ones, but it is by no means clear that it is optimal. Possible avenues for improvement include: 1) Tuning the ratio between the method length (in LIR instructions) and the preferred hashtable size. 2) Tuning the value of the cap imposed on the actual hashtable size. 3) Initially sizing the table based on typical methods seen in the wild, e.g., Brightspot data, and providing for resizing if needed to handle outliers. 4) Use a timestamp-based constant-time mechanism to clear the hashtable, so that time to clear is not impacted by conservatively-large allocations. See bug 565489 for patches and previous investigations along these lines.

Tamarin isn't maintained anymore. WONTFIX remaining bugs.