Memory leak for V8 based JS engines in OBJLoader

[Cobertos]

I'm not sure if you guys are interested in specific javascript engine based fixes like this but I thought I might submit the bug anyway as I need to implement a fix locally for my application which targets V8. I'm running three.js in Chrome Version 53.0.2785.101 m (64-bit) on Windows x64 with three.js r80. This does not seem to affect Firefox which I also tested.

OBJLoader causes three.js to leak a lot of memory when loading large .obj files in a V8 based engine. It seems as though in V8 based javascript engines, sliced strings will keep a reference to their parent which in the case of the OBJLoader is a massive .obj text file. The actual sliced string with the parent reference comes from loading the objects name in OBJLoader. This is shown in Chrome's memory profiler below.

This bug/feature has been documented on the Chromium bug tracker but it hasn't really gone anywhere.

The user who posted the problem suggests a simple fix to remove the parent reference, which is attached in the referenced pull request (#9680). I tested that this does not leak in my project.

[mrdoob]

Hmm... I'll see if I can ping some people to give more priority to that Chromium bug...

[Cobertos]

As an addendum, I was profiling in Firefox and this exact same thing happens. It seems there's a base property of JSString objects in the Firefox profiler that retain the entire string after slicing (while applying some string operations I get "left child" also). The fix above should work (I messed around with long strings and memory snapshots in the Firefox console and I got it to discard the background reference) but I'm still seeing this in my app.

I figure this might be useful knowledge for anyone who stumbles upon this issue.