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

■ このスレッドは過去ログ倉庫に格納されています
2015/11/18(水) 23:24:59.79ID:BUQ68wTG
GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。
以下GCと記す

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

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

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

前スレ
GCは失敗。メモリは自分で管理せよ！
http://peace.2ch.net/test/read.cgi/tech/1412986420/
2015/12/07(月) 23:25:36.31ID:QznWTKRS
>>230
JavaのGCでサーバー応答が止まるなんてザラにある話だよ
それを聞いたことがないなら文系SEと同レベルだね

>>238
管理放棄して開くだけ開いて計算資源を食い潰す玄人気取りプログラマ
2015/12/08(火) 00:48:22.00ID:pyjW8EMu
full GCが頻繁に生じちゃうのは明らかに設計ミスやな
immutableな短命objectを使いまくるのだ。。
つかimmutableなオブジェクト使いまくるとGCないときつくね？
2015/12/08(火) 02:05:45.39ID:H3TgUaFB
RAIIで事足りる
immutableかどうかとＧＣは無関係
2015/12/08(火) 02:21:53.95ID:RVFMry3L
むしろ短命なオブジェクトなんてスタックで十分だし
管理するならshared_ptrのが優れてる
243デフォルトの名無しさん
垢版 |
2015/12/08(火) 03:41:28.67ID:pU1qoPPC
ライブラリ、アプリ、ユーザの三者で考えないと
一部リソースはユーザがを閉じることができる。
そのときアプリの参照を消す仕組みがどのライブラリにもない
244デフォルトの名無しさん
垢版 |
2015/12/08(火) 08:07:46.77ID:rWJ9nJMw
>>243
よくわからんが、それは階層的におかしいのでは？
ユーザーがアプリを通さずにリソースを閉じる事ができるって事？
2015/12/08(火) 12:16:07.11ID:VV6tYNBF
Manager.Execute((res) => ...);

これが終着点
短命なリソースは全てこの形式で事足りし長命なリソースはファイナライザにでも任せればよい
ユーザーが管理しちゃ絶対にダメ
2015/12/08(火) 15:11:36.25ID:DYNM3xm/
このスレでGCいらんて言ってる人たちは環境に恵まれてるんだなぁって思う
2015/12/08(火) 15:20:06.88ID:Bkt0caBE
GC
タモリが昔宣伝してやつ？
2015/12/08(火) 15:28:54.90ID:NMHe7TFl
むしろGCなんて環境良くないと使えないだろ
2015/12/08(火) 16:16:30.38ID:zjJIjn6V
参照がなくなったタイミングで必ず開放してくれて
かつ
循環参照でも問題ない
パーフェクトなGCが有れば最高なわけだが
実際にはそんなGCは無い

となれば、通常であれば言語側は性質の異なる複数のGCを用意しておいて
使う側はシチュエーションに合わせて選べるようにしておくのが自然な発想
しかしそういう言語は殆ど無い、これが問題

といってもマークスイープ系GCが前提のC#やJavaのような言語に
RAIIの発想を持ち込もうとしても
C++のデストラクタのように自身のメンバのデストラクタを自動で芋づる式に呼び出す仕組みが
元々無いので、手動で芋づる式に解放関数を呼び出すコードを書かなければならなく
うまく行っていない
2015/12/08(火) 16:25:08.60ID:RVFMry3L
>>246
JavaでPhantomReferenceも使ったこと無い人って恵まれてるんだなあって思う

>>249
無いのでってもろにAutoCloseableとかあるやん
2015/12/08(火) 16:37:24.80ID:zjJIjn6V
>>250
自分のクラスがファイルなんかのcloseを持つリソースをメンバに持っていたとする
そうすると、それらのメンバのリソースを明示的にcloseできるようにするために
自身もcloseを実装することになるだろう
それで、自身のcloseが呼ばれた時、勝手にメンバのcloseが呼ばれるか？
結局手動でメンバのcloseを呼び出しまわるコードを書かなければならない

C++のデストラクタならメンバのデストラクタが芋づる式に勝手に呼び出されるから
気にしなくて良い
2015/12/08(火) 17:08:50.17ID:NMHe7TFl
強参照、ソフト参照、弱参照、ファントム参照
この字面だけで糞言語って察せられるから凄い
2015/12/08(火) 19:22:21.31ID:RKxPG6yJ
Rustはどう？
明文化されたmoveセマンティクスと、オブジェクトの寿命と参照のチェッカを型システムに組み込んでるおかげで、
リソース管理の実行時コストをゼロにしつつ、メモリリークが発生しないプログラムが書ける。
shared_ptrに相当するRcもあるから、所有者を複数にしたい場合のコストもそれなりに抑えられる。
254デフォルトの名無しさん
垢版 |
2015/12/08(火) 19:35:14.32ID:Hrv9Cion
>>253
すげえ難しいらしいじゃん
2015/12/08(火) 19:52:40.51ID:NMHe7TFl
rustの清貧さは好みだけどまだ触った事ないな
同期処理を省略するためかshared_ptr相当がタスク間跨げないらしいけど
そこら辺の使い勝手ってどうなんだろう
2015/12/08(火) 21:00:06.21ID:RKxPG6yJ
>>254 難しいのは難しいが、低レベルの世界に相応な難易度であって、理不尽さはあまり無いと思う。
自分が遭遇した理不尽というか不便は、トレイト(型クラスみたいなの)を戻り値にした、ジェネリックな関数の型注釈の煩雑さで、
そのworkaroundが、その関数の返り値専用の型を定義する、ってのがカルチャーショックだった。
https://doc.rust-lang.org/std/iter/trait.Iterator.html
↑はIteratorトレイト(Listインターフェイスみたいなもの)のドキュメントだけど、mapとかfoldとかよくある高階関数の戻り値が、それ専用の型(MapとかFold)になってる。
だから、よくある関数型言語のイメージで、何か高階関数を利用したアダプタ関数を試しに定義してみよう！ってやると、
型注釈のエラー、ライフタイムのエラー等が一辺に出てきてわけが分からなくなる。

その関数の戻り値専用の型、なんて贅沢に見えるけど、返り値のサイズを見る限り、余計なデータで膨れているわけでもなかった。
Cでstruct wrap_int { int c; };とやったときにsizeof(wrap_int)がsizeof(int)と等しいけど、それと同じことをやっていた。
型情報なんてコンパイル時に全部消えちゃうから、実行コストも無いんじゃないかと今では思う。

メモリ/リソースの所有権を意識してコードを書くこと、が身について面白いよ。
ヒープを贅沢に使ってコピーしまくりなコードを書くと汚いし遅いしなんで、ちょっとダイエットする気分も出てくる。
2015/12/08(火) 22:39:35.60ID:RVFMry3L
>>251
C++もヒープ相手は自分で呼ぶので、実装は必要だよ
Javaでもメンバの特定メソッド呼び出しはやろうと思えばできる
現実に横断的な呼び出しをやる場合はある

結局要求される物と実装の問題
2015/12/08(火) 22:59:22.32ID:RKxPG6yJ
>>255 shared_ptrと恒等なものは無いけど、ポインタ的に使える型がBox, Rc, Cell(あるいはRefCell)とあって、
Boxはヒープ領域であること、Rcは複数の所有者がいる(つまり所有者全員が死ぬまでは生きている)こと、Cellは複数の書き込みが作れること、
とか機能とコストが別れているから、これらを組み合わせて使う。

で、Thread Safetyを実現させる機構は上記には無いので、Atomicityを導入させるRcの類似形であるArcと、
書き込みもしたいならMutexっていう型も合わせて使う。
すると、例えば整数のベクトルをスレッド間で共有したい、とかになるとArc<Mutex<Vec<i32>>>という目が滑るような型表記をすることになる。
あんま詳しくないので、ケース毎にもっと簡単なやり方があるとは思うんだけどね。
2015/12/08(火) 23:55:28.64ID:NMHe7TFl
>>258
ああ、Arcってのが別にいるのね。納得
個人的にもう一点気になる所があるから聞いてしまう
BoxやDropを使ってるとコピー禁止になるらしいけど
これ面倒な場合ない？
最初はコピー可能な型としてガンガンコピーしてたけど
途中から終了処理を書きたくなったらコピーしてる箇所
全部直すって事？

ちなみにググってたらRWArcっての見つけたんだけど
これ読み書き可能なArcなんじゃね
2015/12/09(水) 00:46:02.26ID:WVnNYSfg
>>249
javaは世代別管理でGCの種類は色々選べるはずでは
261デフォルトの名無しさん
垢版 |
2015/12/09(水) 01:14:15.85ID:wAGGTtTq
>>260
起動時に切り替えられるだけであって
オブジェクトごとには切り替えられないのでは
2015/12/09(水) 01:50:08.36ID:x/ryIvcR
>>259 コピーしまくっているような変数の型をTからBox<T>に変えた場合、確かに面倒なことになる。
けど、基本的に単純な代入(let x = y)はコピーじゃなくてmoveになるし、
Box<T>の値をコピーしてBox<T>の値を生成するっていうのは、同じヒープ領域を指すポインタを作るんじゃなく、
新しいヒープ領域を確保して中身をコピーし、そのポインタを返すという意味なんで、
変数の型を後でTをBox<T>に変える、という場面はあまり無い(少なくとも自分は学んでいる最中にそういうことをしたくなったことがない)

値をコピーする場面では、元の変数の型がBox<T>であってもTであっても、参照型&Tを受け取ってTを生成、ということをするのが定石。
&Tはほぼ無制限に安全に作ることができるし、安全じゃない可能性があったらコンパイルが通らない。
で、コピーした型Tの値は呼び出し元がBoxに包んでヒープ領域に置いたりするのが定石

Dropも別にコピーを禁止することは無いよ。後からつけたらエラーまみれ、ということにはならない。

あと、自作じゃない型に自作じゃないトレイト(インターフェイスみたいなもの)をつけることができないので、
例えば標準ライブラリのFileやTcpStreamはCopyできるようには決してできない。メモリ以外の資源管理も安全だよ。
263デフォルトの名無しさん
垢版 |
2015/12/12(土) 10:36:13.53ID:mXWFWn5f
freeし忘れるとか、そんな超ウルトラ素人ミスを大前提に議論するのは間違いだよなｗ
freeしきれないとかｗｗｗｗ
264デフォルトの名無しさん
垢版 |
2015/12/12(土) 11:52:29.69ID:v/VbuB+R
>>263
規模が大きくなれば管理が難しくなるのは普通のことだよ。
ライフサイクルはオブジェクトごとに異なるものだし、
人間に頼らずにGCにメモリ管理を任せるっていうのは良いやり方だよ。
2015/12/12(土) 12:05:07.06ID:yfUf7LLZ
shared_ptrって参照カウント式のGCじゃないの？
2015/12/12(土) 12:44:09.71ID:7G0ybzbE
循環を綺麗に扱えるなら参照カウントの方が良いと思うけど
VB6は循環参照の扱いどうやってるんだろう
2015/12/12(土) 14:25:51.97ID:npRd3MLZ
>>265
RAIIじゃろ
2015/12/12(土) 15:20:38.55ID:tVgJgcBS
>>265
GCの一種だけど、文脈的にはプログラマが
管理が非局所的で明確な型宣言もなしに使えるのをGCと言ってるわけで
議論で揚げ足にしかならない野暮な突っ込みはやめようぜ
269名無しさん＠そうだ選挙に行こう
垢版 |
2015/12/14(月) 08:16:09.53ID:hn3965Zz
>>264
いや、下手って一言で片付けられるよ。
よっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっぽど、出ない限り
2015/12/14(月) 08:38:44.84ID:sXTPVO5Q
片付ける奴が馬鹿なのだ。素人ほど簡単だと言いたがり、上級者ほど簡単ではないとはっきり言うものだ。
どの分野でもな。
2015/12/14(月) 09:09:02.89ID:lNUL9lX8
freeとか言ってる奴はC++使えよ。いつまでＣ使ってんだ。
2015/12/14(月) 09:20:53.11ID:MauTQhQ/
>>270
東大生が人に教えるとき、何がわからないのかわからないというのがわからない。
上級者になればなるほど自分がやってることなんて簡単に見えてくる
2015/12/14(月) 09:35:23.70ID:sXTPVO5Q
>>272
何が分らないか分らない、つまり東大生も生徒がどういう思考をしてるか分析できず分らないと言ってるのだ。
低学歴ほど、分らないのはおまえが馬鹿だからと簡単に片付けるものだ。
2015/12/14(月) 09:37:05.77ID:eBJzgHzn
それ中級者
あと、東大生は教えるの上手いのもいるから想像で話すな馬鹿
2015/12/14(月) 09:41:37.74ID:sXTPVO5Q
このようにおまえのようなコンテキストすらまともに読めないPGは五万といる。
スレッドがデッドロックしてメモリを開放できないなんてよくあることだ。
276名無しさん＠そうだ選挙に行こう
垢版 |
2015/12/14(月) 10:59:16.82ID:hn3965Zz
>>275
。。。。。完全な設計ミスじゃん
2015/12/14(月) 11:15:19.23ID:eBJzgHzn
>>275
俺は272に向けてたんだが
そりゃコンテキスト読めてないように見えるよなw
2015/12/14(月) 11:40:27.14ID:ETDpPCfc
スレッドがデッドロックしたらメモリリークどころじゃないじゃないかwww
2015/12/14(月) 14:48:51.74ID:MOnxQz3f
スレッドがデッドロックしちゃってメモリ解放できない（泣）
っていうPGが五万といるのかよｗ
280名無しさん＠そうだ選挙に行こう
垢版 |
2015/12/14(月) 15:51:19.55ID:hn3965Zz
まぁfreeやdeleteやnullやらすらできないPGに、「僕はそんなこと管理しきれる脳みそ持ってない！」って言われたらソレは真実なんだろうけど・・・。
そんな脳みそPGに「もっと複雑な業務使用」を理解できるとは思えないんだ。

そんなPGにプログラミングの場を与えるのが間違い。
2015/12/14(月) 15:58:21.86ID:2JSVZtRY
そもそも実務でスレッド使うＰＧなんてゴマンもいない
2015/12/14(月) 17:06:58.52ID:eBJzgHzn
Javaのプロジェクトだとほぼ使ってるけどな隠蔽してるだけで
そのせいで共有リソース壊したり、逆に個人情報の領域が共有されたりして、とんでもないインシデントが発生する
そんな奴等にメモリ管理なんて任せられんし、共有リソースも触らせたくないから
更に隠蔽したフレームワークもどきが出来上がる
283名無しさん＠そうだ選挙に行こう
垢版 |
2015/12/14(月) 17:59:33.07ID:hn3965Zz
>>282
勝手に使うな。勝手にトリッキーコードにすんな。
素直に、設計書通りに作れ。
勝手なことやって勝手に自爆してるだけじゃねーか。
2015/12/14(月) 18:15:27.90ID:Z4FycFda
javaってc++のconst参照に対応するものが無いのに、素人みたいなプログラマを大量にかき集めているのが怖すぎる。
2015/12/14(月) 18:28:13.63ID:eBJzgHzn
>>283
理解してないのに無理してレスしなくていいから
2015/12/14(月) 18:42:08.38ID:CJqGCki1
C#はマルチスレッド使いまくりだけど事故の話はあまり聞かないな
マイクロソフトが優秀なのか低品質プログラマがいないのか
2015/12/14(月) 19:01:59.11ID:2+GDL4RD
JAVA自体がDQN
288uy ◆Qawu9.2l1E
垢版 |
2015/12/14(月) 20:57:26.55ID:J5PYIleC
Freeし忘れ

↑これ。


ソースコード書いてる人間の注意力次第でバグが入るなら
言語も設計も間違ってるよ
2015/12/14(月) 21:54:10.80ID:ETDpPCfc
動的型言語
↑
これ

コード書いている人間の注意力次第でtypoするだけで
実行するまでわからないバグが入るなら
言語も設計も間違ってるよ
2015/12/14(月) 22:23:00.81ID:lNUL9lX8
C#でcatchやfinally書くの嫌すぎる
C++に戻りたい
2015/12/14(月) 22:43:08.79ID:bhzmg0NL
>>290
おかえり
2015/12/15(火) 06:39:51.52ID:gQhFMQgY
(ヽ´ω`)眠い
2015/12/16(水) 08:46:15.45ID:fgV80IeN
>>290
C++/CLR「こっちこいよ」
294デフォルトの名無しさん
垢版 |
2015/12/17(木) 17:18:40.36ID:Szn4FINI
COMのVariantとかJSとかリークしまくりだし
2015/12/17(木) 23:16:36.40ID:kltDf5Nv
そういやVBScriptって参照カウンタ以外のGC積んでんのあれ
必要には見えないんだけど
296デフォルトの名無しさん
垢版 |
2015/12/18(金) 23:17:49.50ID:b1Otx84Y
プログラマはMacを使ってるってマジ？
http://hayabusa3.2ch.net/test/read.cgi/news/1450395043/
2015/12/19(土) 07:07:37.11ID:qL4RiVer
マカーってどんだけアホなの？
298デフォルトの名無しさん
垢版 |
2015/12/19(土) 12:49:09.79ID:EW8XrhCB
解放処理
すら、まともにお前ら管理できねーのかよ・・・・・・・・・・・・・・・・。そらオレが完璧な仕様書渡してもバグってるわけだ
2015/12/19(土) 13:38:07.82ID:i3zp3GbO
開放処理を手動でやれって書いてある仕様書かw
御免こうむるwwwww
300デフォルトの名無しさん
垢版 |
2015/12/19(土) 14:42:49.35ID:iG82T79N
ガベコレのあるPyObjectをラップするクラスをガベコレのあるDで書いたら
wxPythonで書いたクラスをDから使ったとき意味不明なタイミングで落ちるようになった
二重に管理するとだめなんかな
301デフォルトの名無しさん
垢版 |
2015/12/19(土) 15:57:38.71ID:qL4RiVer
>>298
ﾌﾟﾌﾟﾌﾟ　馬鹿だこいつw
2015/12/20(日) 08:46:23.14ID:gr0U1KS4
ガベージコレクションはたしかに便利だ
だからといって「本来はてめぇのケツはてめぇで拭け＝自分で解放すること」を忘れてはならない

そんだけ
2015/12/20(日) 11:55:11.08ID:HXRBhwTH
C#ではSafeHandleだけ作って後は放置
usingも使わないってのがトレンドだけどね
自分で解放とかバカバカしい
面倒はランタイムに見させて開発者はドメイン設計に集中するって目的を見失うな
2015/12/20(日) 12:13:23.36ID:ofrSOHxv
>>303
オブジェクトの開放を他と独立にやれるケースばかりならそう言えるかもしれんが
オブジェクトAとBがリソースCに依存しているケースでA、Bの開放の少なくとも片方をGCに任せる場合、
リソースCの参照カウンタなりをつかった防護策をプログラマーが書かねばならない
しかしそんな嫌ったらしい雑用を増やすぐらいなら
　Cオープン
　A生成
　B生成
　A, B使用
　B開放
　A開放
　Cクローズ
でええやん？

さらにダンプファイルとかからの障害解析において、オブジェクトが生きているべきなのか死んでいるべきなのか決まっていないとか、
アドレスがはっきりしないとか言う状況は地獄
2015/12/20(日) 12:21:54.48ID:ofrSOHxv
つかこの世はうつろうもののであって、物理的ハードウェアでプログラムを実行する限り、
計算モデルは明らかに状態遷移ベース（チューリングマシン）の方に分がある
GCとかチューリングマシンで無理矢理関数型プログラミングを行うためのつなぎの技術、
いわば邪道
どんだけ蛇が出てくるか、GCの方がかえってわからん
2015/12/20(日) 13:48:14.94ID:HXRBhwTH
>>304
設計が悪い
使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
知らなきゃ困るような設計にしたのが間違いだね
2015/12/20(日) 13:52:55.68ID:8RLYRFXT
メモリ空間は無限であるべき
使い終わったメモリの断片化なにそれ？
仮想メモリを管理するのはCPUの責任だろ
2015/12/20(日) 14:03:49.29ID:ofrSOHxv
>>306
>>304の例で、さらにCを上書き更新したいオブジェクトDがいたらどうすんの？
GCがA、B両方開放してくれるまでDは期限不定で待たされるけどそれが>>306的に良い設計なの？

つまり、ハードウェアリソースの有限性を考慮する限り
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
が常に成立はしないという話
2015/12/20(日) 14:28:20.48ID:i39XsMQ2
>>308
そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？
意見を否定するためだけの極端な反例(この場合は例にすらなっていないが)を引き合いに出すのは不毛だよ
2015/12/20(日) 14:35:53.96ID:xl2QwS3M
>>303
いい加減だなぁw
2015/12/20(日) 14:36:58.02ID:ofrSOHxv
>>309
>そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？
極論なもんｶﾖ；
例：　表示デバイスの数＞表示したいスレッドの数
というのはざらにある

で、>>308のオブジェクトDのケースはどう解決すんのさ…
GCが「いつ開放してくれるかわからない」ブツである以上解消しない問題だとおもうんだけど
（A、BにCのための明示的closeメソッドを付けるぐらいならGCに頼らずに順序管理するわ；
2015/12/20(日) 14:42:20.07ID:ofrSOHxv
解決策の一つはActive ObjectパターンでリソースCの管理を1スレッドXにやらせて
Cに対する要求を全部Xのキューにシリアル化して入れさせるというのがあるが、それはそれで
リソースCを使う全てのオブジェクトがスレッドXに依存するから、Xの開放コードが面倒なことになりかねない
かつ、シリアル化はマルチコア時代のせっかくの並列実行性能を殺してしまう

GCに合わせて生きることは、神仙にでもならねば到底かなわぬ…
2015/12/20(日) 14:44:35.05ID:ZDEpjFBd
つくづく、ARC最強だな。
2015/12/20(日) 14:46:27.58ID:i39XsMQ2
>>311
その例じゃ308の状況にならないよ
どんなコード書いてんだよw
2015/12/20(日) 14:48:11.36ID:ofrSOHxv
>>314
>その例じゃ308の状況にならないよ
なんで？ビデオメモリに2スレッドから同時に書いて無事に済むと思ってるの…；
2015/12/20(日) 14:51:52.93ID:i39XsMQ2
だから同時に書く設計が悪いんだって
気合入れて設計を見直してみろ
そんな必要はないってわかるから
2015/12/20(日) 14:55:30.48ID:ofrSOHxv
ていうか>>316の言っていることはますます矛盾で、
>同時に書く設計が悪い
>そんな必要はないってわかる
というのは明白に「書き込みの順序を設計できる」ということを言っていて、
それはその通り（チューリングマシンの計算モデルに合致する）ので別段漏れの立場と対立するものではなく、
かつ気合を入れて設計すれば順序で全て解決する（GCは不要である）という言明でもある
2015/12/20(日) 15:17:45.93ID:14eB8c4R
>>315
もはやGCがどう関係するのかわからない
2015/12/20(日) 15:20:28.11ID:i39XsMQ2
>>318
彼は敵対意見に反論する材料が欲しいというだけで変な例をでっち上げて出してしまったんだ
本人も今頃困ってるんじゃないかな
2015/12/20(日) 17:05:42.48ID:6vo8OCaj
>>319
>>308を変な例変な例というばかりでGCを用いた正しい解決方法が一向に示されない件について：
繰り返しになるが、>>308のオブジェクトDのケースはどう解決すんのさ…
たとえ変でも反例は反例だし
>>308のリソースCがファイルなのだとしたら、病的な反例というほど例外的想定でもない

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

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

>>318
ウィンドウシステムでの描画は一般に裏VRAMに描いてハードウェアでBitBlt転送するが
裏VRAMに書く際のデバイスコンテキストが複数使えるが数に限りがある場合…
とか細かい話をしても通じないようならリソースCをファイルと考えてくんな
2015/12/20(日) 17:12:24.84ID:6vo8OCaj
ﾌﾟﾁ訂正
誤: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306)
正: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>308)
2015/12/20(日) 17:19:25.13ID:HXRBhwTH
読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
書き込みたいから読み込み終わるの待ってますってリソースの無駄だろ
2015/12/20(日) 17:21:31.86ID:ZDEpjFBd
なんか参照カウントの話とマルチスレッドの話がごっちゃになってね？
2015/12/20(日) 17:33:49.10ID:6vo8OCaj
>>322
>読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
破壊的代入の世界ではそいつは常に可能とは限らない

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

この手の混乱は、A、BがアクセスするリソースCの開放タイミングの決定をGCに任せてサボったがために生じるのである
2015/12/20(日) 18:10:09.92ID:ZDEpjFBd
おいおい、バージョン管理のマージの話にまで拡張したら収集つかなくなるぞw
2015/12/20(日) 19:32:49.85ID:i39XsMQ2
>>324
ファイルの分割は必ずしも必要ではないし更新モデルから読み取りモデルへの同期も必要ないよ
2015/12/20(日) 19:44:06.53ID:9YX+2XWA
>>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.85ID:kaqci566
メモリ管理もできないんだから
データの依存関係とか関係ねえ〜〜〜〜〜〜〜〜〜〜〜〜
でおわりでは
2015/12/21(月) 05:26:25.94ID:ejqZ3DMD
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.99ID:ejqZ3DMD
その理由・・・GCは失敗。メモリは自分で管理せよ！
http://peace.2ch.net/test/read.cgi/tech/1447856699/l50
2015/12/21(月) 05:35:31.18ID:ejqZ3DMD
メインメモリに対するGC・・・MGC
HDDならストレージGC・・・SGC
2015/12/21(月) 05:38:11.78ID:ejqZ3DMD
GoogleChromeかsvchost.exeを使わなくなった理由・・・ページメモリGC制御が遅過ぎでお粗末だからか？
2015/12/21(月) 05:42:27.02ID:ejqZ3DMD
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.43ID:ejqZ3DMD
「Svchost Process Analyzer」
svchost.exeのプロセスの中身が何かを調べて表示するフリーソフト
http://gigazine.net/news/20131114-svchost-process-analyzer/
2015/12/21(月) 05:51:39.30ID:ejqZ3DMD
そろそろsvchost.exeを使うソフトは使用禁止なのかも？
2015/12/21(月) 06:11:17.64ID:ejqZ3DMD
svchost.exeを使わないことでGoogleChromeは確実に応答性能が速くなっている
・・・動画マルチ再生でクラッシュしたFirefoxは見習うべき
2015/12/21(月) 06:17:26.48ID:ejqZ3DMD
残念だがスリープだ！ 　
http://pds.exblog.jp/pds/1/201104/11/06/e0026606_2391337.jpg http://i.imgur.com/qrjJDgC.jpg
2015/12/21(月) 06:40:32.08ID:ejqZ3DMD
Wave
http://aurorawave.atspace.tv/?sop:v/jfgn-S6JzfM!RDtSvhh7Sq1OU http://i1.ytimg.com/vi/jfgn-S6JzfM/mqdefault.jpg #AuroraWaveTV
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況