"free" shows the amount of memory consumed, not disk (i assume we don't need to discuss the difference).
Doh! My bad, what was i thinking?! Probably because buffers/cache (RAM) and /tmp (also RAM) are mangled in my head...
So... perhaps some threads survive Home button? This is odd, i ass-umed all threads' interpreters are shutdown on (whatever) app exit.
App running: used free
-/+ buffers/cache: 140724 238580
exited "cleanly": used free
-/+ buffers/cache: 136168 243136
App running again: used free
-/+ buffers/cache: 168500 210804
exited with Home: used free
-/+ buffers/cache: 162000 217304
App running:> cached 155244The first exit freed 61 MB, while the second released... nada (or worse, "-1.5mb" but nvm the trifle).
App exited "cleanly"> cached 94540
App running again> cached 154240
App exited with Home button> cached 155788
"joetesta" wrote:Perhaps if @RokuMarkN drops by the thread, he can shed some light - he seems to know the storage mgmt corner well and has been most helpful on the subject in the past.
where do we go from here?
I believe the problem is that the app is using Global Node for storing large json and parsed results, as well as referencing video player.
Trying to figure out how we might change it so that it doesn't use Global Node; how can the data be shared across threads? In the documentation I read about "thread rendezvous" https://sdkdocs.roku.com/display/sdkdoc/Scene+Graph+Threads but trying to figure out how it's implemented or if there's a working example...?
It appears that m.global survives after Home button is pressed, and we need a way to avoid that.
a bug in the current implementation, which is easy for the Co. to fix and will be