[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
316(1): デフォルトの名無しさん [sage] 2015/12/20(日) 14:51:52.93 ID:i39XsMQ2(3/5) AAS
だから同時に書く設計が悪いんだって
気合入れて設計を見直してみろ
そんな必要はないってわかるから
318(2): デフォルトの名無しさん [sage] 2015/12/20(日) 15:17:45.93 ID:14eB8c4R(1) AAS
>>315もはやGCがどう関係するのかわからない
425: デフォルトの名無しさん [sage] 2016/03/27(日) 10:12:42.93 ID:Ap0rkncx(1) AAS
schemeにはdynamic-windみたいな他所に継続が飛んでも後処理が保証される仕掛けがあるし
デストラクタがない==RAIIできないにはならないと思うの・・・
516(1): デフォルトの名無しさん [sage] 2016/04/24(日) 01:18:30.93 ID:9YSuZOIq(1) AAS
>>512512(1): デフォルトの名無しさん [sage] 2016/04/23(土) 00:19:34.35 ID:43LRl8T1(1) AAS
そもそも、ページサイズより粒度が細かいフラグメンテーションにはMMUはなんの効果もないしな。
お前のプログラムはメモリを1ページしか使わんのかｗ？
フラグメンテーションで使用率が低いスカスカのページだらけになるのが問題なんだろうが。
650: デフォルトの名無しさん [sage] 2017/09/11(月) 21:54:05.93 ID:khvQxUtn(1) AAS
>>646646(1): デフォルトの名無しさん [sage] 2017/09/11(月) 13:44:59.20 ID:I3u+9T/v(1/2) AAS
メモリのフラグメンテーションなど実質的には気にする必要は全くない
なぜなら現実のコンピュータにはMMUが付いてるから
物理メモリの連続空間が枯渇することは考えなくてもよい
あり得るとしたら32bitプロセスでの論理アドレスの連続空間の枯渇であるが
64bitプロセスにすれば問題ない
もともと論理アドレス空間が枯渇するかもしれないほどメモリを使うのなら
64bitプロセスにするのが当たり前なので・・・
というわけでメモリのフラグメンテーションは気にしなくてよい
CPUのキャッシュのヒット率を上げるとか、そういうことでなければ
そういうぬるい環境で済むところもあればそうじゃないところもある
ゲームコンソールだと物理メモリサイズに最適化するからな
STLとかdefault allocatorで気軽に使ってヒープ汚しまくってると
そのうち物理メモリ足りなくなってページアウト
684: デフォルトの名無しさん [] 2017/09/17(日) 22:27:01.93 ID:S40DCpdn(18/20) AAS
あと、動的配列ってのを作って、複数のメモリ取得に対応させた。
メモリにヘッダとフッタを用意して、フッタには複数配列のデータに対応させ、
ヘッダには配列数とメモリサイズを入れてる。フッタには>>682682(1): デフォルトの名無しさん [] 2017/09/17(日) 21:59:59.26 ID:S40DCpdn(16/20) AAS
自分はメモリ対策プログラムを作って対応したけどな。
メモリサイズを三種類用意して、メモリに対するガードの確実な作りにした。
現在のサイズに使われてるサイズにリミットサイズの三種類のサイズな。
外に出てくるサイズは現在のサイズ、
使われてるサイズはメモリを増やした場合の最大取得サイズで、事実上の取得サイズ、
リミットサイズは取得できるメモリの上限。
で、これらを組み合わせてスーパークラスを作って基本的に対応させてる。
のデータを持たせた。
ある意味では拡張コンパクションみたいなモノになった。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.028s