I meant the synthetic memory arena, the JS array that malloc() and free() manage. That certainly could contain JS references and needs to be examined by the GC.
I don't think you can actually avoid GC by avoiding JS object allocations. Any form of string manipulation, any form of IO (event handling, DOM manipulation, XHR), any use of timers, etc, is going to allocate objects, right? Also, the JS runtime could generate garbage internally. For example, since JS has closures, it wouldn't be totally unreasonable for the runtime to manage the lifetime of activation records (JS stack frames) using the GC.
The memory arena is a typed array, which cannot contain object references and so does not need to be scanned by the GC.
If you keep JavaScript object allocations to a minimum, then GC pauses will be short and infrequent. This could actually be useful to write a game render loop or any other code that can't tolerate pauses.
Managing JS stack frames using the GC would be very bad for performance. You almost never need to do that unless your language has something like Scheme's call/cc. You may need to promote closed-over variables to the heap, but you don't need to migrate the entire stack frame there.
As modeless said, the memory arena is a typed array. It contains numbers, not JS references. The GC does not look at the contents of typed arrays at all.
String creation does create JS objects, yes, as does creating closures. It is hard to avoid garbage entirely, that's true.
I don't think you can actually avoid GC by avoiding JS object allocations. Any form of string manipulation, any form of IO (event handling, DOM manipulation, XHR), any use of timers, etc, is going to allocate objects, right? Also, the JS runtime could generate garbage internally. For example, since JS has closures, it wouldn't be totally unreasonable for the runtime to manage the lifetime of activation records (JS stack frames) using the GC.