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/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への影響もなくユーザ目線では実質コストゼロ
良いコードを書いてるなら圧縮もたまにしか起こらないし起こっても大した事ない

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

>>399からの流れを見ればわかるがそういう話ではない
参照カウンタ方式以外のGCは、オブジェクトがどこからも参照されなくなったことが「即座」にわからない
だからRAIIが出来ない、そういう話

もちろん、参照の値が書き換わるたびに毎回マークスイープを実行すれば
即座にゴミが分かるがのでRAII出来るが、マークスイープは重いので参照が書き換わるたびに毎回実行できない
その意味で、循環参照以外のGCは重いと言っている

参照カウンタ方式は軽いので毎回実行できる
即座にゴミが分かるからRAIIが出来る

参照カウンタ方式で問題になるのは循環参照が起こった場合だが
循環参照が発生する箇所は設計段階で分かるので、実際には大した問題ではない
C++であれば、片方をweak_ptrにすればよいというだけの話
そこさえ気を付ければ、参照カウンタ方式とデストラクタの組み合わせは非常にうまく機能する
IDisposableのようなものも要らない

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

>循環参照以外のGCは重いと言っている

↑間違えた

参照カウンタ方式以外のGCは重いと言っている

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

>>413
安全が何で保証されてるのかを知るためにアセンブラを勉強しなさい。
その上で「パフォーマンスは何の問題もない」かどうかを語りなさい。

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

前にも書いたが、RAIIとGCは直接の関係はないよ。
現にC++/CLIでは、ローカルスコープのオブジェクトがスコープを抜けた時点、あるいは
gcnewで作成されたオブジェクトがdeleteされた時点で即座にデストラクタが実行されて
メモリの回収自体はGCで行われる。

**デフォルトの名無しさん** · 2016/03/27(日) 01:02:24.98

>>415
そもそも不可視のコードでリソースを解放するのが愚行そのもの
プログラマとしての良識があるならusingを使いなさい
RAIIなどというくだらないバッドノウハウはC#では必要ない

**デフォルトの名無しさん** · 2016/03/27(日) 01:31:49.74

>ローカルスコープのオブジェクトがスコープを抜けた時点、あるいは
>gcnewで作成されたオブジェクトがdeleteされた時点で即座にデストラクタが実行されて
>メモリの回収自体はGCで行われる。

それはGC関係ないRAIIの話だろ
C#でもusing使えばRAII出来るが
usingも、ローカル変数も、deleteも、何れもGCじゃない
手動で寿命管理しているに過ぎない

寿命管理を自動化(GC)しつつ、RAIIを実現する話をしているわけだが
どんな場合でも、GCで有ろうが無かろうが、手動でデストラクタなりファイナライザなり呼び出せば
RAII出来るに決まっているだろ、それに何の意味が有るんだよ
自動化の話だよ

**デフォルトの名無しさん** · 2016/03/27(日) 01:33:16.88

>そもそも不可視のコードでリソースを解放するのが愚行そのもの

その最たるものが、マークスイープ系GCなわけですが
いつ実行されるかすら分からない
まさに不可視

**デフォルトの名無しさん** · 2016/03/27(日) 01:51:43.15

極端な話
mallocして使い終わったらfreeして
はい、手動でRAII出来ました！って主張
それ何の意味が有る話なの？ってね

**デフォルトの名無しさん** · 2016/03/27(日) 07:41:27.84

>>420
>それはGC関係ないRAIIの話だろ

メモリはGCで回収されると書いたが？あと、そもそもRAII自体がGCと直接関係ないとも書いた。

>usingも、ローカル変数も、deleteも、何れもGCじゃない

いずれもメモリ領域はGCで回収される。

>どんな場合でも、GCで有ろうが無かろうが、手動でデストラクタなりファイナライザなり呼び出せば
>RAII出来るに決まっているだろ、それに何の意味が有るんだよ

ローカルスコープに置いたオブジェクトは手動で呼ぶ必要はない。
gcnewで作成したものにはdeleteを使うってのは普通のC++と同じだ。
ローカルスコープの変数を基点に、スコープを抜けたときに連鎖的にデストラクタが呼ばれて
delete等の後始末がされるってのがRAIIだからな。
普通のC++ではそのdeleteのときにoperator deleteでメモリ領域が解放されるが、C++/CLIでは
GCで回収されるというだけ。

「GCで有ろうが無かろうが」「RAII出来るに決まっている」ということを理解したならまぁそれでいい。
できないってのを否定しただけで、別に意味があるかないかを話していたわけじゃないからな。
要は、GCを使う多くの言語でRAIIができないのはデストラクタの仕組みを持っていないからであって、
それがあるC++/CLIならRAIIも可能ということ。逆にGCを使わない言語でも、デストラクタがなければ
RAIIは不可能。
つまり最初の結論、RAIIとGCの有無に直接の関係はない。

**デフォルトの名無しさん** · 2016/03/27(日) 10:01:03.80

メモリとその他のリソースを混同して考えるからダメ
まずその他のリソースは不可視のコードで解放しちゃダメ
リソースのスコープは明示的でなければならない
これはデストラクタにもGCにも任せられない
逆にメモリは不可視のコードで解放してもよい
まずこの基本原則から話を進めよう

**デフォルトの名無しさん** · 2016/03/27(日) 10:12:42.93

schemeにはdynamic-windみたいな他所に継続が飛んでも後処理が保証される仕掛けがあるし
デストラクタがない==RAIIできないにはならないと思うの・・・

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

>>424
んな事はない。
あらゆるリソースの寿命はライブラリでデフォルトの管理がされるべきであり、使用者の完全性を前提にすべきではない。

**デフォルトの名無しさん** · 2016/03/27(日) 11:16:32.31

>>426
銀の弾丸は無い
あらゆるリソースのあらゆる利用形態に対してデフォルトの動作を定義できるなら話は別だが無理だよね
結局は人が方針を決めて書くしか無い
幸いにしてメインメモリにはRAIIやマークスイープという正解が見つかっているのでそれを使えばいい
だが他のリソースはダメだ

**デフォルトの名無しさん** · 2016/03/27(日) 16:21:42.54

>>423
そんな基本的なことを言って何がしたいの？

RAIIとGCは密接な関係が有るんだよ
君はローカル変数が好きみたいだから、ローカル変数の事例で説明するとする
(嫌ならC#のusingと読み替えてもらっても構わない)
ローカルに確保したオブジェクトが、メンバ変数に他のオブジェクトを持っていたとする
いわゆるコンポジションの状態、よくある話
C++で言えば、class my_class{ object *obj; };　といった感じのクラスになる、分かるよね？
で、ローカル変数はスコープを抜けたら解放される、usingも似たようなもの、これはRAIIの基本、良いね？
このとき、マークスイープ系GCだと、my_classのobｊに他からの参照が有るかどうか、即座にわからないので
objを開放してよいのか判断が付かない→my_classは破棄されてもobjはGC発動まで保留される→objは残るのでRAIIの意味がない

もしくは、my_classのobjに他からの参照が全く無いことをプログラマが保証して
my_classの開放部にobjをdeleteなりdisposeなりするコードを記入する
しかしこれは、objの所有権がはっきりしていないことには使えない上に、「手動」である
C++の場合はスマポが有るのでまだましだが、C#のDisposeは完全に手動で呼ばなければならない
自身のメンバにIDisposableなメンバいたら、自身もIDisposableにしなければならず、Disposeメソッドを実装して
自身のメンバのDisposeを芋づる式に呼び出すコードを手動で書かなければならない
mallocしたらfreeしましょうと一緒で、C言語レベルの全くの手動になってしまう

参照カウンタ方式のGCではこれらの問題は発生しない
他からの参照が有るか無いかは即座にわかるし、参照カウンタが0になれば、その場で即座に破棄される
自身のメンバに対して、デストラクタは芋づる式に呼び出されるので、C#のDispose実装のような面倒さは無い

>>424
お前言ってること無茶苦茶すぎるだろ

>リソースのスコープは明示的でなければならない、デストラクタにもGCにも任せられない

GCはともかく、デストラクタでもダメって意味不明すぎるんだが
考えの根本がおかしい

**デフォルトの名無しさん** · 2016/03/27(日) 16:43:31.54

C++で書けば
struct A{ *obj };
void func()
{
　　A a;
}
こういったRAIIの場合のobjの開放はどういう扱いにするんだって話

aが完全にobjを所有しているケースなら、Aのデストラクタにdelete obj;とでも書くかscoped_ptrでも使えばよい
しかし、objが彼方此方から参照されている可能性もあるので
そこんとこコンパイラは判断が付かないので、自動化はきない
あくまで、プログラマが保証する形になる
C#のDisposeのような仕組みを言語側で用意したところで、自身のメンバにIDisposableなメンバが有るかどうか
いちいち調べなきゃならなないし、調べ忘れや呼び出し忘れをするという問題が出てくる
しかも、所有権が単一である場合にしか成り立たない

一方でマークスイープ系GCに任せっぱなしにすると、objの開放はGC発動まで遅延してしまうだろう

参照カウンタはこれらの問題をすべて解決する
参照数はどのタイミングでも直ぐに分かるし、0になれば遅延なしで即座に削除される
デストラクタは自身のメンバに対して芋づる式に自動で呼び出されるので
スマポを使っておけば呼び出し忘れるということもないし
Disposeのような冗長なコードを書く必要もない

**デフォルトの名無しさん** · 2016/03/27(日) 16:44:43.86

訂正

struct A{ *obj };
void func()
{
　　A a;
}

↓

struct A{ object *obj };
void func()
{
　　A a;
}

**デフォルトの名無しさん** · 2016/03/27(日) 17:07:08.54

結局、C#のDisposeはどこまで行ってもどんなに進化しても手動で書かなければならない
自身のDisposeが呼ばれたからと言って、自身のメンバ変数のDisposeを芋づる式に勝手に呼び出して良いかは
コンパイラにはまったく判断が付かない
他からも参照されていて今まさに使われている可能性がある以上
コンパイラが勝手に自動でDisposeを呼び出すコードを生成することはできない
GCを発動してみるまでは、どこからも参照されなくなったことが保証できない
しかし、GCの発動まで開放が遅延しても良いのであれば、そもそもDisposeは要らないわけで
Disposeの実行はGC発動より先行していなければならず、GCに頼れないということになる
なので、自身のDisposeが呼ばれたときに、自身のメンバのDisposeをしてよいかは
プログラマが考え、手動で呼び出す必要が有る
所有権が単一であれば、手動でメンバのDisposeを呼び出せばよい
手動で記述しなければならないので面倒くさいし、ミスの元ではあるが、一応できる
所有権が複数であれば参照カウンタを使うしか現実的な方法は無いだろう
マークスイープ系GCなのに参照カウンタで独自に管理するのは馬鹿げているがな

参照カウンタ方式＋デストラクタ
であればこれらの問題は一切発生しない
参照カウンタが0になったことは即座にわかるし、デストラクタはメンバ変数に対して芋づる式に呼び出されるので
開放に関しての特別なコードを手動で書く必要は無い
開放処理も一本化される

**デフォルトの名無しさん** · 2016/03/27(日) 17:16:20.56

長文は漏れなく基地外

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

>>428
バカすぎる
細かい事気にせずデストラクタで解放すりゃそれでおkって感じの適当な現場でしか働いた事無いんだろうな

**デフォルトの名無しさん** · 2016/03/27(日) 17:22:53.59

ポインタがメンバ変数になってたら公開しちゃいかんでしょ

**デフォルトの名無しさん** · 2016/03/27(日) 17:24:21.54

まずDisposeは生成できる
めんどくさいという奴は知識が無いだけ

リソースを共有する事は少ない
というか設計段階で可能な限り少なくする
そして共有するならするでしっかり管理して自動解放などという手抜きはしない
基本中の基本だ

**デフォルトの名無しさん** · 2016/03/27(日) 17:32:09.52

デストラクタで解放してはいけないリソースをデストラクタで解放しなければいいだけで、デストラクタで解放すればいいリソースはデストラクタで自動的に解放すべき。

**デフォルトの名無しさん** · 2016/03/27(日) 20:12:26.78

>参照カウンタ方式＋デストラクタ
>であればこれらの問題は一切発生しない

.NETのマーク&スイープGCの上でRAIIを実現している実例としてC++/CLIを説明したんだが、
「基本的なこと」とか言いながら結局何も理解してないんだな。

そもそもRAIIの話で所有権が共有されたオブジェクトを持ち出すのが意味不明すぎる。

>参照カウンタが0になったことは即座にわかるし、

「いつか」全員が所有権を手放したら「即座に」破棄される
「いつか」全員が所有権を手放したら「いつか」GCで破棄される

どう違うというのか。

**デフォルトの名無しさん** · 2016/03/27(日) 20:35:08.73

RAII信者の痛さは異常
オブジェクトをコピーされたら破綻するのに

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

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