Это зависит от ситуации, в которой происходит сбор мусора. Если в стеке нет ссылок на GC-объекты (например, в начале очередного цикла лупера главного потока) — тогда GC гарантированно соберет весь мусор. Когда в стеке могут быть ссылки на GC-объекты (например, если понадобилось освободить память для создания нового объекта), коллектор вынужден трактовать все похожие на ссылки значения как ссылки: иначе он может пропустить настоящую ссылку и удалить объект, не являющийся мусором.
Разворачивание макроса VLOG подразумевает создание временных объектов, под которые требуется память в стеке. Эта память резервируется в начале функции путем уменьшения значения регистра esp на нужную величину.
Мы обсуждали эту ситуацию с разработчиками Chromium, однако изменения в Chromium вносить не стали, поскольку данная проблема — следствие консервативного сканирования стека и «удачного» стечения обстоятельств, у нее нет системного решения. Мы нарвались на эту проблему случайно в одном конкретном тесте, сильно нагружающем GC.
Предполагаю, что под макрос VLOG память в стеке выделяется всегда, но используется она лишь тогда, когда логгирование включено в рантайме. Поэтому включение логгирования тоже лечило эту проблему.
Мы обсуждали эту ситуацию с разработчиками Chromium, однако изменения в Chromium вносить не стали, поскольку данная проблема — следствие консервативного сканирования стека и «удачного» стечения обстоятельств, у нее нет системного решения. Мы нарвались на эту проблему случайно в одном конкретном тесте, сильно нагружающем GC.