Memory leaks? about goja HOT 10 CLOSED

@iKonrad pprof files gives 404 error

from goja.

@kirillDanshin oops, my bad. here are the correct links:

http://jarosinski.uk/files/heap_base.svg
http://jarosinski.uk/files/heap_current.svg

from goja.

Most likely it's a leak in JS code. However, there is a possibility that goja may be responsible as well, the value stack is only cleared after RunProgram(). I'm going to add a bit more aggressive cleaning which could make a difference in you case, give it a try. If it doesn't I'd like to see JS code.

from goja.

Thanks for your reply!
Unfortunately your change didn't help much. Still the heap gets high and is not released.

JS is a react.js application.

I can't paste the entire react application, but here's the "toString.js" file that handles exporting the React.js to string and sending it back to goja:

https://gist.github.com/iKonrad/5a9ab16be0f253f3d9f1ee2683d77082

Also, the following is go code that creates the goja instance:
https://gist.github.com/iKonrad/6f3528e35e2d5b522fbed6c99d336ec7

newJSVM function creates a new eventloop. Handle gets called for every request

Also, in the toString.js file, global[cbk] has the __goServerCallback__ function passed from the VM.

If you need any other code, feel free to let me know.
Otherwise, do you have any suggestions on how to trace JS memory leaks on server-side?

from goja.

Same methods as for generic memory leaks in Go apply, there is nothing specific in goja I'm afraid. I would probably try writing memory dump.

from goja.

Alright. It must be the React application that's leaking the memory.
In that case, there's no point in keeping this thread open.
Thanks a lot and keep up the good work.

from goja.

No problem. Feel free to reopen if you find out it's actually goja.

from goja.

@iKonrad, are there were your app specific leaks or React in general? Just wondering if it's a go-starter-kit's specific stuff or not.

from goja.

@olebedev

I did load testing to the bare go-react-kit project as well, but it was working fine, so i thought it must be something else.

I spent a good few hours yesterday and it turned out that, as @dop251 suggested, it was a memory leak in JS.

See, in the toString.js gist I've posted above, for some reason I've added memoryHistory thingy from react-router. Then I'm adding the syncHistoryWithProps to the renderProps array which caused a massive memory leak. I can't remember what I was trying to solve with it, but I think memoryHistory is pretty useless when there's match, isn't it?

Either way, the leak's fixed! :)

from goja.

@iKonrad, oh, sure. It doesn't make sense to use in-memory routing and ssr.

from goja.