Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

read.crx内のタブを閉じても、そのタブに含まれるキャッシュがメモリから開放されない #311

Open
eru opened this issue May 17, 2017 · 10 comments

Comments

@eru
Copy link
Member

eru commented May 17, 2017

ref #141

#141 (comment)

chromeのメモリ消費量について少々気になっていることがあります。
applicationの場合は実行していたタブを閉じればプロセスも消えてread.crxで使用していたメモリも開放されていたようですが、extensionの場合だとread.crxを終了させてもプロセスは残ったままでメモリが開放されません。
試しにthread.coffee, board.coffee, bookmark.coffeeの"view_unload"の処理部分に、それぞれの処理の冒頭で変数にnew <クラス>としてセットしている変数にnullをセットしてみたのですが、あまり効果はないようでした。
大量の画像をロードした後などは相当のメモリ消費量になるので何とかしたいとは思うのですが、何か良い方法はありますか?

追記
chromeのタスクマネージャで見ると、大半が画像キャッシュとなっているので対応は無理?

追記2
index.coffeeの"unload"イベント処理の最後でchrome.runtime.reload()を実行すれば全てクリアされる。
何か予想される弊害はありますか?

アプリ自体を終了するまで開いたURLのキャッシュが開放されないため、メモリ使用量が増大し続けている。
本来であれば、タブ(read.crx内のタブ)を閉じるタイミングで、そのタブに含まれるキャッシュを開放してやるのが正攻法。

@S--Minecraft
Copy link
Member

nullだとGCが回るまで解放されないので即時開放されるdeleteをしてみては?(記事が古いので少し変わってるかも…)
http://blog.livedoor.jp/aki_mana/archives/2587785.html

@S--Minecraft
Copy link
Member

ちなみに何のキャッシュが残ってるんです…?
スレの中のサムネ画像でしょうか?
スレ本体のhtml/dat?

@eru
Copy link
Member Author

eru commented May 17, 2017

Chromeのタスクマネージャで観測してみました。

タイミング メモリ 共有メモリ 専有メモリ 画像キャッシュ スクリプトキャッシュ CSSキャッシュ GPU JavaScriptメモリ
起動時 65.6MB 152MB 18.6MB 0B 0B 0B - 2580KB
index表示時 134MB 181MB 69.7MB 26.2KB 693KB 0B 22.3MB 31764KB
スレッド表示※1 468MB 338MB 271MB 491MB 749KB 0B 105MB 17428KB
スレッド閉じ 468MB 338MB 271MB 113MB 749KB 0B 105MB 17428KB
index閉じ 469MB 317MB 272MB 113MB 749KB 0B 14B 17428KB
リロード 66.7MB 152MB 19.5MB 0B 11.7KB 0B - 6676KB

※1 1〜1000まですべての画像を読み込ませた状態

スレッド閉じのタイミングで、スレッド表示のiframe部分はアンロードされているのに、113MBの画像キャッシュがなんのために残るのか?
index.htmlを閉じたタイミングでも専有メモリになにが残ってるか不明、放置しておけば開放されるのか…?

@awazi
Copy link

awazi commented May 17, 2017

何となくですが、なんたらキャッシュとなっているのはChromeが内部で使用しているもので、ユーザーサイドで制御できる性質のものではないのではないでしょうか。
プログラム的に制御できるのはJavaScriptメモリの部分だけのような気がします。

それと、deleteも試しては見たのですが、board.coffeeとbookmark.coffeeで定義しているthreadListでビルドエラーになりました。一見普通の変数に見えますが、これは何か特殊なものなのでしょうか?

@eru eru added 保留 and removed バグ labels May 25, 2017
@eru
Copy link
Member Author

eru commented May 25, 2017

何となくですが、なんたらキャッシュとなっているのはChromeが内部で使用しているもので、ユーザーサイドで制御できる性質のものではないのではないでしょうか。
プログラム的に制御できるのはJavaScriptメモリの部分だけのような気がします。

同じくそう見えますね。

@S--Minecraft
Copy link
Member

S--Minecraft commented May 25, 2017

default
devtoolsのMemoryで起動直後、タブ開いたあと、タブ閉じた後でそれぞれでsnapshotをとってみたのですが、青線部で開いたタブのWindowオブジェクトが生成されて、タブを閉じた後本来はなくなるはず(?)なのに赤線部にWindowオブジェクトが残っています(さしているアドレスと内容が合致したのでおそらく同じインスタンスかと)
ただ、これを消す方法はわからないです…

参考: https://stackoverflow.com/questions/19621074/finding-javascript-memory-leaks-with-chrome/19726918#19726918
https://stackoverflow.com/questions/38856457/memory-leak-when-using-iframes-with-javascript

@eru
Copy link
Member Author

eru commented May 25, 2017

メモリリークあるのは問題としても、微々たるサイズではありますね。

5/25 18:28 編集

そもそも、タブ閉じた状態で残るのであれば、閉じる度にそのサイズのリークが発生して、終了まで開放されないと考えるべきですね。

@S--Minecraft
Copy link
Member

https://www.kaoriya.net/blog/2014/03/28/

jQueryのdom.data()がメモリリークしてた可能性?

今プルリクを出してるjQueryなくしたほうはapp.DOMData(実態はWeakSet)で書いてあるが、リークしている兆候はない…?

補足 WeakSetはkeyのobjが消えるとvalueは自動でGCに回収される

@S--Minecraft
Copy link
Member

S--Minecraft commented Jul 2, 2017

おそらく上記のWindowは改善されたと思われる (2018/07/28 訂正)

が、画像のほうはまだ発生している(reloadするまでの間)

@S--Minecraft
Copy link
Member

electron/electron #11550 と同様…?

S--Minecraft added a commit to S--Minecraft/read.crx-2 that referenced this issue Aug 13, 2018
S--Minecraft added a commit to S--Minecraft/read.crx-2 that referenced this issue Aug 13, 2018
S--Minecraft added a commit to S--Minecraft/read.crx-2 that referenced this issue Aug 14, 2018
S--Minecraft added a commit that referenced this issue Aug 14, 2018
Fix: メモリリークの一部を修正 refs #311
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants