[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
361: デフォルトの名無しさん [] 2016/01/26(火) 06:48:44.23 ID:v48l+1vS(1) AAS
やっとこの気色の悪い仕組みにトドメが刺されたか
javaとかGCが基本だけどflash();とかできるの？
362: デフォルトの名無しさん [sage] 2016/01/26(火) 07:35:03.77 ID:RBo8KHcc(1) AAS
ゴミ言語は所詮ゴミ
363: デフォルトの名無しさん [sage] 2016/01/27(水) 17:10:09.80 ID:eULyfEEH(1/3) AAS
GCのすべてを否定するつもりはないけど・・・
GCはメモリ管理を自動化する技術だけど、今のコンピュータはメインメモリを何十ギガ積んでたりするのも普通で
メインメモリが足りなくなることはほぼ無くて、しかも仮想メモリもあるから、なおさらメモリは潤沢で・・・
むしろメインメモリ以外のリソースの方が余程貴重で、もし仮にメインメモリが足りなくなるまで
GCを発動しないアホなGCが有ったとしたらメインメモリより先に他のリソースが枯渇する状況
だからメインメモリは無駄遣いしてもよいけど、他のリソースは使い終わったら
こまめに開放しないとダメだから、いつ実行されるか分からないマークスイープ系GCの余計にRAIIな仕組みも必要なわけ
しかしこのRAIIが付け焼刃でなまっちょろい出来だったりする
C#で言えばDisposeが有るけど、C++のデストラクタのように特別扱いされておらず
ただの普通の関数でしかないので、C++のデストラクタみたいに自身のメンバ変数について
自動で芋づる式に呼び出してくれない
だから手動でメンバのDisposeを芋づる式に呼び出すコードを記述しなければならない
いちいち自身のメンバ変数にIDisposableなものが有るか無いか調べるのもひと手間かかるし
もしそうだったら自身もIDisposableにする必要があり、例の一連のイディオムを書かなければならない
当たり前にDisposeの呼び出し忘れが有ってもいけない
まるで、mallocしたらfreeするのと似ている
しかもIDisposableはコンポジションで増殖する
IDisposableなオブジェクトをコンポジションしたら、自身もIDisposableといった具合
C#のようにコンパイラマジックでなんでも実現する言語で
どうしてDisposeをC++のデストラクタみたいに特別扱いしなかったのか謎だ
364: デフォルトの名無しさん [sage] 2016/01/27(水) 17:24:38.54 ID:eULyfEEH(2/3) AAS
謎だといったが、理由ははっきりしていて
メンバのDisposableを自動で呼び出す為には
他で使われてないことを保証する必要があって
参照カウンタ方式のようにローコストなものなら簡単に分かるが
これでは循環参照の問題が出る
プログラマが循環参照を気にしなくてもよいことが前提の
マークスイープ系のGCを搭載した言語では設計思想が破たんするので
参照カウンタ方式は採用できないし
マークスイープ系GCでは何処からも参照されていないことがローコストに分からないので
自動でDisposeを呼び出す仕組みを用意できない
どうにもならない
結局C++の方式が一番優れている
循環参照が発生する場合はweak_ptrを使う事だけ注意を払えば
GCにまつわる他の問題が一切発生しない
365: デフォルトの名無しさん [sage] 2016/01/27(水) 17:46:52.79 ID:eULyfEEH(3/3) AAS
もっと言えばC#でDisposeを実装する場合でも↑は問題になる
自身のメンバのDisposeを呼んでよいのかどうなのか
完全に自分しか使ってないことが分かっているのであればDisposeを呼び出して問題ないが
あちこちから参照されている可能性があるメンバなら勝手にDisposeを呼び出してはいけない
GC任せにするか、自分で参照カウンタを実装するか
どちらにせよ、RAIIと相性が悪い
366: デフォルトの名無しさん [sage] 2016/01/27(水) 17:58:09.12 ID:aloDWtjb(1) AAS
前から何度も言ってるがDisposeの実装はしていいが呼び出しは禁止
これがC#では基本だからね
リソースの使用効率が悪いとか軟弱な反論をするバカがたまにいるが
実行効率気にするならそもそも別の言語使えって話になるからな
C++CLIを使えってこった
本質を見誤るなよ
367: デフォルトの名無しさん [sage] 2016/01/27(水) 18:38:52.76 ID:XmqLFQFE(1) AAS
c#の欠点はデストラクタが呼び出されるタイミングが分からないこと。
不便で仕方ないや。
368: デフォルトの名無しさん [sage] 2016/01/27(水) 18:56:08.53 ID:VDkVQpP+(1) AAS
最近VB.NETを使い始めたんだけど
new したオブジェクトが不要になった時にDispose()よんだり参照にNothing代入する必要ってない（やってもいいが無意味・無駄）なのかな？
369: デフォルトの名無しさん [sage] 2016/01/28(木) 08:05:17.75 ID:oip5UtLa(1) AAS
c++のデストラクタは例外投げられないウンコ仕様
だから皆デストラクタ内で発生したエラーは握り潰してる
他の言語はあんなバカなの真似する必要ない
370: デフォルトの名無しさん [sage] 2016/01/28(木) 17:53:06.50 ID:M0BYpVOa(1) AAS
デストラクタで投げるなよ。迷惑な奴だな。
371: デフォルトの名無しさん [sage] 2016/01/28(木) 18:02:00.92 ID:xwQj4KRs(1) AAS
javaはファイナライザで発生した例外は握りつぶすことが仕様で決まっているな。
c++の場合は、デストラクタでどうしても例外を外に伝えたかったらやりようはある。
372: デフォルトの名無しさん [sage] 2016/01/30(土) 01:11:50.31 ID:QZN0GaAw(1) AAS
そら伝えたかったらやりようはいくらでもあるでしょう？C++に限らず
373: デフォルトの名無しさん [] 2016/02/10(水) 11:29:59.19 ID:lL2Wg2mH(1) AAS
Javaは強制的に解放させることもできるようにすべきだったな。
374: デフォルトの名無しさん [sage] 2016/02/10(水) 11:41:46.63 ID:83b7Yxnh(1) AAS
Java(VM)は(すべてのプラットフォームで)強制的に解放させることもできるようにすべきだったな。
375: デフォルトの名無しさん [sage] 2016/02/10(水) 12:19:44.29 ID:k9iR7lzz(1) AAS
都度メモリ管理するよか、GCに任せた方がスループット的に有利な場合も多いでしょ。
376: デフォルトの名無しさん [sage] 2016/02/10(水) 14:29:59.29 ID:CcpqYYAq(1) AAS
GCはメモリ管理に関しては成功してる、
でも、メモリブロックをオブジェクトに昇格させたにも関わらず、相変わらず「メモリ管理」だから失敗。
377(1): デフォルトの名無しさん [sage] 2016/02/10(水) 17:29:46.71 ID:+sMp0qjD(1) AAS
そうそう、メインメモリの管理に関しては100%成功している
しかし、今やメインメモリはそれほど貴重なものではないわけだがな
コンシューマでも数十GB積んでたりは珍しくない
メインメモリがなくなるより他のリソースが枯渇する方が現実的
だからメインメモリ以外のリソースに関しては使い終わったら即座に開放してほしいから
GCとは別にRAIIを行う仕組みを導入するわけだが
真剣に考えていくと、RAIIはGCと相性が悪い
そもそも使い終わったら自動で即座に開放(RAII)できるなら全てのGCはそう実装すべきで
それが出来ないからわざわざコストのかかるマークスイープを遅延して実行しているわけだからな
C++みたいにGCを参照カウンタ方式にして、プログラマが人力で循環参照が無いことを保証する以外に
あちこちから参照されるオブジェクトのRAIIを自動化する方法は無い
378: デフォルトの名無しさん [sage] 2016/02/10(水) 20:59:51.38 ID:rEABlirv(1) AAS
JAVAはクソ
379: デフォルトの名無しさん [sage] 2016/02/10(水) 21:00:45.91 ID:ZQ/yQmxu(1) AAS
簡単だよ
スレッド立ててGCをフルサイクル実行し続けるだけ
380: デフォルトの名無しさん [sage] 2016/02/11(木) 16:22:39.56 ID:vxbPXQEr(1) AAS
javaもsandy-bridge以降でSSDとかならそれほど重いってわけじゃないけど
相変わらずatomでeMMCだったりする環境も並行して存在してて
そこで動かすと改めて糞だと思うわけよ
GCが悪いんじゃなくてjavaランタイムが悪いんだろうけどね
381: デフォルトの名無しさん [sage] 2016/02/11(木) 19:04:56.18 ID:EuRhj+pR(1) AAS
フラッシュとJAVAは、システムに見つかり次第、速攻アンインストールしている
382: デフォルトの名無しさん [sage] 2016/02/12(金) 08:32:20.35 ID:Uwfak+5B(1) AAS
>>377
Pythonみたいに参照カウント+GC（循環参照を解放するため）が最強ってこと？
383: デフォルトの名無しさん [sage] 2016/02/13(土) 15:34:22.04 ID:OKKAbu21(1) AAS
最近のPC環境でも贅沢が過ぎるプログラムは動かん。
最近の奴だと、Node.jsのパッケージマネージャnpmが`npm search`と初回に打つとパッケージ検索用のインデックスを作ろうとするんだけど、
1つのjsonオブジェクトにまとめようとするからかOOMエラーを吐いて失敗するっていう不具合。
npmに登録されてるパッケージ数が膨大になったせいもあるが、設計を間違えると遅いどころか動かなくなる。
384: デフォルトの名無しさん [sage] 2016/02/13(土) 22:32:48.48 ID:6Xm9VASh(1) AAS
GCがある言語でRAIIみたいな事したいのなら
loan patten使えばいいだけでは
385: デフォルトの名無しさん [sage] 2016/02/13(土) 23:42:47.95 ID:VLo29AwR(1) AAS
リソースを共有した上で最後の参照が切れた時点で回収してほしい
しかし誰が共有するかもその寿命も実行時までわからない
そういう前時代的なダサい設計をした時の話しなんだろ
Loan Patternはこの状況では役に立たない
上下前次1-新書関写板覧索設栞歴
あと 335 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.018s