I think everyone's jumped to conclusions on this. The profiles actually show that GC is not the cause. The profiles show a long frame, and only a tiny amount of time taken up by GC. For example the profile posted by TheRealDannyyy shows a frame taking 68ms, but GC only taking 8ms of that. Why didn't it schedule another frame in the remaining 60 ms? It looks like it could have done, because it wasn't busy doing GC, but it didn't. Right now we don't know why, but it is too early to blame GC, especially since it looks like GC finished quickly with plenty of time to spare.
At 60 FPS there is 16ms per frame. A demo like 'endless runner' does a tiny amount of work per frame - let's be pessimistic and say it takes 4ms of time per frame. This leaves another 12ms idle while it waits for v-sync. The browser knows it has 12ms idle, so it does increments of GC work in that time, since it essentially hides the work in otherwise idle time so it doesn't affect performance. So an 8ms period of GC could be the GC working exactly as intended, doing increments of work in the idle time between frames. I don't think there's reason to be suspicious of any GC times under, say, 14ms.
Identifying the cause of issues is surprisingly complicated, which is alluded to in this blog post.
As ever the best approach is to find a way to reliably reproduce the issue (to the best extent possible anyway), and the fact I can't reproduce it suggests it's a device or system specific issue, so we should probably start collecting system specs and look for patterns in specs where the issue can be reproduced.