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/

**デフォルトの名無しさん** · 2016/07/16(土) 10:13:41.67

△: リストの要素
○: リストの要素が保持するデータ

つか開放タイミングをshared_ptrに任せておk、などという発想のは管理しているうちに含めれないがな…

**デフォルトの名無しさん** · 2016/07/16(土) 10:38:52.53

一般のグラフじゃなくてリスト構造の話だろ？
双方向リストはheadとtailへの参照があるが、単方向リストで循環参照は生じようがないが。

**デフォルトの名無しさん** · 2016/07/16(土) 11:51:50.13

>>572
すまんの>>570の単方向リストは正確には循環リストもしくは環状リストと呼んだ方が良いかも試練、

だが、循環リストもしくは環状リストも単方向リストの実装方式の一つではある（初期の『プログラミング言語C++』か何かのslist等
のじゃ…！

**デフォルトの名無しさん** · 2016/08/22(月) 17:06:41.08

循環してるかは後付けでオブジェクトをマークすれば判るんだし
扱うデータ構造から可能性の有無は予測できるし循環自体は大した問題じゃないよ
あ、これリークするなと思ったら対策すればいいだけ
問題は他人様のブラックボックスなライブラリを使う場合

**デフォルトの名無しさん** · 2016/08/22(月) 19:24:37.36

？
今の議論はプログラマーが何も考えないアホでもGC(言語)使ってれば問題無いのか
そうでなければ結局なんらかの管理が必要でちゃんとする事しないとリークするから本質的には管理から開放されないよねって話だと思うが

**デフォルトの名無しさん** · 2016/08/22(月) 19:33:58.37

いまどきの子はブラウザアプリしか作れないから
ブラウザ再起動とかページ遷移で解決でしょうな

**デフォルトの名無しさん** · 2016/08/23(火) 19:56:22.47

現在のGCが不完全なだけであって、
メモリは人が管理すべきでないという考え自体は正しいよ。

**デフォルトの名無しさん** · 2016/08/23(火) 20:17:10.56

潤沢なメモリを用意してGCしない戦略
起動時間に限ってGCしなくても問題ない範囲であればGCしない戦略
結局こういうのが勝つ

**デフォルトの名無しさん** · 2016/08/23(火) 20:29:14.30

プロセスを細かく分けて寿命を短くすればそんなの考えなくて済む

**デフォルトの名無しさん** · 2016/08/24(水) 13:32:09.69

本当の意味での軽量プロセスをOSがサポートしてくれたら良いんだけどね
メモリプールみたいなもんなんだけど、OSのリソースも紐づいてて
メモリプール解放時にOSのリソースもちゃんと解放されるようなもの
マルチプロセスは非常に強力で良いんだけど
メモリ空間が別になるから色々面倒だしパフォーマンスも出にくい

世の中には呼び出したらしばらく処理が返ってこない時間のかかる関数があるけど
とうぜんUIが固まったら困るから別スレッドで実行するわけだけど
処理中にユーザーがキャンセルボタンを押したとき
処理を中断する手段が関数側に用意されてなかったりすると、困る
外からスレッドごと殺しても、リソースリークの問題が出る
真っ先に困るのが同期オブジェクト
同期オブジェクトを握った状態で死なれると、それ以降デッドロックを引き起こす
それ以外にも、プログラムの整合性が壊れているかもしれないので、以降正しく動く保証がない

だから別プロセスで実行して、キャンセルされたときはプロセスごと殺すしか方法が無い
しかし別プロセスにするとメモリ空間が繋がってないので面倒
だからその中間がほしい

**デフォルトの名無しさん** · 2016/08/24(水) 16:03:33.76

erlang最強

**デフォルトの名無しさん** · 2016/08/24(水) 19:53:51.27

軽量プロセスより重量スレッドの方が実現できそう。

**デフォルトの名無しさん** · 2016/08/24(水) 20:02:24.36

いつ無くなってしまうかわからんようなメモリのアクセスが簡単になってもほとんど使いみちないだろ。
安全性重視なら別プロセスにして、必要なデータだけ共有メモリで受け渡してのが妥当なところだろう。

**デフォルトの名無しさん** · 2016/08/24(水) 20:18:52.71

結論から言うと、Windowsにforkが無いのが面倒すぎるってことなんだけどね

**デフォルトの名無しさん** · 2016/08/24(水) 20:32:21.12

>>580
> 処理を中断する手段が関数側に用意されてなかったりする
具体的には？

**デフォルトの名無しさん** · 2016/08/24(水) 22:11:21.77

いやそんなもん、中断する手立てが用意されている方が珍しいだろ

**デフォルトの名無しさん** · 2016/08/24(水) 22:31:11.60

>>586
で、具体的には出せないと言うことね

**デフォルトの名無しさん** · 2016/08/25(木) 11:39:37.19

元々はスレッドが軽量プロセスって呼ばれていたりしたんだがな（アドレス空間の切り替えが不要だからプロセスより切り替えが軽い）

まあそれはおいておいて
forkを使うと軽量プロセス？とやらの機能が実現できるらしい理屈がわからない
forkしたら別プロセスだぞ？
vforkとかなら実行直後は共有しているけど変更を加えた時点で分かれるし

まあどちらにしろGCじゃメモリーをはじめとする資源管理からは完全には解放されないって事だ

**デフォルトの名無しさん** · 2016/08/25(木) 11:59:23.81

メモリ空間がつながっていること自体はそれほど考慮してないんよ
単にWindowsはマルチプロセスがしにくい
forkあったらちょっとした処理を別プロセスで実行するの、便利じゃん
片づけはプロセスごと殺して終わりだし

**デフォルトの名無しさん** · 2016/08/25(木) 15:41:54.51

ほしいのはLinuxでいうclone(2)やね

**デフォルトの名無しさん** · 2016/09/03(土) 00:41:24.79

https://cedil.cesa.or.jp/cedil_sessions/view/1484
リアルタイムGCの実装が凄い

**デフォルトの名無しさん** · 2016/10/22(土) 08:52:04.68

GCもハードウェアに支援させれば全部解決するよ
リアルタイム処理含めてね

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

再起動最強説

**デフォルトの名無しさん** · 2016/11/14(月) 22:33:26.01

固定領域として静的にグローバル変数化、バッファ化すればいいだろ、
それを汚い言うやつがいるが、

潜在ＢＵＧだらけでどうにもできないそれのほうが汚いわ。

**デフォルトの名無しさん** · 2016/11/14(月) 23:45:18.91

例えばChromeとかFirefoxとかが静的にメモリアロケートしてたらどうなるか

**デフォルトの名無しさん** · 2016/11/14(月) 23:59:22.37

そういう発想、嫌いじゃないよ
静的にできるものは、なるべく静的にすべし
俺もそう思う
妙なからくりじみたことにはもう興味が湧かなくなった
最初のころはGCのメカニズムが面白いと感じていたが、もうそういうの、無い

いかに静的にシンプルに書くか、こっちのがパズルみたいで面白い
すべての事は明確であるべきで、コードはそのようになっているべきだ、と
俺が特に嫌いなのは、何がどの順番に実行されるか、コードを見ただけで
よくわからない類のプログラムだ
コールバックも基本的に嫌いだ
なのでいつ実行されるか分からないマークスイープGCは好きではない
参照カウンタ方式のほうが根本的に安全であり、シンプルであると思う
というのも参照カウンタ方式のGCはバグの再現性があるから
唯一の問題は循環参照だが、これも弱い参照を使えば解決する
たったそれだけの工夫でマークスイープGCの複雑な仕組みがいらなくなるなら
おれはそちらのほうが良いと考える
開放するというただそれだけのことに、あれだけ巨大な仕組みが必要になるのはおかしい

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

マークスイープ系GCはメモリ管理に関しては完璧かもしれないが
それ以外のリソースの面倒は一切見てくれない
そういったものはファイナライザで開放すればよいわけだが
要らなくなったらすぐさま開放してほしい時に困るので、例えばC#ではDisposeを用意している
しかしながら根本的に本当にDisposeを呼んで良いのかは誰にもわからない部分がある
もしかしたら他の誰かが使用中かもしれない、という場面もありうる
だから誰も使ってないことをプログラマが保証する格好になる
その意味ではfree()と大差ないわけで
usingという構文が用意されていて、ある程度自動で呼ばれるというだけである
本当に誰も使ってないことを保証するにはマークスイープを走らせなければわからない
しかしマークスイープはコストがかかるので、そんな都度都度気軽に走らせられない
その点、参照カウンタ方式は参照カウンタを見るだけで使われているかどうかわかるので
都度都度チェックできるし、要らなくなったらその場で即開放できるので
Disposeのような仕組みもいらず、解放処理をデストラクタに一本化できるし
スマポを使えばデストラクタ自体、書く必要すらないかもしれない
そして有り難いことに、デストラクタはメンバ変数やベースクラスに対しても
芋づる式に自動で呼ばれる
これはDisposeには無い機能だ
何故無いのか？答えは、勝手にDisposeして良いのかどうか、コンパイラは判断がつかないからだ
誰か他の人が使っているかもしれないわけで、勝手にDispose出来ない
Disposeして良いかどうかはプログラマが保証しなければならないので自動化できないのだ

**デフォルトの名無しさん** · 2016/11/15(火) 00:02:48.22

本当にC#で解放処理をまともに書こうと思うと
自身のクラスのメンバ変数にIDisposableを実装しているものがあるかどうかを調べ
もし、実装しているものがあれば、自身もIDisposableにし
Disposeメソッドを作り、その中で、先ほど調べたメンバのDisposeを呼び出さなければならない
これを手作業でやる
C#をやったことのある人なら知っている通り、マイクロソフトの示すIDisposableの実装例自体が
非常に煩雑であるわけだが、ともかく、もれがないように、手作業で頑張る
まず、IDisposableかどうか調べ忘れるだろうし、Disposeの呼び出し忘れもありうる
mallocしたらfreeしましょうと同レベルのことを強いられる
このように面倒なIDisposableであるが
IDisposableなオブジェクトをメンバに持つと、自身もIDisposableになるということは
IDisposableはどんどん伝染していくわけで、手動でDisposeしまくるコードを書き続ける羽目になる
このように、まじめに考えると、破たんした方法であることが分かる
根本の問題はDisposeが自動で呼ばれるコードをコンパイラが生成してくれないこであるが
確実にDisposeして良いかどうかを判断するためにはマークスイープを走らせる必要があるので
どうやっても自動化は困難であり、プログラマが開放してよいことを保証するという
ある種手作業なusingがせいぜいである
参照カウンタ方式であれば、ほぼノーコストで開放して良いかどうか分かるので
これらの問題は一切発生しない
解放処理はデストラクタ一本であるし、芋づる式に自動的に呼ばれるので
手動でコードを書かなければならないということもない
ランタイムもシンプルであり、バグった時も再現性が期待できる

**デフォルトの名無しさん** · 2016/11/15(火) 00:24:03.03

これがC++が未だにかたくなにマークスイープ系GCを搭載しない理由である
C++を書くプログラマはweak_ptrを適切に使えるものだという前提のもとに
マークスイープ系GCにまつわる数々の問題点を排除したのだ
マークスイープ系GCで有利なのは唯一循環参照だけであり
そこさえ気を付けることができれば
それ以外の部分に関しては参照カウンタのほうが優れている
C++は別に時代遅れなわけじゃなく、そういう選択をしたというだけ
今になって考えるとその選択は正しかったと思う

**デフォルトの名無しさん** · 2016/11/15(火) 04:04:15.16

メンバーにdisposeしなければならないような設計が良くない。そんなものはメソッド内のローカル変数に止めるべき。
それすらも理解できず(考え付かず)にただ一律なんにでも同じ考え方を押し込むのはただの愚行。
ありもしない、回避可能な杞憂をただ恐れるのは、勉強不足か進歩が止まっているだけ。
だから皮肉を込めて老害と呼ばれる

**デフォルトの名無しさん** · 2016/11/15(火) 04:09:46.64

日本語おかしかった。
メンバーにdisposeしなければならないような物を持たせるのが良くない
でした。

**デフォルトの名無しさん** · 2016/11/15(火) 05:19:19.06

>>594
参照カウンタよりも固定バッファを動的に確保ですね判ります

**デフォルトの名無しさん** · 2016/11/15(火) 05:20:35.14

>>595
firefoxは解放が遅いのでそれやってるのと実質同じ
realplayerとかもそうだったな

**デフォルトの名無しさん** · 2016/11/15(火) 08:18:37.29

>>600-601
よくないって言われてそうせざるを得ない場合はいくらでもあるしなぁ
例えば動的に出力先を切り替えられるログクラスみたいな奴をどう書けと言うんだろ？

**デフォルトの名無しさん** · 2016/11/15(火) 09:05:11.25

>>597
スマポとデストラクタの必要性は関係ないだろ…
deleteの必要がない、とか、デストラクトを考えなくて良いってことだと思うけど。

**デフォルトの名無しさん** · 2016/11/15(火) 10:48:15.69

スタック変数の 0 クリアすら嫌がる C/C++ が GC 搭載とか夢見すぎ

**デフォルトの名無しさん** · 2016/11/15(火) 10:53:43.30

struct test
{
　　std::shared_ptr<int> ptr;
　　test(){ ptr = new int; }
};

上のコードはデストラクタを書く必要があるのかないのか
スマポを使えばデストラクタを書かなくてよい場合もあり得るということ
スマポを使わないのであれば当然デストラクタでdeleteをしなければならないだろう
なので、「スマポ」と「デストラクタを書く必要性」は、関係がある

ちなみにC#のDisposeはただのメソッドであるので
このような芋づる式にメンバ変数のDisposeを呼び出してくれる機能はないし
マークスイープなので原理上不可能である
他で使用中でないことをプログラマが保証しないとにはDisposeは呼べないので
自動化できない

**デフォルトの名無しさん** · 2016/11/15(火) 11:05:47.46

>>606
ツボったw
効率至上が利点であり特徴だもんな

**デフォルトの名無しさん** · 2016/11/15(火) 12:45:52.53

>>607
それptr.reset()使うんじゃないの？

**デフォルトの名無しさん** · 2016/11/15(火) 13:34:38.18

グローバルが嫌われたのは
疑似マルチプロセスでメモリを共有していた時代の汚物だろ
今みたいなOSのメモリ管理ならアプリ単位グローバル常套

**デフォルトの名無しさん** · 2016/11/15(火) 23:45:20.82

C#/C++よりRustだろ
参照カウンタのオーバーヘッドすらない
Firefoxに期待

**デフォルトの名無しさん** · 2016/11/16(水) 04:04:29.47

>>604

http://ideone.com/9L3kQp

これじゃいかんのか？
おかしかったら教えて

**デフォルトの名無しさん** · 2016/11/16(水) 12:42:03.97

>>612
Write する度に WriteTypeA とかを生成/破棄するってこと？
ログとかならその方が望ましいケースもあるかもしれないけど、例えば性能上の問題でストリームは開きっぱなしにしたいとかもあるでしょ

**デフォルトの名無しさん** · 2016/11/16(水) 14:56:37.10

>>613
開きっぱなしにしたいスコープは？
スコープを一つのメソッドにして、同じようにすればいいじゃない

コードが必要なら夜にでも書くよ

**デフォルトの名無しさん** · 2016/11/16(水) 19:17:42.21

>>614
スコープを動的に変えたい場合を想定してるんだが
実行中にログファイルを変更できるアプリケーションとか見たことないの？

**デフォルトの名無しさん** · 2016/11/16(水) 23:34:22.54

>>615
ログファイルであれば日付で切り替えとかあるね。

そしたらストリーム開きっぱで日付が切り替わったら、閉じて新しいの開き直すとかあるわ。

いつもlog4とか使って主処理と切り離してたから考慮から抜けてたわ。

俺の意見はdb接続とかで一部にしか当てはまらんので、
「基本的には」とか
「リソースを管理する必要があるもの」とか前提がつくね。すまん。

**デフォルトの名無しさん** · 2016/11/19(土) 06:41:14.49

ログファイルはログが確実に記録されるのが使命であって性能は二の次なのだよ
よって開きっぱなしは論外
性能で問題が出るなら吐く量を調節すればいいだろう

**デフォルトの名無しさん** · 2016/11/19(土) 08:38:51.71

開きっぱはなんでダメなん？

**デフォルトの名無しさん** · 2016/11/19(土) 08:52:00.55

flushすればいいな

**デフォルトの名無しさん** · 2016/11/19(土) 10:16:22.36

>>618
アプリケーションエラーとか異常終了した時にバッファされてる内容が書かれないことがあるから
異常終了した時はまさにそのエラーになる直前のログが欲しいのに～
ってなる w

ただログってそういうログばかりじゃないし Apache のアクセスログみたいにいちいち閉じてたら全然間に合わないって現実を知らない >>617 はもう少し経験積むまで黙ってた方がいいと思う

**デフォルトの名無しさん** · 2016/11/19(土) 14:20:53.96

>>620
それは開きっぱなしが問題なんじゃなくてflushしてないことが問題なだけで見当違い

**デフォルトの名無しさん** · 2016/11/19(土) 14:29:51.71

>>621
>>604 から読み直せよ
見当違いはお前の方だよ...

**デフォルトの名無しさん** · 2016/11/19(土) 14:34:26.96

とこのように、相手を互いに見当違いであると罵り合うのであった
しかし、それは正しい
両者とも正しい

**デフォルトの名無しさん** · 2016/11/19(土) 15:37:17.31

スコープの話してるのに flush とか頭わいてるだろ

**デフォルトの名無しさん** · 2016/11/19(土) 21:51:13.35

null安全をアピールしてる人間はObjCerから見ると補助輪付き自転車を渡してきてこれ安全だから絶対に乗れよと言ってくる頭おかしいおじさんにしか見えない
Swift移行がこじれるだけだから黙っといて欲しい

**デフォルトの名無しさん** · 2016/11/21(月) 14:59:21.88

浜矩子・著
『アホノミクス完全崩壊に備えよ』
『どアホノミクスへ最後の通告』
『みんなで行こうアホノミクスの向こう側』

抑制のない成長に基づく経済政策は終焉

日本国民はどう対処すればいいのか。
新しい政権は民意を反映し、
食糧、住宅、健康、教育、最後に防衛です。
国民の意志を裏切ることは、
極端な場合、自殺や殺人にまでつながります。
民衆の指導者は
職業的政治家ではない人々から見つかるのです。

世界平和の脅威は、
イスラエル、イラン、アメリカです。
イスラエルの役割は跪いて、
パレスチナに許しを請うことです。
アメリカによる他国の虐待に
反対の声を上げなければなりません。
彼らは今世紀（21世紀）を
この帝国が出来上がるアメリカの世紀と呼ぶ。
しかし、そうはならないでしょう。
彼らが世界中に‘民主的’制度を確立したい
という衝動(世界を支配する)をコントロール
するのは、マイトレーヤの任務です。

非常に間もなく
マイトレーヤをテレビで見るでしょう。
彼は「匿名」で働いております。

**デフォルトの名無しさん** · 2016/12/08(木) 09:10:56.35

小規模ならGCのメリットは大きいのかもしれないが、大規模または大量にメモリを食うプログラムにはGCは向いてないのではないか。

あんまり例を知らないが、JAVAで動くマインクラフトのデバッグ画面でメモリ使用量みたら、めまぐるしく増加して一気に減ってるのみてびっくりした。

**デフォルトの名無しさん** · 2016/12/13(火) 13:02:48.84

GC周りに付いて書かれたネットの記事読んできたけど
オブジェクトが生成されては次々と死んでいき
生きてるオブジェクトより死んだオブジェクトが多い場合の方が速くなるっぽい

>>627
そう考えると長命のオブジェクトが大量にある方が(性能的には)問題だが
マインクラフトがそれかは知らない

**デフォルトの名無しさん** · 2016/12/15(木) 23:33:53.51

>>606
C++はGC支援のメモリモデルが標準に入った
と言ってもコンサバGCライブラリ向けだけどな

**デフォルトの名無しさん** · 2017/01/18(水) 11:38:56.79

漏れたときの調査が大変
安心してると痛い目にあう

**デフォルトの名無しさん** · 2017/01/20(金) 16:23:16.03

参照カウントは循環参照の問題が起こるだけじゃなくて
意外と遅いって聞くけどマジで？

・メモリをOSから直接確保・解放するのは意外と遅い
・マルチスレッドで参照カウントを使うにはアトミックな操作が必要
・カウントを自動化すると不必要な参照カウントが起こる
とかで

対してトレーシングGCの弱点は回収時に止まる時間が長いところか

その対策か、V8やOracle JavaにはGCの時間を制限する機能があるみたいだが
それってどうなんだ？

**デフォルトの名無しさん** · 2017/01/20(金) 23:17:39.79

まじ

**デフォルトの名無しさん** · 2017/01/22(日) 15:00:56.26

^ナマポ

**デフォルトの名無しさん** · 2017/01/22(日) 18:20:35.13

ストップ・ザ・ワールドの問題さえなくなればGCが最強ってこと？

**デフォルトの名無しさん** · 2017/01/22(日) 18:44:59.67

>>634
フルGCの危険があるという点で最強になりえない

**デフォルトの名無しさん** · 2017/02/20(月) 19:16:44.90

バイオハザード7は28万行のC#コードでできててビルド10秒らしい。
独自VM、独自GCだとか。

**デフォルトの名無しさん** · 2017/03/20(月) 22:46:15.84

>>636
ゲームで28万ステップって長すぎね？

**デフォルトの名無しさん** · 2017/04/01(土) 12:49:43.55

バイオの資料見つけた。
https://www.slideshare.net/mobile/capcom_rd/re-engine-72302524

FrameGCって独自アルゴリズムなのか。

**デフォルトの名無しさん** · 2017/05/26(金) 12:05:46.50

>>638
FrameGCはゲームというかRTSに特化したGCだね

・ローカルに発生したオブジェクトは溜め込んでフレームの終わりにまとめて開放する
・グローバルに結びついたオブジェクトにはカウンタGCを適用する
・フレーム毎に循環参照のチェックを少しずつ行う

ざっくりこんな感じ？

**デフォルトの名無しさん** · 2017/05/26(金) 20:16:13.14

内部的にC#をC++に変換してるからC#をスクリプト的に使ってるだけで実質C++だな。当然GC・メモリアロケータ周りも身内実装。

**デフォルトの名無しさん** · 2017/05/26(金) 22:20:13.64

>>640
C++のスマートポインタみたいな形で実装できるのかな？
俺は検討してみたけど無理だったw

**デフォルトの名無しさん** · 2017/06/03(土) 06:38:16.81

そこまでやって既存のフレームワーク使えるのって疑問が。

**デフォルトの名無しさん** · 2017/06/03(土) 10:06:08.23

GCがconflictするんですね判ります

**デフォルトの名無しさん** · 2017/09/11(月) 12:41:54.43

「メモリ」+「フラグメンテーション」で検索すると色々と詳しい話が出てくるね。

**デフォルトの名無しさん** · 2017/09/11(月) 13:14:06.52

ここが分かりやすかった

ttps://www.uquest.co.jp/embedded/learning/lecture17.html
ttp://www.kaede-software.com/2015/06/post_655.html

**デフォルトの名無しさん** · 2017/09/11(月) 13:44:59.20

メモリのフラグメンテーションなど実質的には気にする必要は全くない
なぜなら現実のコンピュータにはMMUが付いてるから
物理メモリの連続空間が枯渇することは考えなくてもよい
あり得るとしたら32bitプロセスでの論理アドレスの連続空間の枯渇であるが
64bitプロセスにすれば問題ない
もともと論理アドレス空間が枯渇するかもしれないほどメモリを使うのなら
64bitプロセスにするのが当たり前なので・・・
というわけでメモリのフラグメンテーションは気にしなくてよい
CPUのキャッシュのヒット率を上げるとか、そういうことでなければ

**デフォルトの名無しさん** · 2017/09/11(月) 17:53:09.29

そうなん？
ガベコレの回収効率が悪くなって
無駄な使用領域が増えて枯渇しやすくなるんじゃね

**デフォルトの名無しさん** · 2017/09/11(月) 18:13:16.59

>>647
GCのアロケートサイズとページングサイズの区別もついてないアホはスルーでよろしく

**デフォルトの名無しさん** · 2017/09/11(月) 20:33:05.66

程度の問題であって
世のプログラムがフラグメンテーションなど気にせずとも
普通に動いているのを見てわかる通り、問題になってない
MMUがあるから

**デフォルトの名無しさん** · 2017/09/11(月) 21:54:05.93

>>646
そういうぬるい環境で済むところもあればそうじゃないところもある
ゲームコンソールだと物理メモリサイズに最適化するからな
STLとかdefault allocatorで気軽に使ってヒープ汚しまくってると
そのうち物理メモリ足りなくなってページアウト

**デフォルトの名無しさん** · 2017/09/12(火) 10:09:32.99

必ず来ると思った、その反論
しかし、稀な事例を持ち出して、どうこう言っても仕方がない

**デフォルトの名無しさん** · 2017/09/12(火) 12:38:17.20

MMU のお陰でふらぐめんてーしょんが起きない環境の方が希だと思うが

**デフォルトの名無しさん** · 2017/09/12(火) 13:22:19.16

フラグメンテーションはアドレス空間や実メモリ量が限定される環境をどううまく使うかの話だから
MMUがあって64bit空間なら平気と言われてもな

**デフォルトの名無しさん** · 2017/09/13(水) 03:53:58.25

そそ、複雑なプログラムって書こうと思えばいくらでも複雑化するからな。
で、簡潔で高度と思われる機能を追加していくほど難易度は指数関数的に増大するし。

**デフォルトの名無しさん** · 2017/09/13(水) 05:10:44.22

でも実際スマホアプリ作ってんのにフラグメンテーションを防ぐ為に最初に使用する分全部確保しておいて、その中で割り当てするんだーとかいって、オレオレアロケーター作ろうとする頭の悪いやつがいて困る。
逆にお前の作ったそのアロケーターの中でフラグメンテーションして枯渇するわと。

**デフォルトの名無しさん** · 2017/09/13(水) 07:42:12.50

組み込みなんかでよくあるそういうのは、どっちかというと最初に確保したメモリ以上を
使用しないことを保証するためにやるもんだろう。

**デフォルトの名無しさん** · 2017/09/13(水) 08:52:01.48

アロケータ置き換えるだけでは普通解決しないでしょ
>>655 こそが置き換えて何するのか理解できてない気がする

**デフォルトの名無しさん** · 2017/09/13(水) 22:09:52.04

むしろ一定時間を保証する（なのでサイズは固定長とかが多い）もんだろ

**デフォルトの名無しさん** · 2017/09/17(日) 13:06:26.21

いくら64bitあっても設計が雑ならメモリ枯渇するでしょ
ページング方式でメモリ消費されてんだし

**デフォルトの名無しさん** · 2017/09/17(日) 13:32:06.14

MMUのアドレス変換コストもタダじゃない。
TLBキャッシュ外れたら遅くなる。

**デフォルトの名無しさん** · 2017/09/17(日) 13:32:07.34

1回のメモリ取得で4kづつ消費されるわけか

**デフォルトの名無しさん** · 2017/09/17(日) 13:49:19.58

ツリー状のメモリ管理するとあっという間にメモリ無くなるな
class CTree{
std::vector<CTree>;
};
とか

**デフォルトの名無しさん** · 2017/09/17(日) 14:00:55.72

こうするとさらにメモリが消えていくな
class CTree{
std::map<std::string,CTree>;
};

**デフォルトの名無しさん** · 2017/09/17(日) 14:12:30.87

間違えた。

class CTree{
std::vector<CTree> m_Tree;
};

class CTree{
std::map<std::string,CTree>m_Tree;
};

で、ツリーのノード一つ毎に上は4kづつ下は8kづつメモリを消費するわけで・・・

**デフォルトの名無しさん** · 2017/09/17(日) 15:23:52.56

一回のメモリ取得で4KBってのが嘘だから意味が無い話だね
MMUついてたって、そんなアホな実装は無い

4KBだかの1ページ分の中での細かなメモリ断片化はおおむね無視できる、ということ
メモリ断片化で困るのは大きなサイズのメモリを確保しようと思ったとき
連続したアドレスが確保できなくてコケる、ということだからね
これに対してMMUは有効ということ
メモリが断片化で多少無駄遣いされる分にはスワップしてでも動くから

そんでこれは程度問題
大概の場合は問題にならない

**デフォルトの名無しさん** · 2017/09/17(日) 15:38:01.00

https://ja.wikipedia.org/wiki/動的メモリ確保
＞また、粒度の細かいページングは、ページングテーブル
＞(物理アドレスと論理アドレスの対応表)が大きくなるため、
＞4KB程度の大きなブロック単位でしか割り当てることができない。

ウィキペディア見るとそのアフォな実装がまかり通ってると読めるんだが・・・

**デフォルトの名無しさん** · 2017/09/17(日) 15:48:55.35

アホだなぁ
OSレベルのメモリ確保と言語レベルのnew、mallocは別

**デフォルトの名無しさん** · 2017/09/17(日) 16:00:06.71

こっちも参考になる
https://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%A2%E3%83%AA%E7%AE%A1%E7%90%86%E3%83%A6%E3%83%8B%E3%83%83%E3%83%88
CPUによってMMUの実装が異なる点は面倒だな

**デフォルトの名無しさん** · 2017/09/17(日) 16:06:24.06

>>667
ちゃんとmallocやnew時のアドレス確認はしたか？？かなりアフォな動作してるぞ？
まあ、多少のrealloc程度の処理なら何とかしてくれるけどな。

**デフォルトの名無しさん** · 2017/09/17(日) 16:13:26.66

mallocやnewは
大きなサイズを確保するときと
小さなサイズを確保するときで
アルゴリズムが切り替わる

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

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