{"id":36811,"date":"2022-08-19T15:06:15","date_gmt":"2022-08-19T19:06:15","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=36811"},"modified":"2023-06-19T10:10:25","modified_gmt":"2023-06-19T14:10:25","slug":"garbage-collection-in-javascriptcore","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/08\/19\/garbage-collection-in-javascriptcore\/","title":{"rendered":"Garbage Collection in JavaScriptCore"},"content":{"rendered":"

Haoran Xu<\/a>:<\/p>\n

The garbage collector in JSC is non-compacting<\/a>, generational<\/a> and mostly–concurrent<\/a>. On top of being concurrent, JSC’s GC heavily employs lock-free programming for better performance.<\/p>\n

[…]<\/p>\n

The inlined metadata cellState<\/code> is easy to access for the mutator thread (the thread executing JavaScript code), since it is just a field in the object. However, it has bad memory locality for the GC and allocators, which need to quickly traverse through all the metadata of all objects in some block owned by CompleteSubspace<\/code> (which is the common case). Outlined metadata have the opposite performance characteristics: they are more expensive to access for the mutator thread, but since they are aggregated into bitvectors and stored in the block footer of each block, GC and allocators can traverse them really fast.<\/p>

So JSC keeps both inlined and outlined metadata to get the better of both worlds: the mutator thread’s fast path will only concern the inlined cellState<\/code>, while the GC and allocator logic can also take advantage of the memory locality of the outlined bits isNew<\/code> and isMarked<\/code>.<\/p><\/blockquote>\n\n

All this engineering notwithstanding, I still find myself using Chrome for some sites like Board Game Arena<\/a>, where performance, even with an M1 Mac, is abysmal compared with Chrome on a much slower Mac.<\/p>\n\n

Previously:<\/p>\n