Garbage Collection (GC)について語るスレ

GCの理想と現実について語ってみない？

Javaは糞

>>2
「何故なら」と説明しないのはただの中坊でしかないぞ。

「アドレスラインがシンボルを表現できる程あればGCいらないのに」
と５文字のラベル時代に妄想したことがある(w

このスレッドはゴミと判断されました。

私はエデンの園にいました。

やがて時が経つと我が世界の時を止める悪魔がやってきて、
私を掴んで下界へ投げたのでした。

　　　　　　　　　　　　　　　　　　　　　　　　　　　〜ガベージコレクション伝

Garbageってなんか強そう。
必殺技みたい。

GC がスレッドと相性が悪いのはどうにかならないかな。
このスレッドは GC を組む人向けって事で良いのかな。

取り敢えず、初心者向けの GC 実装のポインタｷﾎﾞﾝ。

原音聞くとどうしたってガーベジなのに
何で日本ではガベージなの？

オレはガーベジコレクションいうてるけど

俺は　ジーシー　または　ガベコレ　と呼んでる。

GCはソースコードを荒らす事無く解放のタイミングを最適化できるんで
結構肯定的に見てるんだけど、更に一歩進むにはコンパイラとの連係
がミソかな？って気がしてる。
同一クラスの生成と解放が続く場合、スコープを抜けても参照元を失
っても敢えて解放せずに残しておいて次の生成を省略し再利用する様
にするだけでも効率が相当よくなる。
ソースコードで同じ事をしようとすると、フローの複雑さに比例して保守
性がズルズルと低下するから、GCの利点がより映える。

>>8
初心者向けってどういうGC指してる？
仮想マシンとか構文木のまま実行するインタプリタのとか生Ｃから使うとかの違い？
それともスレッドの話が出てるからSELFとかの実装の方？

MLKit の Region Inference は後続が出て来ないけど、やっぱり困難なのかな。

inference自体は困難ではないけど、採用するGCの方式との絡みによる。

ガービッジコレクションは二流の象徴

誤爆?

馬にいるんだよ。ガービッジって二流の馬が。

intelはPauseless GCの機能をCPUに組み込んでくれないかな。

なんでCPU？
てかメモリコンパクションをしてるから
排他しなきゃやばいでしょ

GCの利点はコーディングのしやすさより
むしろこのメモリコンパクションにあるんだと思ってるし

http://www.nminoru.jp/~nminoru/java/cms/pauseless_gc.html
いやコレ見るとCPUにそれ専用の命令割り当ててるみたいなんだよね。
CPU全体の構成を大幅に変えるな必要があるならいらないけど、
もし命令付加でできるならやってくれんかなあと。

GCは必ずしもメモリコンパクションをするものではないけど。

例えばBoehm　GCもRubyのGCもメモリコンパクションはしない。
原理的にムズイから。

保守的GCではムズイっていうか無理。
ポインタっぽい値がポインタじゃなかったら書きかえちゃまずいから。

不可能ではないので、ムズイ、であってます。

JaavやD言語はメモリコンパクションするはず
Dのバイナリってそんなにでかくないから出来ないこたない

>>25
アクセス方法に制限があるからできるのだよ。
たとえばヒープメモリが64bit境界で割り当てられてることを前提にして最下位ビットを値として使ったりすることは禁じられてる。

>>24
やり方教えて。大体でいいから。

GCはオシメの取れないガキへの救済措置。
時給70＄以上稼ぐプログラマはきっちり自己管理ができるし、出来なきゃクビだ。
ミサイルの弾道計算などはGCに頼ってる暇などないのだ。

お前と違って俺はアセンブラでも食えるからなぁ・・・

>>27
じゃあ大体で。書き換えてもいい奴だけ書き換える

>>28
2割の努力で8割を得る

>>30
書き換えてもいいってどうやって判断するんだ？

unary *じゃなくて別のアクセス方法使うってことで一段挟めばできなくもないが
アクセスが遅くなるし、回収しそこねを防ぐために表現をできるだけユニークにしないと
いけないので BoehmGC式が一番だとは思う。

>>32
>で一段挟めばできなくもないが

不可能じゃないと認めたな。

>どうやって判断するんだ？
方法なんざ選ばなけりゃいろいろあるがな。考えてみ。

断片化してるメモリをCPUが仮想的に直列化してくれると
簡素な実装でそこそこ以上の実行速度が得られたりは
しないかな？

>>33
認めたけど...
Boehmは速度の邪魔にならないようにCにGCを組み込むってことだから無理でしょ
Rubyは単に Mark and Sweepだから。

>方法なんざ選ばなけりゃいろいろあるがな。考えてみ。
うーん、全然分からん。っていうか書き換えてもいい奴だけ書き換えるっていっても
そこ指してるやつ全部書き換えなきゃいけないわけだから、破綻してる気がする。

>>35

>Boehmは...

>23 名前：デフォルトの名無しさん[sage] 投稿日：2006/03/07(火) 23:25:57
>保守的GCではムズイっていうか無理。
>ポインタっぽい値がポインタじゃなかったら書きかえちゃまずいから。

>うーん、全然分からん。

30分も考えてないじゃん。考えてない。脳が退化してるんかいな。

>>36

>From: [22] デフォルトの名無しさん <sage>
>Date: 2006/03/07(火) 23:02:16
>
>GCは必ずしもメモリコンパクションをするものではないけど。
>
>例えばBoehm　GCもRubyのGCもメモリコンパクションはしない。
>原理的にムズイから。
>_____________________________________________________________________________________
>
>From: [23] デフォルトの名無しさん <sage>
>Date: 2006/03/07(火) 23:25:57
>
>保守的GCではムズイっていうか無理。
>ポインタっぽい値がポインタじゃなかったら書きかえちゃまずいから。
>_____________________________________________________________________________________
>
>From: [24] デフォルトの名無しさん <sage>
>Date: 2006/03/07(火) 23:30:09
>
>不可能ではないので、ムズイ、であってます。

>>38
>From: [22] デフォルトの名無しさん <sage>
>Date: 2006/03/07(火) 23:02:16

>例えば
>例えば


>From: [23] デフォルトの名無しさん <sage>
>Date: 2006/03/07(火) 23:25:57
>
>保守的GCではムズイっていうか無理。
>ポインタっぽい値がポインタじゃなかったら書きかえちゃまずいから。

RubyってMark and Sweepで、メモリコンパクションせず、しかも遅いの？
これでJRubyのが性能いいとかだったら笑うな

保守的GCでも一段挟めば stop and copyで実装できるのは認めてる。
でもコストがかかるので Boehm GCでは使われてない。
Rubyはムズイんじゃなくて mark and sweepを選択しただけ。

書き換えていい奴だけ書き換えて、保守的GCでコンパクションする方法教えて。

Rubyってなんで保守的GCなんだろう? Cとの親和性?

GCをネイティブサポートする言語環境でシステムを実装していたら、
エヴァンゲリオンの最終回は第拾参話であったろう。

>>31
つまりGC搭載言語じゃおもちゃんこしか作れないってこったな。

GCに頼るということは
一時的なリークを許容するってことだよね。

だから、少しのリークも容認できないものには、
結局明示的に開放指示ださないといけない。

>>44
それじゃ逆向きの説明じゃないのか？

少しのリークも容認できないからGCを用いる。

>>45
一瞬のリークも容認できないものには、
結局、明示的にGCに対して解放の指示ださないといけない。

そういうパッツンパッツンのときは普通手でGCを起動するんじゃないか。
大抵の処理系は明示的にGCを起動できるでしょ。
GC起動するだけの方が全部の開放を適切に捕まえて書くより楽だけど。

Boehm GCの簡単な使い方を教えてください　＞_＜

それくらいgoogleに訊けば教えてくれるぞ。

どかんとメモリとって
そこを共用体として使えば
GC代わりになるんじゃね？

バカ度7強の発言来た

ん？なんの問題があるんだ？

バカ度8になった。被害は深刻化してます。

とりあえずマルチコアの恩恵をめちゃくちゃ受けるのがGC

だからGCの種類によるっちゅうに。

んなこたーない。コンカレント GC もパラレル GC もまだまだでしょ。
stop the world なのも多いし、現状ではシングル性能が物を言う。

>>56 は >>54 宛ね。

>>56
コンカレントGCとパラレルGCとマルチコアとシングルコアとで比べてみたの？

GCは補助輪付き自転車のようなもの。
いい加減大人になったらはずさないと。

それしか言えんのか

それで十分だし

>>58
ちゃんと比較集計した訳じゃないけど、日常的にマルチプロセッサのマシンを使ってるから。
マルチコアの恩恵をめちゃくちゃ受ける GC の設計理論があるなら教えて欲しい。

オライリーから
詳説GC
が出るのはいつの事ですか？

表紙は何だろうね。
掃除人？ふんころがし？ハイエナ？

>>64
スカベンジャーならなんでもありじゃないかな。

死肉食いっつーか
ゴミ集め、だろ

>>62
Javaは大幅に高速化してないか？

>>67
少ないメモリなら割と速く済むようになってきた。
でもめいっぱいメモリ積んで最大ヒープごっそりくれてやると

時が止まる

Javaがメモリ空間広ければ高パフォーマンスになるとは限らないのを
この間知ってちょっとショックだった。

>>69
ＧＣのパフォーマンスなら観察してパラメータ調整するのは常識化してる＜＜エンタープライズ用途

JavaVM は jstat とか、統計情報もちゃんと保持してるのが偉いよね。
チューニングも細かく設定出来るし。

スループットとレスポンス重視とえらべるし、調整が細かく可能なのがえらいよな

JavaはGCが現実的な速度で動くというのを証明してくれたというか

新世代のGCなんてちゃんとチューニングすれば1msもかからんしね
それと普段はFullGC発生させないようにプロファイラで監視するべき

それができないと>>68のようになる


昔Tomcat2つ立ち上げてとか笑える記事があったよなぁと思い出した

AP のインスタンスを複数上げるという事なら、普通にやってるよ。
SPEC とかはそれ抜きにはあり得ないし。

ちゃんと目的があって複数のインスタンスを立ち上げることは別にいい

ITPROだったっけ？GCがまともにチューニングで着なくてインスタンス二つにしましたと
自慢げにいってたやつ

だいたいメモリリークさせる事自体恥ずかしい事なのに
そのチューニングとかもうみてらんない

おしめはこう作ればうんこが漏れない、いやこうだ、とか言ってるようなもん。

一人前はそもそも漏らさない。
漏らさない奴にそんな手の込んだオムツ強制されても重苦しくて歩きにくい。
仕事にならないね。

>>75
寂しいヤツだな。ここで幾ら叫んでも、貴様の現実は改善しないぜ。

カベッジコレクションはまさにやろうとしてる事自体がゴミのように無駄な行為
名前通りの愚行

GCのご機嫌を取るためのノウハウを得る手間と、free/deleteをきちんとやる手間って
あんまり変わらないよな。ぶっちゃけ、そんなたいそうな機構をいれ、パフォーマンスを
多少犠牲にしてまで導入しないといけないようなものなんだろうか。

C++のようにクラスをヒープ以外にスタックや静的に配置できるなら、リークの発生は
かなり抑えられるわけで。

1mSecって凄まじく長い時間だと思う。

俺が思うのは「馬鹿にはとっても素晴らしい」ということ。
ただし自分は良くてもプロジェクト内に馬鹿がいるという状況も含める。

馬鹿が書くメモリリークを起こすコードを直すよりはGCを走らせておくほうがいいよ。

業務系ﾄﾞｶﾀにはGCというセーフティネットがないとな。

>>77-81
自作自演までしちゃって、哀れな男…

つか、C++ 厨か。時代に取り残されるって不幸だな。

>>82
あなたの当て推量は残念ながら外れです。
僕は77ですが78と79は知りません。

>>78
Javaの次のバージョンのVMではスタックに取るらしいよ

例えばどこにも参照を渡さないローカルインスタンスなら
スタックに取っておいて捨てるとか、newそのものを無視できるのかもね

>>85
もう少し詳しく。
C#にあるstackallocの様な構文が導入されるって事？
それとも、コンパイラが判断して自動で挿入するって事？

>>86のいうようにVMの自動判別
つまり、ソースコードはそのままで高速に動く

スタックでの割付の利点は短期寿命オブジェクトがヒープ使わないからGCの負荷が大幅にへるんだよねぇ
新世代は元々負荷たいしたことないけど

てか、おまえらなんでそんなにパフォーマンスが気になるんですか？
俺はGCのある言語しか使ってこなかったから、GCあって当然なんだけど、
ポインタってそんなにいいものなんですか？

main() {
Hoge *hoge;
init(hoge);
}

init(Hoge *hoge) {
hoge = new Hoge();
}

うそみたいなホントの話

>>91
エラーメッセージ(警告含む)の出ない行を予測するパズル?
空行を除くと、2行目だけはメッセージが出ないと思うのだが。

同じことがJavaではできない

>>91
小学生でもそんなリークコード書かねーよ。

出来るか出来ないかの違いを書いただけだが？
main終われば勝手に回収されるだろ

そういうのは Java スレでやってくれ。

>>95
OSによる。

>>90
時と場合による。
それと、GC要らない派はポインタだけを目当てにしているのではないはず。

ＧＣ付きの言語評価器を書く場合はＧＣ使えないわな

>>91
これはひどい。

>>87
C#では、stackallocは配列のみ、structは継承していないクラスのみ
スタックに割り当て可能だよな。
JDK 6.0では、実行時コンパイラがエスケープ解析を行うことで、
外部に参照が漏れていない、どんな配列・クラスもスタックに割り当て可能。

Javaはそろそろ次の奴にとって変わられそうだな。
これといって強み無いし。

>>102
そろそろってほどの期間ではJavaは死にようがないな
完全なオブジェクト指向言語でJava以上のものは未だ存在してない

D言語が気になってたが、あそこはβ版を弄り続けることに
意義を感じてるっぽいから興味も失せてきたなぁ

>完全なオブジェクト指向言語でJava以上のものは未だ存在してない

Javaが完全なオブジェクト指向言語？未だ存在してない？

C#はJavaのほぼ全てを内包してると思うが、
お前の「完全なオブジェクト指向」の定義は一体何なんだ？

どうせ説明できなくて逃げるに5#

DはC++の置き換え用途にはいいけどね
ただ、完成してないから次のコンパイルで同じ動作とはいえない
実用度という点では言語仕様完成して安定度が勝負だからまだスタートラインにすら立ってない

C#は実用的といえば聞こえはいいが、クラス指向としてみるとJavaのほうが使いやすいかと
プラットフォームの差もある

Javaは言語的にはプロパティと符号なしのプリミティブ型がつけばわりと万々歳
ガチガチの言語使用のおかげで最適化やツールが用意しやすいのが特徴か

あとはこれほどオープンソースのプロダクトが集まった環境はめずらしいね

>>103
> 完全なオブジェクト指向言語

そんなにSmalltalkerやらSelferやらを召還したいのか…
Objective-Cにも及ばん分際で…

　　　R　　u　　b　　y　　の　　予　　感

言語に特化したレスは各言語スレでやればよろし。

>>105
Class.newInstance()のお陰だろ
この手の機能のない言語は、
もうオブジェクト指向を名乗るのは許されないな

C#とJavaの決定的な違いって例外まわりかな

Monoが糞すぎて結局Win専用ってところじゃない？

CLOSこそが真のOO

>>106-112
スレ違い。

>>110
動作環境まわりだよ

ＧＣの利点

・ＧＣの動作を理解していれば非常に便利
・ＧＣの動作どころかプログラムレベルが低くても比較的安全に

世代別ＧＣになってからはまず欠点ねーな

世代型GCももう古いな
非同期式のGCがそろそろ登場してもいいはずだ

あと、GCの方が実行が早いって利点もあるね。malloc,free方式と比べて。

OSのヒープ呼び出しよりはさすがにね
最近はキャッシュがききやすいように配置しなおすとかもあるし

ただ、ヒープ拡張はGCと同時に起きるので非常に重くなることが予想される
Javaとかデフォの初期ヒープが非常に小さいので最初はGCが連発するので
初期ヒープを大きくしておくべきだ
そうしないと起動が遅いとか言われる羽目になる

GCがあるからメモリ管理をしなくてはいいというのは間違いで
アプリがどれだけのメモリを食うかはどんな環境でも知っておくべき

Javaならプロファイラも無料で使えるんだしね
どこがネックなのか一発で分かる

TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？

まぁ、これは俺のポリシーなんだが、GCは俺には必須だ。
オブジェクトの生成・解放はなるべく、やるなら同じ階層(レベル)でやりたいので、
そういう場合、オブジェクトを返すメソッドとかつくれなくなる。
オブジェクトを作って、メソッドにオブジェクトを渡してなんて、うんこみたいな事になる。

>>120
> まぁ、これは俺のポリシーなんだが、GCは俺には必須だ。
> オブジェクトの生成・解放はなるべく、やるなら同じ階層(レベル)でやりたいので、
すっごい矛盾してます（はぁと）

＞オブジェクトの生成・解放はなるべく、やるなら同じ階層(レベル)でやりたいので、
オブジェクト指向を1から勉強したほうがよさげ

Cでメモリの解法を考えるとバグが少ないのはたしかに同じ階層での解放だし
それは常識のひとつとされてたが、C++になってからオブジェクトのやりとりがはいると
それが見事に崩れ落ちる

同じ階層って意味分からないんだけど、
どんなケース？

マジでわかんないの？頭悪い人？

やるなら同じ階層で、でもそんなことは現実には無理、だからやらない→GC必須
ってことだろ

object の extent がすぐ手の届く範囲にあるなら GC 使う必要は少ないよな。

Object* obj = new Object();
delete obj;

を、
boost::share_ptr<Object> obj(new Object());
obj.reset();

に書き換えてくれるプリプロセッサがあったら、
GCなんていらないと思ったのですが、どうでしょうか。

んでC++withGCとか名乗る。

boost::shared_ptr<Object> obj(new Object());
obj.reset();

>>128
struct Object{
Object* obj;
};

Object* obj = new Object();
obj->obj = obj;

どうすんのコレ？

もちろんフロー解析して

boost::shared_ptr<Object> obj(new Object());
obj->obj = NULL;
obj.reset();

にしてください

>>131
意味違ってるじゃん。

>>132
その辺のチェックが落ちる解析かと…

いまさらスレを見た者ですが:
>>23 Mostly-Copying GCってのもあった。
ttp://web.yl.is.s.u-tokyo.ac.jp/meeting/doc/yoshinor2001_11_13.ppt
に書いてあるようだ。ちゃんと読んでないけど。

>>134
それJavaで4年位前から採用してるだろ

㋦㋸㋭°

みんな，青い本もってる？
もっといい本ある？

ない。

でも何度か改訂されているらしいよね。最初の版しか知らないけど。

青本しか知らない
あとは関連論文を直接あたってる

やっぱ論文をあさるしかないか．．．
論文って客観性が足りなくて鵜呑みにできないんだよね．．．
自分のやっていることはすごいんですみたいな．．．．
この分野に限ったことではないけどね．

そりゃ数読むしかないのでは?
後はACM computing survey

>>141
客観性のない論文ってのはありなのか？
普通はRejectされないか？

現実はそうなっていません。

ワシが大学を出てからだいぶんたつが、そんなに質の劣化が激しいのか？
人生の残りが半分切ったからなぁ。

投稿が少ないと、文章の構造だけで acceptしてるっぽい

世界中にゴミような論文が散在している．ph.Dもインフレ気味．
いろいろ調べる方としては，スパムメールよりもたちが悪い．
論文のGCが必要だよ．

レスコテハンに意味がないのを承知で聴きますよ。
>>146
最近人が急激に増えた情報科学系の話に限るとかそういう事じゃないのですか？
>>147
ph.Dがインフレなのは海外じゃないの？、国内だと事実上食えないって部分の方が大きいと思うのだが。

P.S.
全然関係無い訳じゃないけど、2chって板やスレによっては僕のような昭和30年代よりお年寄りが居ることもあるよ。
オフ会で70台の師匠に出会えて幸せを感じた145（ｗ

まあGCの論文なんて5年前で1000本以上でてるしねえ。
その大半がマージナルなものになるのは仕方がない。

主流の技術を語って

CPUとメモリの速度比
キャッシュ段数、容量
複数CPU間の同期機構
そのときメジャーなアプリ

このへんが変わるたびに前提が変わるんで
適当に研究し続けられる
ただ、数年（下手すると２年程度）で研究が陳腐化する

アコギな商売ですね

計算機の世界は、ほとんどがそんなもんだ。

いやだったら、理想計算機なんてもんを振り回せる、境目の数学屋よりの方へ
行くしか無いな。

主流の技術を語って

OS方面でも
スケジューリング
ファイルシステム
権限調整（サンドボックスアプローチとかそのへん）

なんかはその類だなあ
うわ、スレ違いだ

主流じゃなくて，クラシカルなネタだけど，
「コンカレントな環境で，いかにStopTheWorldを無くすか」
というのがやはり重要なのかも．
一般人でもメモリ何ギガの並列環境を使うのが当たり前になりそうな勢いだよね，
2コア，4コア...

でも，結局，肝のところはハードウェアで対応しちゃうのだろうから，
ソフト的にはほとんど進化なさそう．．．

あぁ，コピーコレクタを最初に知ったときのような感動を味わいたいよ．

それは主流だろ?
Realtime Javaとかさ。

256バイト1ページでページ単位にＧＣとMMUによるアドレスの再マップとかしたら却って鈍かったorz

いまの時代に256バイト単位はないだろ

>>159
実験だからね〜。
つか32Mしか積んでないし@Mips R4000のワンボードだし

32Mで256バイト/ページってことは、えと･･･
よん？

gcされないように上げてみる

sageてるじゃねーか

保守的GC

革新的GC

闘争的GC

どれもメモリ内容の一貫性は保証しません

消えたり宙に浮いたりします。

http://www.premiumtv.12gbfree.com/?YTV=Blue+Man+Group+Summer+Sonic

http://www.premiumtv.12gbfree.com/?X3/?YTV=gstarr1266+Blue+Man+Group+Christmas+Lights

手軽にＣＧ
http://www.premiumtv.12gbfree.com/?rSTV=%E7%97%9B%E8%BB%8A

C++用GCライブラリらしい
http://18.real-sound.net/~fanzo/Real/xoops/

invariantによる議論がちっともないところを見ると不安で使えないなあ。
GCはバグの特定が容易でないのできちんとした理論的な検討が重要。

・対象クラスがgc_obj_baseを必ず継承せねばならない
・使用時はスマートポインタのようなi_obj<ClassName>を使う必要がある

この２点だけで、俺はもうだめだ。
循環参照しなければ、スマポの方が圧倒的に簡単で便利そう。

参照カウントとマーク＆スウィープの比較だったよね？

GCの圧倒的利点は、あれだろ
ヲマイラの所にもいるの斜め上のあいつのバグに悩まされるのが減るってことだろうよ。

おめーのバグだろ(#ﾟДﾟ)ゴルァ!!

藻前らWikipediaも見てないなんて、サーベイ不足も良い所ですね。
C++にはあと二年以内に、言語仕様としてデフォで透過的なGC「の実装サポート」が入りますよ。
http://en.wikipedia.org/wiki/C%2B%2B0x#Transparent_Garbage_Collection

GCがフルで入るはずだったが、上記URLのとおり、0xより[あとでやる]に切り替わったらしいね orz
それでも相変わらずBohemﾀｿらが、「最小限のGCサポートとReachabilityベースのリーク検知」と
名前を変えて、標準に入れるべくがんがってるぽい。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2481.html


さて、C++/CLIでも使うか。

二年以内に入るなんて書いてないが？
今、提案の最低限の機構だって入るかどうか分からないし。

>>177
>>179というわけでWikipediaも最新の動向を追い切れていない。残念だけど。
Wikipediaしか見ていないのも調査不足だよ。

>>177
exportなんざからっきしだしtemplateだってようやっとなのに本当に全部実装したコンパイラなんか出てくるのかね？

exportはなかったことにされてます。
後は実装されると思いますが、(実際既に実装が追っているし)
gc関連はC++0xには入らないでしょう。
そもそも2007最後のミーティングで議題から外されてますから。

>>178
「0x」って文字読める? 確かにずれ込むこと考えたらまぁ、何十年後か分からんが。
「入るかどうか分からない」「二年いないかどうか分からない」と言ったら、もうなにも言えない。

もっとも俺の表現は断定的すぎた、ｽﾏｿ。
そう議論されているんだから、入るだろうと予測するのがまっとうだと感じたまで。
この時期にGCのフルサポートを削って「Minimal」を残してるんだから、後者は入る可能性が高くなったと印象を持った。

>>179
「しか見てないのも調査不足」はその通り。俺みたいな、一ページしか読んでないヒヨッコより頼りになるC++ハカーはたくさん居ると思う。
しかしそれすら見てなくてかつC++0x一次情報(TC1/SC22/WG21)も出てこないスレの流れよりはマシ。

>>181
いやだから、そのミーティング
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2507.html
で「N2481 Minimal Support for Garbage Collection and Reachability-Based Leak Detection」が取り上げられてるわけだが。誤解だったら指摘よろしく。

そりゃここはC++0xスレじゃないからね。普通はそこまで見ないでしょ。
見てる人がそれを紹介するという流れならわかるけどさ。

ゴミ集め厨らが、集められるのを待っています

>>176
無駄にstaticな参照とか、map等に入れっぱなしが発生するからあんまり変わらん。

>>185
ただN2481が入れば、
debuggerでbugを追いやすくなったのも確かだ。
(現実的には追いやすくなる可能性が増えた程度か?)

ttp://hnxgc.harnixworld.com/
RealGCよりも柔軟性が高そう
ただしマクロを使うことになるから、
ほかのGCライブラリを使った場合よりもソースは汚くなりそうだ。

GCなしでクロージャなんかまともに使えるのかね

コンパイラが静的解析して必要な箇所にクロージャを解放するコードを埋め込む
とかだったらいけるかも。

ユーザの入力した数 n に等しい長さのリンクリストとか作ると破綻するよね < 静的解析
Region inferenceとかどうなってるんだ

>>190
なことねーよ。
長さは抽象化して扱うんだよ。
全てのlist nodeが同じ性質かどうか解析する。
map/reduce系はlist nodeを同じ扱いするから結構簡単。

こんなん20年以上前から論文あるよ。
実装技術として実用化されてきたのが最近ってだけで。

リストは簡単な部類。嫌らしいのはフラットじゃない木構造。
フラットな構造ってのは、non-flat domainとしては一番単純だから。
最後の"non-flat"ってはdomain theory的な意味でね。

>>189
クロージャを解放？ただの匿名関数と勘違いしてないか？

>>192
なぜそう思ったの?

>>193
クロージャはローカル変数も束縛できる。
"クロージャを"解放すること自体はスマートポインタだろうが何だろうが問題ない

>>194
だから何？

>>195
お前誰？

なぁ、過疎スレで結構マニアックなスレでそういうバカな応答やめようよ。

Generation GC使ったらedenのサイズとかのパラメータが及ぼす影響が広範囲にわたって頭が痛いと思い始めたですよ。
まじめにアプリによってUI応答性能がすごく変わるんです。

それるけど、そろそろ藻前ら「匿名」関数はやめないか。ガ「ベー」ジコレクションと一緒で悪しき慣習だろ。
匿は「隠す」って意味だぞ、犯人隠匿とか。匿名なら、名前が「元々存在する」ものをあえて隠す。

anonymous functionは元々、進んで名前を付けないないのだから、訳すなら「無名」の方がましだろ。
# 英単語集合と和単語集合が全単射なわけねぇ〜

無名関数(他、無名クラス、等)は、書籍レベルだと定訳になってると思うけど、
最近はウェブベースで知識共有が進むからかなぁ。

ところで、「ガベージ」を排するとして、残る候補は、
・ガベジ
・ガベッジ
・ガーベジ
・ガーベッジ
だが、おすすめはどれよ。

もぉカタカナに変えた時点でどうでも良いと思うんだが。

じゃあ「ごみ」でいいか

>>199
.NETでは無名ではなく匿名になっているよ

実際コンパイラによって自動で命名されているのだから、匿名でも間違いではないとも言えるのかもしれない

例によって、MSDNの翻訳ミスかもしれんが。

> .NETでは
> .NETでは
> .NETでは

やはりRealGCはプリミティブを直接GC管理化には置けない模様。
ttp://18.real-sound.net/~fanzo/Real/xoops/modules/d3forum/index.php?topic_id=17
ちょっと使い勝手が悪いかな。

char*のラッパとかいちいち作るのも微妙。

>>203
何がいいたいの？
無名関数のように振舞う匿名関数という実装は存在するから、確実に間違いだとは言えないという話なんだけど

>>203
phpやpythonは匿名関数のほうが一般的
関数型の色が薄い言語は匿名と呼ぶものが多い様子

間違いと言っている奴も、
匿名としているグループがないと言っている奴もいない。
なのに(ry

>>206
>>203は
> 何がいいたいの？
って訊かれてるんだから、何が言いたいのかを言えばいい話。
ていうかお前>>203？　仄めかしばっかで中身全然無いのがそっくりだし。

> phpや
> phpや
> php

>>204
ぜんぜんRealじゃない実装w

>>204
> 無名関数のように振舞う匿名関数という実装は存在するから、確実に間違いだとは言えないという話なんだけど

悪いが、その「無名関数」と「匿名関数」のそれぞれの英訳教えてくれる？
英訳が無いような実装とかだったら実装の具体名で。

C#では、プログラマには無名に見えるけど、
CLRの内部では実際は名前を持っているって話でしょ。
GC関係ないからどうでもいいよ。マ板いってやってくれ。

スレ違いなのは同意だが・・・
>マ板いってやってくれ。
アホか


>>204
つまり、GCを導入してもdeleteは書くことになるわけだな（苦笑
デストラクタにdeleteを集約させるという意味ではスマートポインタに対する違いはあまりないな・・・

template<typename T>
class PrimitiveArrayPtr : virtual public gc_obj_base
以下略みたいなのを作ればいいのか
あえてそれを用意しないのは、何か問題があるのだろうか

>>197
で、GCなしでローカル変数の参照はどう扱うの？
UI応答速度なんてクロージャが実装可能かどうかとは関係ないのだが

C++はコンサバGCの精度を上げるための機構をまずは用意するんだね。
アプリの領域は、GCありきの言語にどんどん侵食されているのに、
非常にアグレッシブで面白いね。

C--もGC記述可能だったけど、今もC--やっている人いるのかな?

>>197
その前はリファレンスカウントだったんよ

>>193と>>197は別人か
ごめん

>>216は>>213(俺
重ね重ねすまぬorz

>>217
ワシこそ申し訳ない、しかし今回世代別初めて自分で書いたのですが、本当にパラメータ調整難しいです。
割と遅い速度のARM系チップなのでメモリに余裕あるからとコピー世代領域たくさんとると嫌なときにカクっとなったり、
かといって少ないとoldから参照されやすくなったりして非力なマシンには向かないかも知れないとおもいました。

以前Hnxが海外サイトのBBSでライセンスのことで叩かれていたのを思い出して、
調べてみた。

HnxGCのライセンス
>http://www.excite.co.jp/world/english/web/?wb_url=http%3A%2F%2Fhnxgc.harnixworld.com%2Fterms.htm&wb_lp=ENJA&wb_dis=3

ソフトウェアの許諾としてはありがちな内容だが、確かにこれは問題ありだ。
RealGCは選択肢としては（機能的に）微妙だし、SGCLはWindowsしかサポートしてないし
AGM::LibGCもマルチスレッド対応はウインドウズのみだっけ？
妥協するしかないのかー？

いつも思うんだけどさ。最初っから全部GCならいいんだよ。
次世代OSの定義でこれはどうよ:

1. malloc(3)がNULLを返さない事 (そんなもん返すくらいなら爆発しろ!)
2. free(3)の定義が空っぽな事 (すべての free(ptr); はコンパイル時に霧と消えろ!)

はぁ、(s)brk(2)? POSIXに載ってないAPIなんて(ry

あるいは、動的領域確保の必要性がない次世代言語: COBOL。

>>220
Visual C++は、mallocが失敗したときにも
set_new_handlerで指定したハンドラを呼び出すようにできる。

おっと送っちまった。
もちろん、GCはないし、2も満たしていないけどね。

>>222
ていうかC++ならbad_allocでおk

C++ OS と C++ chip マダー？

>>225
> C++ OS
http://nes.sourceforge.jp/ とか

色々考えた結果、RealGCを使ってみた。

オブジェクトを作るとき、引数付きコンストラクタは使えない仕様らしい。
メタプログラミングで吸収できないかあれこれ悩んでマス

エロい人にお願いです
boehmGCのライセンスについて解説してください(>人<)

>>228
英文が読めないって話だったら板違い

>>229
英文が読めないなんて書いてないけど…

「英文が読めないって話だったら板違い」という文章は
if (英語が読めないって話) { 板違い }　という意味であって、
英文が読めないということが「書いてないから」こういう言い方になるんだろう。

突っ込むなら、英文が読めないと「書いている」人に向かってこの反応をした時に突っ込むべきだよ。
「常に真になるじゃん。冗長にもほどがある」って。

長いしキモい…

"翻訳"してくれとどこに書いてあった？
"解説"と書いてあるだろ

>>231
冗長すぎてどっちに文句を言っているのかわからんちん

あんな短いライセンスに解説が必要か?
ライセンススレに言ったらどうか?

>>233
文句なんか言ってないし、冗長でもないよ。
「xではないから書かれたもの」に対して「xではないんだけど・・・」と返すのは変だという話。

>>228は結局、どこについて解説して欲しいんだ?
何が分からないのか示せない、典型的な教えて君だな。

漏れなら「短いよね」で解説終わりだ。これも(ライセンス全体についての)解説だ。

というか聞かなきゃわからんことなんかあるんだろうか、あの短さで

>漏れなら「短いよね」で解説終わりだ。
一般人はそれを感想と言う

本家見てれば関係ないのだが、漏れはBSDライセンスと書いているサイトがあるのが気になるお

今配布中の物を本家のライセンスにあわせんでどうするんだ？

>>238
そうだね、断定的に書けばいいのか。「短い。」

アホラシ

>>239
なんで俺に聞くの
俺がBSDって記載したんじゃない

>>240
どう取り繕っても感想は感想

「僕はアホらしいです」って自己紹介してるんだから許してやれ。

>>240
よう、学生

20歳位の頃は、>>240みたいなのがかっこいい切り返しに思えるんだよね。
数年経って、何でもない時にふと思い出すと、あまりの恥ずかしさに「うわっ」とか声出るけど。

何下らん話してるんだよ。GC以外の話をダラダラ続けんな、ボケ。
……といってもまったく新しい手法というのは聞かないしなぁ。せいぜいGCのハイブリッド化の技法ぐらい？

> ……といってもまったく新しい手法というのは聞かないしなぁ。せいぜいGCのハイブリッド化の技法ぐらい？

kwsk

いや、大した話じゃなくて、単に２つ以上のGC手法を組合せたもののこと。
Javaの世代別GCとかPythonのGCなんかでも使われとりますな。

メモリの節約とか効率化とかの話があるからそれなりに研究があるらしいけど、
詳しく追っていないから詳細はシラネ。

知らない割には>>245では偉そうだな。

javaチップの一種がGCの手法をハードウェアで支援するとか言う工夫してた、
ああいう手法が普通のCPUで使えたらいいのにと思う事はある。

>>249
それがデスクトップ用PCや汎用機で使えるようになると
かえってARMなどのモバイル環境でも使えるGC技術の発達が遅れかねないから
俺は嫌かな

GC実装の細かいところにはあんまり興味無いからなあ。
H/W GCというのも面白そうだけど、C&C++と相性悪そうだからどうだろ？

C&C++ って、NEC の「C&C」に ++ かと思ったわ一瞬

C&Cはカレーだろ

>>251
そうかなぁ？、あくまでハードウエアによる支援だからタグ付きポインタみたいにそれがポインタかデータかを持つだけでもありがたいと思うんだ。
（使わなければ普通のプロセッサになるってのがミソなんだとおもう）

でも、いまさらメモリインターフェースが３２＋ｘビットとかになると困るかもね（実際に出てくるとしたらECCの分を使い回しなんだろうね）

LISP専用ハードの再来ですか？

Tag付きデータはどの言語でも有用だろ

ちょいとGC好きのおまいら、このスレ監視してんならもちっとネタ振ってくれよ.
おいらが流れにあきれて>>249振ったらこんなに栄えちゃうならまだまだ素人考察事はあるんじゃないの？

いや、マジでお願いします、ＧＣは学術的に素人だけど、自前でComapction GCや世代別ＧＣ実装するくらい好きなんで。

ハードウェアのサポートありなら、Azulのやつは?

Freeの高速なGCの手法って
名前なんだっけ？

ハードウェアサポートは廃れた。

汎用のチップの方が速いから。
x86とそれ以外のCPUでもあれだけ差がある。
Tag付きデータを直接扱えるCPUはもっと遅くなる。

売れるCPUは速い。
また汎用CPUですらx86の牙城を崩せないのに、
Tag付きデータCPUに出来るわけがない。
80年代には決着がついていた。

ELISは、まだやってるんだ…という受け取られ方だった。

プロプライエタリな手法って特記するようなものもないと思うが...

GCはリファレンスカウントなら参照の発生と消滅に必ずコストがかかるし、
スキャベンジングでは生きてるオブジェクトを全部なめるから、オブジェクトの
数に比例したコストがどうしても必要になる。

GCに要する時間を少なくする手法としては、GC対象のオブジェクトを限定する
世代別GCとか？

GCしないという手もある

大昔，Lispマシンはその日電源落とすまでGC起きない方が普通だった
CPUも遅かったから

>>263
メモリ足りないとさすがにするってば。
っていうかそのころのLispマシンでそんな使い方できるくらいのメモリ積んだのってよっぽど予算余ってないと回ってこなかったよ。

#バブル期だったらそうかもしれんが、おいらが知ってるのはバブル前だからなぁ。 orz

４０過ぎたオッサン？もしかし５０近い？

LMIとかSymbolics社で聞いた話

飯食う前に(gc)
タバコ吸う前に(gc)
トイレ行く前に(gc)
ってのは聞いたことがある。

かつてパソコンベーシックでゲーム作ったときに、ゲーム中に不定期にGC入るのを嫌って
シーンチェンジのときに強制的にGCしたことを思い出すw

Ypsilonってピンボールゲーム開発用に作ったscheme実装が、
ゲームに十分なpauselessなGCと言っているね。

littlewing のやつか。

保守

Mostly Concurrent GCはポーズタイム存在するけど、ライトバリアで引っかかるオブジェクト
って思ってるより少ないのかな。

今俺が作ってる組み込み言語のGCは組み込み用途で使う限りはポーズレス（なはず）
だけど、Mostly Concurrent GCでも十分なら新規で開発する意味がないなぁ…

>>272
組み込みみたいなきつい環境だと状況しだいで優劣決まったりするから微妙じゃないの？
Realtime状況下でもっともプライオリティ低い所にUI環境がいてそこでGCさせるのにSTOP THE WORLDじゃ困るかと思ったら
リソースが少なすぎて世界が止まる区間があまりにも短くて笑った事がある

あ、ごめん、組み込み環境じゃなくて組み込み言語ね。
LuaとかSquirrelとかその辺りの言語のこと。

その辺りのGCを見る限りポーズレスなGCは需要あると思うんだけど、
実際世に出てみないと分からないだろうな。
まぁ考えても仕方ない、作るか。

期待age

最近のJavaとか、スループットより最悪値の改善を優先したGCがあるけど、
それって結局のところ、デストラクタを最初から実装しとけば良かったろと思ったりする。

ん？最初からGCを使うなって意味か？

GCを使ってたら、デストラクタがあってもGCに必要な時間は変わらんと思うけど

>>276
GC+デストラクタだと、
GCが回収した時にデストラクタが実行されるのかよ！
って不満も大きいと思うぞ。
全部explicitにやるならGC必要ないしな。

C++/CLI方式が理想だと言いたいのか？

つ GObject Introspection
http://live.gnome.org/GObjectIntrospection

今日考えた新しいGCアルゴリズム ： ノーオブジェクト - new でオブジェクトを一切生成せずnullを返す。
ガベージになりうるオブジェクトを一切生成しないという画期的なアルゴリズムであり、メモリ回収の必要がない。
欠点は、プログラムとして動かないという点である。

Javaプログラマは今日も呑気です。

逆に生成したオブジェクトを一切回収しないという方針でも
スワップファイルを酷使すればそこそこ動く。

Javaのエスケープ解析はもう標準？

>>282
スワップ周りの仕組みがちゃんとしていれば、それは一種の Copying CG になるぞ。

>>284
スワップ周りの仕組みがちゃんとしてても結局GCしてないじゃん。
オブジェクトがメモリ→ディスクと移動していくだけで。

イミュータブルが基本の関数型言語ならそれなりにありな戦略だと思う。

>>283
「標準」ってどういう意味?

バニラ状態のSun JDKに入った、とかその程度の意味なんじゃない？

最近の(Sunの)VMは何も言わないでエスケープ解析がonになるの？
という質問のつもりだった。

まだみたいだね。-XX:+DoEscapeAnalysis が相変わらず必要みたいだ。

なんで未だに標準でONにならないんだろうね？
バグ持ち・遅い・GCで十分早いのどれかなんだろうとは思うけど。

エスケープ解析ってどこまでスタックに乗せられるの？
参照型をフィールドにもたないクラスくらいはしてくれるのかな。

GC本発売記念age
http://www.amazon.co.jp/dp/4798025623/

エスケープ解析はupdate14から17までは有効になってたらしいが。
G1GC、JRockit統合、エスケープ解析を並行して調整していくとなると先は長そうだ

java6 u20でエスケープ解析もCoopもデフォルトon

>>293
mjk?

>>291
俺の一番知りたいマルチスレッド関係が全く持ってはしょられてて意味なかった。(compactionとスレッド間の同期とか）
つかここのスレで紹介されてるweb記事とあんまり得られる知識かわらなかった。

結論
2ch読んでれば不要

>>296
つか著者ってこのスレで紹介された論文書いてる人だったハズ
なので一般的な読み物としての完成度は上がっているのだけど、2chの専門スレに来ちゃうような人には物足りないだけなのだ

>一般的な読み物
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

なんだこれ。

技術読み物？

GCの一般的な読み物っていったらこれだろ。
http://www.amazon.co.jp/dp/4086301849

>>300
新刊？
まぁラノベも読むけどあんまり雑食じゃないので、外伝とかサイドストーリーまでは買わないし完全にネタが電算と秋葉でもそれはスレ違いだぞ


技術読み物ってのは専門家以外でも読める内容や記述の書籍の事じゃないの？
中田先生著のコンパイラ本は専門書だけど、中田先生監修だといっぱんてきとか
CLtLと初めての人のlispみたいなもんじゃないの？

>>294
ttp://download.java.net/jdk6/6u20/promoted/b01/changes/JDK6u20.b01.list.html
enable escape analysis by default
enable compressed oops by default

間をとって
ガーベージコレクション

GC本扱っている内容の珍しさという点ではおすすめだが
質的な面では平凡なレベルか

最近のGC研究はレスポンスの最悪値の改善が主流なんでしょ？
stop-the-worldとか過去の産物なのかね？

http://www.managedruntime.org/
x86なVM上(KVM, VMWare)で直にJVMを走らせるイメージらしい。
Pauseless GCが載ってる

長年.NETでプログラムを書いてるが、stop-the-worldはねえなー

ちょっと皆に聞きたいんだけど
今時のjavaの実装とかってコンパクションしてるんだろうか？
たとえば64bitマシンで６４Ｇのメモリ積んでいて、ギリギリまで使う状況でコンパクションありとかだとものすごい事にならんのだろうか？

ソース読めっていわれりゃごめんなさいするしかないんだけど、コンパクションするしないの違いって大きいと思うのだけどどうなんだろう？
Bohemとかはしないけど言語的にGCが実装されている場合ってどっちが主流なの？

>>308
Java の GC は世代別な上に、parallel gc とか concurrent gc とか積んでるから、
ちゃんとオプションを付けてあげれば結構耐えるんじゃないかな。

hotspot vm はコンパクションしてるよ
というか世代別なのでそうなるというか

>>308
コンパクションするかしないか、二者択一で考えているところが、
知識が３０年近く古い。

>>311
３０年は言い過ぎだろう、今でもコンパックションしないとフラグメントして記憶域が鬆になってOutOfMemoryになるのは変わらん

>>308
そもそもCopying GCなら原理的にフラグメントは発生しない。

Hotspot の GC は、寿命が短いオブジェクトは Copying GC で刈り取って、
ある程度長生きしたオブジェクトは Mark and Sweep する方式だったと思う。
Heap 全体のサイズを 64GB 取るとしても、Copying の部分は 4GB とか、
ある程度小さいサイズにするんじゃないかな。

>>314
昔のGCはそうだった。
G1GCの基本はコピーだから今は違う。

>>315
thx
ちょっとペーパー読んでくる

>>312
G1GCだとコンパクションが起きても領域が限定的にできるってイメージなんだけどそれでOK？
FullCompactionのようなヒープサイズに依存した実行時間が掛かったりしない、と。

G1GCのパフォーマンスの情報が少ないんだよなぁ・・・
自分で使ってても他の方式と差が出るような場面がまだ出てこない。
通常にJ2EEサーバ、デスクトップクライアントを使ってるだけでは
見えてこないくらいの差なのかな？

オリジナルの論文で評価もちゃんとしてあるから、
ツボを突いたベンチでもやれば？

GCが仇となる環境を挙げてみて下さい

>>28やっべーこれ当時の俺の書き込みかも知れない

>>320
ﾜﾗﾀ

君子豹変す

Haskellのガベコレはどれくらい最先端なの？

グラスゴHaskellコンパイラについて言えば、
投入されてる労力はそこらのLLよりは多いってぐらいじゃない？
Javaの実装とは比較にならんとは思うけど。

GCはJVM>.Net=FranzLisp>LispWorks>>>そのほか
ってかんじだとおもう、異論はいっぱいあると思うから感触が違うと思う人の意見も聞きたいけど
C用のベームだけちょっとわからん位置づけ（アプリケーションに依存して性能が変わっちゃう感じするんだ)

.Netはヒープ使わない場合があるのが性能に寄与してるから言語設計のうまさもあるんだと思うし。

.Net は後出しジャンケンだからね。そりゃぁJavaに勝って当然。

後出しジャンケンのDとGo、なぜ差が付いたのか…慢心・環境の違い

>>327
Dは仕様が固まらなかったのが痛いんじゃない？
Goは放置プレイに見えるし

見えるしね

仮想敵を決めて的確に弱点をついたか田舎の差

市場を支配しているOSを持っていたかどうかの違い。

MS-BASICのGCの思い出

http://ityougo.com/programming/347/

>>333
なんでコンパクションもまざってんだろう?