GCは失敗。メモリは自分で管理せよ！その2©2ch.net

**デフォルトの名無しさん転載ダメ©2ch.net** · 2015/11/18(水) 23:24:59.79

GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。
以下GCと記す

プログラマをメモリ管理から開放する！
といいつつ、メモリリーク問題の文献が大量にある。
これすなわち、メモリリーク問題が全然解決していないということ。
さらに、メモリ解放のタイミングの文献まで大量に生み出した。
これすなわち、新たなるメモリ管理に関する問題を生み出したということ。

malloc、freeじゃないが
結局のところ、メモリを管理するという技術は、今しばらくは、身につける・教える・学ぶべきではないだろうか？
使って、そのまま放置しても、基本的にはGCがなんとかしてくれている。
ランジョブからジョブ終了までさほどの時間を要さない。メモリも大して使わないならいいだろう。
しかし、規模が大きくなり常駐ジョブやメモリ大量使用のジョブになってくると、そんなメモリ管理の方法でやっていると、
上記「文献」を生み出されてしまう。

入門時は、メモリに無頓着でもいいだろう。それよりも、目的を達成することが先決だ。
しかし、慣れてきたら、やはりメモリの管理まで余裕を持って自分で行うべきだろう。

前スレ
GCは失敗。メモリは自分で管理せよ！
http://peace.2ch.net/test/read.cgi/tech/1412986420/

**デフォルトの名無しさん** · 2015/12/20(日) 14:48:11.36

>>314
>その例じゃ308の状況にならないよ
なんで？ビデオメモリに2スレッドから同時に書いて無事に済むと思ってるの…；

**デフォルトの名無しさん** · 2015/12/20(日) 14:51:52.93

だから同時に書く設計が悪いんだって
気合入れて設計を見直してみろ
そんな必要はないってわかるから

**デフォルトの名無しさん** · 2015/12/20(日) 14:55:30.48

ていうか>>316の言っていることはますます矛盾で、
>同時に書く設計が悪い
>そんな必要はないってわかる
というのは明白に「書き込みの順序を設計できる」ということを言っていて、
それはその通り（チューリングマシンの計算モデルに合致する）ので別段漏れの立場と対立するものではなく、
かつ気合を入れて設計すれば順序で全て解決する（GCは不要である）という言明でもある

**デフォルトの名無しさん** · 2015/12/20(日) 15:17:45.93

>>315
もはやGCがどう関係するのかわからない

**デフォルトの名無しさん** · 2015/12/20(日) 15:20:28.11

>>318
彼は敵対意見に反論する材料が欲しいというだけで変な例をでっち上げて出してしまったんだ
本人も今頃困ってるんじゃないかな

**デフォルトの名無しさん** · 2015/12/20(日) 17:05:42.48

>>319
>>308を変な例変な例というばかりでGCを用いた正しい解決方法が一向に示されない件について：
繰り返しになるが、>>308のオブジェクトDのケースはどう解決すんのさ…
たとえ変でも反例は反例だし
>>308のリソースCがファイルなのだとしたら、病的な反例というほど例外的想定でもない

読み書き順序の設計の必要性（破壊的代入前提のプログラミング）を口にしつつ
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない（>306）
と言い切ることはできないとかそういう話

で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306)

>>318
ウィンドウシステムでの描画は一般に裏VRAMに描いてハードウェアでBitBlt転送するが
裏VRAMに書く際のデバイスコンテキストが複数使えるが数に限りがある場合…
とか細かい話をしても通じないようならリソースCをファイルと考えてくんな

**デフォルトの名無しさん** · 2015/12/20(日) 17:12:24.84

ﾌﾟﾁ訂正
誤: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306)
正: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>308)

**デフォルトの名無しさん** · 2015/12/20(日) 17:19:25.13

読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
書き込みたいから読み込み終わるの待ってますってリソースの無駄だろ

**デフォルトの名無しさん** · 2015/12/20(日) 17:21:31.86

なんか参照カウントの話とマルチスレッドの話がごっちゃになってね？

**デフォルトの名無しさん** · 2015/12/20(日) 17:33:49.10

>>322
>読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
破壊的代入の世界ではそいつは常に可能とは限らない

>308の例で、リソースCがファイルXなのだとしたら、オブジェクトDが上書きすべきもあくまでファイルXでないといけない。
つまりリソース分離の余地など無い
（正確には、無理矢理ファイルA、BはファイルX、DはファイルYに分ける設計もありえるが、XとYに対する変更をいつどのように統合するかという超難題が生じる

この手の混乱は、A、BがアクセスするリソースCの開放タイミングの決定をGCに任せてサボったがために生じるのである

**デフォルトの名無しさん** · 2015/12/20(日) 18:10:09.92

おいおい、バージョン管理のマージの話にまで拡張したら収集つかなくなるぞw

**デフォルトの名無しさん** · 2015/12/20(日) 19:32:49.85

>>324
ファイルの分割は必ずしも必要ではないし更新モデルから読み取りモデルへの同期も必要ないよ

**デフォルトの名無しさん** · 2015/12/20(日) 19:44:06.53

>>323 (Rust信者で)すまんな。
ttp://smallcultfollowing.com/babysteps/blog/2015/12/18/rayon-data-parallelism-in-rust/#data-race-freedom
マルチスレッドで起きるデータ競合といった問題も、シングルスレッドで起きうるdangling pointerなどの問題も、
どっちも所有権を持つオブジェクトが無闇にいたり、変な参照関係があるから起きるんじゃないか？って言う人がおる。
根っこが同じ、あるいは近しい問題なんで、横滑りに見えても堪忍な。

**デフォルトの名無しさん** · 2015/12/20(日) 19:49:46.85

メモリ管理もできないんだから
データの依存関係とか関係ねえ～～～～～～～～～～～～
でおわりでは

**デフォルトの名無しさん** · 2015/12/21(月) 05:26:25.94

GoogleChrome動作中のタスクマネージャーのイメージ名にsvchost.exeが見当たらない
GoogleChromeでは、svchost.exeを使用せずに、chrome.exe自身で制御しているらしい
Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36 Width/1360px/1920px

**デフォルトの名無しさん** · 2015/12/21(月) 05:32:28.99

その理由・・・GCは失敗。メモリは自分で管理せよ！
http://peace.2ch.net/test/read.cgi/tech/1447856699/l50

**デフォルトの名無しさん** · 2015/12/21(月) 05:35:31.18

メインメモリに対するGC・・・MGC
HDDならストレージGC・・・SGC

**デフォルトの名無しさん** · 2015/12/21(月) 05:38:11.78

GoogleChromeかsvchost.exeを使わなくなった理由・・・ページメモリGC制御が遅過ぎでお粗末だからか？

**デフォルトの名無しさん** · 2015/12/21(月) 05:42:27.02

GoogleChrome動作中のタスクマネージャーのイメージ名にsvchost.exeが見当たらない
GoogleChromeでは、svchost.exeを使用せずに、chrome.exe自身で制御しているらしい
Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36 Width/1360px/1920px

**デフォルトの名無しさん** · 2015/12/21(月) 05:45:15.43

「Svchost Process Analyzer」
svchost.exeのプロセスの中身が何かを調べて表示するフリーソフト
http://gigazine.net/news/20131114-svchost-process-analyzer/

**デフォルトの名無しさん** · 2015/12/21(月) 05:51:39.30

そろそろsvchost.exeを使うソフトは使用禁止なのかも？

**デフォルトの名無しさん** · 2015/12/21(月) 06:11:17.64

svchost.exeを使わないことでGoogleChromeは確実に応答性能が速くなっている
・・・動画マルチ再生でクラッシュしたFirefoxは見習うべき

**デフォルトの名無しさん** · 2015/12/21(月) 06:17:26.48

残念だがスリープだ！　
http://pds.exblog.jp/pds/1/201104/11/06/e0026606_2391337.jpg http://i.imgur.com/qrjJDgC.jpg

**デフォルトの名無しさん** · 2015/12/21(月) 06:40:32.08

Wave
http://aurorawave.atspace.tv/?sop:v/jfgn-S6JzfM!RDtSvhh7Sq1OU http://i1.ytimg.com/vi/jfgn-S6JzfM/mqdefault.jpg #AuroraWaveTV

**デフォルトの名無しさん** · 2015/12/21(月) 06:42:41.39

LG OLED TV : You Dream We Display
http://aurorawave.atspace.tv/?sop:v/VenG8TF90yA!RDVenG8TF90yA http://i1.ytimg.com/vi/VenG8TF90yA/mqdefault.jpg #AuroraWaveTV

**デフォルトの名無しさん** · 2015/12/21(月) 06:43:24.61

LG OLED TV - The Ultimate Display
http://aurorawave.atspace.tv/?sop:v/JubFjalfNIY!RDJubFjalfNIY http://i1.ytimg.com/vi/JubFjalfNIY/mqdefault.jpg #AuroraWaveTV

**デフォルトの名無しさん** · 2015/12/21(月) 07:08:24.86

LG 4K OLED: Paris and Chicago
http://aurorawave.atspace.tv/?sop:v/Hi_WWhih4n4!RDHi_WWhih4n4 http://i1.ytimg.com/vi/Hi_WWhih4n4/mqdefault.jpg #AuroraWaveTV

**デフォルトの名無しさん** · 2015/12/21(月) 09:26:05.64

国別ISO登録件数　⇒　技術マフィア　⇒　技術流出状況　　　
http://www.jicqa.co.jp/09info/07newsletter/2012/no168_news1201.html
http://www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1741.JPG
http://www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1818.JPG
http://www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1742-a.JPG
http://www.google.co.jp/search?q=ISO%E6%9C%AC%E9%83%A8&;num=100&ie=utf-8
http://pds.exblog.jp/pds/1/200909/06/87/a0137487_22475768.jpg

**デフォルトの名無しさん** · 2015/12/21(月) 09:41:02.29

中国、ダークマターの検出に挑む探査衛星「悟空」を打ち上げ
http://news.mynavi.jp/news/2015/12/17/495/
http://n.mynv.jp/news/2015/12/17/495/images/001l.jpg
http://n.mynv.jp/news/2015/12/17/495/images/002l.jpg
http://n.mynv.jp/news/2015/12/17/495/images/003l.jpg

**デフォルトの名無しさん** · 2015/12/21(月) 09:44:40.17

京がお仕置き候補に???
http://gigazine.net/news/20130618-fastest-supercomputers/

◆1位：Tianhe-2(天河二号)、中国人民解放軍国防科学技術大学
http://i.gzn.jp/img/2013/06/18/fastest-supercomputers/01_m.jpg
IntelのIvy Bridge(12コア・2.2GHz)とXeon Phi(57コア・1.1GHz)を採用し、
コア数は312万、計算速度は33.9ペタフロップス、消費電力は17.8MW

◆2位：Titan、アメリカのオークリッジ国立研究所
http://i.gzn.jp/img/2013/06/18/fastest-supercomputers/02_titan2_m.jpg
AMD Opteron 6274(16コア・2.2GHz)とNvidia Kepler(14コア・0.732GHz)を採用し、
コア数は56万640、計算速度は17.6ペタフロップス、消費電力は8.3MW

◆3位：Sequoia、アメリカのローレンス・リバモア国立研究所
http://i.gzn.jp/img/2013/06/18/fastest-supercomputers/03_8716842181_3f50ae207a_o_m.jpg
IBM BlueGene/Qを採用し、中のプロセッサーはPower BQC(16コア・1.60GHz)、
コア数は157万2864、計算速度は17.2ペタフロップス、消費電力は7.9MW

◆4位：スーパーコンピュータ京、独立行政法人理化学研究所計算科学研究機構(AICS)
http://i.gzn.jp/img/2013/06/18/fastest-supercomputers/04_01_m.jpg
富士通 SPARC64 VIIIfx(8コア・2.0GHz)を採用し、コア数は70万5204、
計算速度は10.5ペタフロップス、消費電力は12.7MW

◆5位：Mira、アメリカのアルゴンヌ国立研究所のエネルギー部門
http://i.gzn.jp/img/2013/06/18/fastest-supercomputers/05_30292D004-72dpi_m.jpg
BM BlueGene/Qを採用し、中のプロセッサーはPower BQC(16コア・1.60GHz)、
コア数は78万6432、計算速度は8.6ペタフロップス、消費電力は3.95MW

**デフォルトの名無しさん** · 2015/12/21(月) 09:50:17.19

気づかないかISOは中国のためにある
http://www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1742-a.JPG

**デフォルトの名無しさん** · 2015/12/21(月) 10:45:57.17

>>344
蓮舫さんに次の選挙は次点で良いですよねって言ってきて

**デフォルトの名無しさん** · 2015/12/21(月) 11:12:03.51

>>336
ほんそれ

**デフォルトの名無しさん** · 2015/12/21(月) 12:31:40.33

https://ja.wikipedia.org/wiki/%E8%93%AE%E8%88%AB

**デフォルトの名無しさん** · 2015/12/21(月) 12:34:04.50

https://www.google.co.jp/search?q=%E3%81%BB%E3%82%93%E3%81%9D%E3%82%8C

**デフォルトの名無しさん** · 2015/12/21(月) 12:36:38.19

ただしChromeはプロセスが一杯できるから
タスクマネージャ覗いた時に気持ち悪い

**デフォルトの名無しさん** · 2015/12/21(月) 16:06:45.56

64の時代だから、そろそろCore64ぐらいでイイのでは？
http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/3568.Windows_2D00_7_2D00_CPU_2D00_Usage_2D00_History_5F00_3E37E697.png
http://download.intel.com/newsroom/kits/xeon/phi/gallery/images/XeonPhiDie_02.jpg

**デフォルトの名無しさん** · 2015/12/21(月) 16:21:26.45

ラーメン
http://www.chikuwachan.com/ramen/
http://www.chikuwachan.com/ramen/image/ramen/1430/10_417_512.jpg

**デフォルトの名無しさん** · 2015/12/21(月) 16:33:49.61

http://www.dospara.co.jp/ad/stick_mv.html
http://www.dospara.co.jp/ad/img/stick_mv/title_main.gif

**デフォルトの名無しさん** · 2015/12/21(月) 16:35:11.77

diginnos stickpc_02
http://www.youtube.com/watch?v=OPt0OGNQhnU&;list=RDOPt0OGNQhnU

**デフォルトの名無しさん** · 2015/12/21(月) 18:37:51.00

Holiday Glam
http://aurorawave.atspace.tv/?sop:v/tEdxHgCoXss!RDtEdxHgCoXss http://i1.ytimg.com/vi/tEdxHgCoXss/mqdefault.jpg #AuroraWaveTV

**デフォルトの名無しさん** · 2015/12/21(月) 18:38:29.84

Midnight Luster
http://aurorawave.atspace.tv/?sop:v/DBTd9qv_sJI!RDDBTd9qv_sJI http://i1.ytimg.com/vi/DBTd9qv_sJI/mqdefault.jpg #AuroraWaveTV

**デフォルトの名無しさん** · 2015/12/21(月) 18:43:07.58

Chromeの調子が良い件について・・・TCL 4K Demo: Ultra-Running Beauty
http://aurorawave.atspace.tv/?sop:v/Gg54Miwa8K4!RDHi_WWhih4n4 http://i1.ytimg.com/vi/Gg54Miwa8K4/mqdefault.jpg #AuroraWaveTV

**デフォルトの名無しさん** · 2016/01/10(日) 12:45:59.41

723 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:24:00.06 ID:rlcuxF0A0
Vivaldiの起動が遅いのは
タブのサムネイルに関係しているかもしれない
Blinkは負荷分散のため？かHDDアクセスも遅いらしい
ローカルストレージ関係がとても遅いからだ
724 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:31:29.50 ID:rlcuxF0A0
タブサムネイルを
ローカルストレージで保存するのは止めたほうがいい

タブサムネイルは直接アクセスする事
fopen();ランダム書込:fclose();ランダム読込:fopen();
読取だけならオーバーヘッドを避けるためfopen();しない
725 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:33:41.35 ID:rlcuxF0A0
命題・・・Vivaldiは遅い起動を早期解消せよ！
726 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:37:50.17 ID:rlcuxF0A0
ランダム書込用HDDスペースを作る　個数*固定サイズ　
１トランザクション　個数1024個、固定サイズ256kバイト　
727 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:40:34.65 ID:rlcuxF0A0
そしたら、ランダム読み書きでfopen()すればいい
オーバーヘッドを避けるためfopen();は終了のときだけ
オーバーヘッド無いだけで1000倍ほど速くなるケースも
728 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:44:26.42 ID:rlcuxF0A0
オーバーヘッドはドコにあるのか？
それはWindowsOSのフォルダ構造検索にある
フォルダ構造検索回数を省けば速くなるのだ

**デフォルトの名無しさん** · 2016/01/10(日) 12:47:28.36

Vivaldiの起動が遅いのは
タブのサムネイルに関係しているかもしれない
Blinkは負荷分散のため？かHDDアクセスも遅いらしい
ローカルストレージ関係がとても遅いからだ
タブサムネイルを
ローカルストレージで保存するのは止めたほうがいい
タブサムネイルは直接アクセスする事
fopen();ランダム書込:fclose();ランダム読込:fopen();
読取だけならオーバーヘッドを避けるためfopen();しない
命題・・・Vivaldiは遅い起動を早期解消せよ！
ランダム書込用HDDスペースを作る　個数*固定サイズ　
１トランザクション　個数1024個、固定サイズ256kバイト　
そしたら、ランダム読み書きでfopen()すればいい
オーバーヘッドを避けるためfopen();は終了のときだけ
オーバーヘッド無いだけで1000倍ほど速くなるケースも
オーバーヘッドはドコにあるのか？
それはWindowsOSのフォルダ構造検索にある
フォルダ構造検索回数を省けば速くなるのだ

**デフォルトの名無しさん** · 2016/01/10(日) 12:52:32.51

fopen();のときフォルダ構造検索するようだ

**デフォルトの名無しさん** · 2016/01/26(火) 06:48:44.23

やっとこの気色の悪い仕組みにトドメが刺されたか
javaとかGCが基本だけどflash();とかできるの？

**デフォルトの名無しさん** · 2016/01/26(火) 07:35:03.77

ゴミ言語は所詮ゴミ

**デフォルトの名無しさん** · 2016/01/27(水) 17:10:09.80

GCのすべてを否定するつもりはないけど・・・
GCはメモリ管理を自動化する技術だけど、今のコンピュータはメインメモリを何十ギガ積んでたりするのも普通で
メインメモリが足りなくなることはほぼ無くて、しかも仮想メモリもあるから、なおさらメモリは潤沢で・・・
むしろメインメモリ以外のリソースの方が余程貴重で、もし仮にメインメモリが足りなくなるまで
GCを発動しないアホなGCが有ったとしたらメインメモリより先に他のリソースが枯渇する状況

だからメインメモリは無駄遣いしてもよいけど、他のリソースは使い終わったら
こまめに開放しないとダメだから、いつ実行されるか分からないマークスイープ系GCの余計にRAIIな仕組みも必要なわけ

しかしこのRAIIが付け焼刃でなまっちょろい出来だったりする
C#で言えばDisposeが有るけど、C++のデストラクタのように特別扱いされておらず
ただの普通の関数でしかないので、C++のデストラクタみたいに自身のメンバ変数について
自動で芋づる式に呼び出してくれない
だから手動でメンバのDisposeを芋づる式に呼び出すコードを記述しなければならない

いちいち自身のメンバ変数にIDisposableなものが有るか無いか調べるのもひと手間かかるし
もしそうだったら自身もIDisposableにする必要があり、例の一連のイディオムを書かなければならない
当たり前にDisposeの呼び出し忘れが有ってもいけない
まるで、mallocしたらfreeするのと似ている
しかもIDisposableはコンポジションで増殖する
IDisposableなオブジェクトをコンポジションしたら、自身もIDisposableといった具合

C#のようにコンパイラマジックでなんでも実現する言語で
どうしてDisposeをC++のデストラクタみたいに特別扱いしなかったのか謎だ

**デフォルトの名無しさん** · 2016/01/27(水) 17:24:38.54

謎だといったが、理由ははっきりしていて
メンバのDisposableを自動で呼び出す為には
他で使われてないことを保証する必要があって
参照カウンタ方式のようにローコストなものなら簡単に分かるが
これでは循環参照の問題が出る
プログラマが循環参照を気にしなくてもよいことが前提の
マークスイープ系のGCを搭載した言語では設計思想が破たんするので
参照カウンタ方式は採用できないし
マークスイープ系GCでは何処からも参照されていないことがローコストに分からないので
自動でDisposeを呼び出す仕組みを用意できない
どうにもならない

結局C++の方式が一番優れている
循環参照が発生する場合はweak_ptrを使う事だけ注意を払えば
GCにまつわる他の問題が一切発生しない

**デフォルトの名無しさん** · 2016/01/27(水) 17:46:52.79

もっと言えばC#でDisposeを実装する場合でも↑は問題になる
自身のメンバのDisposeを呼んでよいのかどうなのか

完全に自分しか使ってないことが分かっているのであればDisposeを呼び出して問題ないが
あちこちから参照されている可能性があるメンバなら勝手にDisposeを呼び出してはいけない

GC任せにするか、自分で参照カウンタを実装するか
どちらにせよ、RAIIと相性が悪い

**デフォルトの名無しさん** · 2016/01/27(水) 17:58:09.12

前から何度も言ってるがDisposeの実装はしていいが呼び出しは禁止
これがC#では基本だからね
リソースの使用効率が悪いとか軟弱な反論をするバカがたまにいるが
実行効率気にするならそもそも別の言語使えって話になるからな
C++CLIを使えってこった
本質を見誤るなよ

**デフォルトの名無しさん** · 2016/01/27(水) 18:38:52.76

c#の欠点はデストラクタが呼び出されるタイミングが分からないこと。
不便で仕方ないや。

**デフォルトの名無しさん** · 2016/01/27(水) 18:56:08.53

最近VB.NETを使い始めたんだけど
new したオブジェクトが不要になった時にDispose()よんだり参照にNothing代入する必要ってない（やってもいいが無意味・無駄）なのかな？

**デフォルトの名無しさん** · 2016/01/28(木) 08:05:17.75

c++のデストラクタは例外投げられないウンコ仕様
だから皆デストラクタ内で発生したエラーは握り潰してる

他の言語はあんなバカなの真似する必要ない

**デフォルトの名無しさん** · 2016/01/28(木) 17:53:06.50

デストラクタで投げるなよ。迷惑な奴だな。

**デフォルトの名無しさん** · 2016/01/28(木) 18:02:00.92

javaはファイナライザで発生した例外は握りつぶすことが仕様で決まっているな。
c++の場合は、デストラクタでどうしても例外を外に伝えたかったらやりようはある。

**デフォルトの名無しさん** · 2016/01/30(土) 01:11:50.31

そら伝えたかったらやりようはいくらでもあるでしょう？C++に限らず

**デフォルトの名無しさん** · 2016/02/10(水) 11:29:59.19

Javaは強制的に解放させることもできるようにすべきだったな。

**デフォルトの名無しさん** · 2016/02/10(水) 11:41:46.63

Java(VM)は(すべてのプラットフォームで)強制的に解放させることもできるようにすべきだったな。

**デフォルトの名無しさん** · 2016/02/10(水) 12:19:44.29

都度メモリ管理するよか、GCに任せた方がスループット的に有利な場合も多いでしょ。

**デフォルトの名無しさん** · 2016/02/10(水) 14:29:59.29

GCはメモリ管理に関しては成功してる、
でも、メモリブロックをオブジェクトに昇格させたにも関わらず、相変わらず「メモリ管理」だから失敗。

**デフォルトの名無しさん** · 2016/02/10(水) 17:29:46.71

そうそう、メインメモリの管理に関しては100%成功している
しかし、今やメインメモリはそれほど貴重なものではないわけだがな
コンシューマでも数十GB積んでたりは珍しくない
メインメモリがなくなるより他のリソースが枯渇する方が現実的
だからメインメモリ以外のリソースに関しては使い終わったら即座に開放してほしいから
GCとは別にRAIIを行う仕組みを導入するわけだが
真剣に考えていくと、RAIIはGCと相性が悪い
そもそも使い終わったら自動で即座に開放(RAII)できるなら全てのGCはそう実装すべきで
それが出来ないからわざわざコストのかかるマークスイープを遅延して実行しているわけだからな
C++みたいにGCを参照カウンタ方式にして、プログラマが人力で循環参照が無いことを保証する以外に
あちこちから参照されるオブジェクトのRAIIを自動化する方法は無い

**デフォルトの名無しさん** · 2016/02/10(水) 20:59:51.38

JAVAはクソ

**デフォルトの名無しさん** · 2016/02/10(水) 21:00:45.91

簡単だよ
スレッド立ててGCをフルサイクル実行し続けるだけ

**デフォルトの名無しさん** · 2016/02/11(木) 16:22:39.56

javaもsandy-bridge以降でSSDとかならそれほど重いってわけじゃないけど
相変わらずatomでeMMCだったりする環境も並行して存在してて
そこで動かすと改めて糞だと思うわけよ
GCが悪いんじゃなくてjavaランタイムが悪いんだろうけどね

**デフォルトの名無しさん** · 2016/02/11(木) 19:04:56.18

フラッシュとJAVAは、システムに見つかり次第、速攻アンインストールしている

**デフォルトの名無しさん** · 2016/02/12(金) 08:32:20.35

>>377
Pythonみたいに参照カウント+GC（循環参照を解放するため）が最強ってこと？

**デフォルトの名無しさん** · 2016/02/13(土) 15:34:22.04

最近のPC環境でも贅沢が過ぎるプログラムは動かん。
最近の奴だと、Node.jsのパッケージマネージャnpmが`npm search`と初回に打つとパッケージ検索用のインデックスを作ろうとするんだけど、
1つのjsonオブジェクトにまとめようとするからかOOMエラーを吐いて失敗するっていう不具合。
npmに登録されてるパッケージ数が膨大になったせいもあるが、設計を間違えると遅いどころか動かなくなる。

**デフォルトの名無しさん** · 2016/02/13(土) 22:32:48.48

GCがある言語でRAIIみたいな事したいのなら
loan patten使えばいいだけでは

**デフォルトの名無しさん** · 2016/02/13(土) 23:42:47.95

リソースを共有した上で最後の参照が切れた時点で回収してほしい
しかし誰が共有するかもその寿命も実行時までわからない
そういう前時代的なダサい設計をした時の話しなんだろ
Loan Patternはこの状況では役に立たない

**デフォルトの名無しさん** · 2016/02/14(日) 00:56:38.97

しかし、言語側は、そういうダサい設計も許さないといけないので
マークスイープ系GC搭載で、循環参照が有っても良いことが前提になっている言語で
「使い終わったら自動で即座に開放」を実現するのは困難
そんなことが可能なら、マークスイープは要らないからな

**デフォルトの名無しさん** · 2016/02/14(日) 19:42:04.72

循環参照なんて放置すればいいの
どうせプロセスが終了すればOSが開放してくれるの

**デフォルトの名無しさん** · 2016/02/14(日) 20:10:25.23

>>387
Windowsのように定期的に再起動しなければいけないソフトウェアができあがっちゃいそう

**デフォルトの名無しさん** · 2016/02/15(月) 18:16:17.47

ErlangでOS作るか

**デフォルトの名無しさん** · 2016/02/15(月) 19:50:44.55

そこはRustで

**デフォルトの名無しさん** · 2016/03/01(火) 15:00:17.89

5分でわかるガベージコレクションの仕組み
https://geechs-magazine.com/tag/tech/20160229

**デフォルトの名無しさん** · 2016/03/23(水) 02:31:06.32

常識的に考えてカーネルの実装にはGCなんて使えないし
業務アプリケーションではパフォーマンスより開発速度がはるかに重要になる
結局適材適所だ
GCを強制されるのは苦痛だが使えないのも苦痛だ
好きな時に使える言語がいいよね！

**デフォルトの名無しさん** · 2016/03/23(水) 03:41:39.64

パフォーマンスが問題にならないGCが一つだけあって、それが参照カウンタ方式のGC
パフォーマンスが問題にならない→即座に逐一削除できる→RAIIが出来る
非常に強力だがプログラマが循環参照が無いことを保証しなければならない
しかし、循環参照が発生する場合は設計段階で分かるのでそれほど深刻では無いのだ！

**デフォルトの名無しさん** · 2016/03/23(水) 03:47:03.14

androidでもう何も判らん状態でプログラミングして
それなりに動くのができたからおれは許したよ
でもサービスまで勝手に回収されちゃうとは思わなかったわ
アホだろグーグル

**デフォルトの名無しさん** · 2016/03/23(水) 07:53:14.58

RAIIに必要なのはデストラクタが呼ばれることであって実際にメモリが解放されることじゃないから
GC言語でもRAIIができないわけじゃない。

**デフォルトの名無しさん** · 2016/03/23(水) 10:07:19.06

RAIIに必要なのは適切なタイミングで確実に解放処理が呼ばれることであって
いつ呼ばれるかわからないデストラクタではだめ

**デフォルトの名無しさん** · 2016/03/23(水) 18:24:05.29

かつてStandard MLの実装で、GCじゃないメモリ管理方法をやってみたのがあったな。
コンパイラが全部自動でやるからコードの見た目はSMLなんだけど、いざ動かすとGCより遅かった。

ある程度プログラマがリソース管理のためのヒントを与えないと、GCを捨てられない。

**デフォルトの名無しさん** · 2016/03/23(水) 20:05:29.02

>>396
おまえが言っているのはファイナライザ。
それと、デストラクタはメモリの解放なんかしないよ。デストラクトするだけ。

**デフォルトの名無しさん** · 2016/03/23(水) 21:43:30.89

この際、呼び名はどうでも良い
参照カウンタ方式以外のGCでは、どこからも参照されなくなったことが、即座にはわからない
だから、自動で即座に開放関数を呼び出すことが出来ない→RAIIが出来ない

C#で言うところのusingみたいに、プログラマが手動で情報を与えるなら出来る
だが、usingはGCでは無い

**デフォルトの名無しさん** · 2016/03/24(木) 00:53:54.57

いまさら、ゲームキューブ叩いてどうするんだ？

**デフォルトの名無しさん** · 2016/03/26(土) 05:40:22.28

>>393
間違い
マークスイープのように負荷が集中しないだけでありパフォーマンスへの影響はある
特にツリー状のデータついてルートが削除された時子要素もデクリメントする必要があるため負荷が大きい
カウンタはオブジェクト毎に持つためコピーオンライトとの相性が悪い
また言語の機能として実装されなければ明示的に行う必要がある（例えばCとか）
そのためgcない言語ではマークスイープと比べ非常に面倒なことになる

**デフォルトの名無しさん** · 2016/03/26(土) 10:35:48.15

androidで原因不明のフリーズが発生、プロジェクトはデスマーチに突入した
これだからGCは

**デフォルトの名無しさん** · 2016/03/26(土) 11:39:27.66

これだからGCに頼りきった未熟者は

**デフォルトの名無しさん** · 2016/03/26(土) 11:39:40.83

>>401
そりゃどんなものだって多少の負荷は有るよ
しかし参照カウンタの上げ下げの負荷なんか
マークスイープに比べれば無いも同然

**デフォルトの名無しさん** · 2016/03/26(土) 18:02:09.56

マルチスレッド環境だと参照カウンタとかいうクソアルゴリズムは使い物にならない

**デフォルトの名無しさん** · 2016/03/26(土) 18:52:26.07

参照カウンタがオーバーフローしたらどうなんの？

**デフォルトの名無しさん** · 2016/03/26(土) 19:10:36.57

>>405
SSOのが遅いだろ
>>406
size_t にしとけばオーバーフローしない

**デフォルトの名無しさん** · 2016/03/26(土) 19:44:45.11

>>406
殿堂入りさせて、回収しない

**デフォルトの名無しさん** · 2016/03/26(土) 20:22:44.37

>>407
確かに現実的にオーバーフローしないと言えると思うけど
STLとかもそういう実装になってる？

**デフォルトの名無しさん** · 2016/03/26(土) 20:52:01.21

使う側は少なくとも１つのポインタを持たなくちゃいけないんだからオーバーフローし得ないだろ

**デフォルトの名無しさん** · 2016/03/26(土) 22:10:23.58

マルチスレッドでGCスレッド立ち上げて、再配置起こる可能性のある普通のGCだと、オブジェクト毎にLock,Unlockできる何らかの機構が必要だし、参照カウンタ増減するより高頻度でその機構使うよね。

**デフォルトの名無しさん** · 2016/03/26(土) 22:34:25.82

そうでもない

**デフォルトの名無しさん** · 2016/03/26(土) 23:56:59.65

例えばWindowsだとInterlocked系のAPIを使えば
マルチスレッドでも安全に参照カウンタを増減できるから
パフォーマンスは何の問題もない

**デフォルトの名無しさん** · 2016/03/27(日) 00:13:33.76

C#なら参照のコピーはただのワード代入で済む
メモリ確保もポインタへの加算だけで済むから圧倒的に速い
回収もマルチスレッドで処理されるから圧縮フェーズ以外はUIへの影響もなくユーザ目線では実質コストゼロ
良いコードを書いてるなら圧縮もたまにしか起こらないし起こっても大した事ない

GCは失敗。メモリは自分で管理せよ！ その2©2ch.net

GCは失敗。メモリは自分で管理せよ！その2©2ch.net