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

1 ：デフォルトの名無しさん：2006/03/06(月) 21:07:30

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

2 ：デフォルトの名無しさん：2006/03/06(月) 21:12:20

Javaは糞

3 ：デフォルトの名無しさん：2006/03/06(月) 21:16:34

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

4 ：デフォルトの名無しさん：2006/03/06(月) 21:19:37

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

5 ：デフォルトの名無しさん：2006/03/06(月) 21:47:36

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

6 ：デフォルトの名無しさん：2006/03/06(月) 21:50:06

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

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

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

7 ：デフォルトの名無しさん：2006/03/06(月) 21:54:03

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

8 ：デフォルトの名無しさん：2006/03/06(月) 21:59:08

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

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

9 ：デフォルトの名無しさん：2006/03/06(月) 22:03:23

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

10 ：デフォルトの名無しさん：2006/03/06(月) 22:18:08

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

11 ：デフォルトの名無しさん：2006/03/06(月) 22:20:15

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

12 ：デフォルトの名無しさん：2006/03/06(月) 22:22:11

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

13 ：デフォルトの名無しさん：2006/03/06(月) 22:27:39

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

14 ：デフォルトの名無しさん：2006/03/06(月) 22:29:01

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

15 ：デフォルトの名無しさん：2006/03/06(月) 22:30:39

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

16 ：デフォルトの名無しさん：2006/03/07(火) 00:49:17

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

17 ：デフォルトの名無しさん：2006/03/07(火) 00:52:02

誤爆?

18 ：デフォルトの名無しさん：2006/03/07(火) 00:56:13

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

19 ：デフォルトの名無しさん：2006/03/07(火) 01:12:37

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

20 ：デフォルトの名無しさん：2006/03/07(火) 21:40:48

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

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

21 ：デフォルトの名無しさん：2006/03/07(火) 22:48:03

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

22 ：デフォルトの名無しさん：2006/03/07(火) 23:02:16

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

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

23 ：デフォルトの名無しさん：2006/03/07(火) 23:25:57

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

24 ：デフォルトの名無しさん：2006/03/07(火) 23:30:09

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

25 ：デフォルトの名無しさん：2006/03/07(火) 23:33:39

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

26 ：デフォルトの名無しさん：2006/03/07(火) 23:55:01

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

27 ：デフォルトの名無しさん：2006/03/08(水) 00:33:52

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

28 ：デフォルトの名無しさん：2006/03/08(水) 00:34:57

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

29 ：デフォルトの名無しさん：2006/03/08(水) 00:36:12

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

30 ：デフォルトの名無しさん：2006/03/08(水) 00:45:16

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

31 ：デフォルトの名無しさん：2006/03/08(水) 00:56:25

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

32 ：デフォルトの名無しさん：2006/03/08(水) 00:58:07

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

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

33 ：デフォルトの名無しさん：2006/03/08(水) 01:05:33

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

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

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

34 ：デフォルトの名無しさん：2006/03/08(水) 01:19:37

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

35 ：デフォルトの名無しさん：2006/03/08(水) 01:29:11

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

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

36 ：デフォルトの名無しさん：2006/03/08(水) 01:45:31

>>35

>Boehmは...

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

37 ：デフォルトの名無しさん：2006/03/08(水) 01:47:31

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

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

38 ：デフォルトの名無しさん：2006/03/08(水) 01:50:15

>>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
>
>不可能ではないので、ムズイ、であってます。

39 ：デフォルトの名無しさん：2006/03/08(水) 02:07:18

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

>例えば
>例えば


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

40 ：デフォルトの名無しさん：2006/03/08(水) 02:15:34

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

41 ：デフォルトの名無しさん：2006/03/08(水) 02:24:08

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

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

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

42 ：デフォルトの名無しさん：2006/03/08(水) 03:32:23

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

43 ：デフォルトの名無しさん：2006/03/08(水) 03:34:48

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

44 ：デフォルトの名無しさん：2006/03/08(水) 09:14:24

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

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

45 ：デフォルトの名無しさん：2006/03/08(水) 13:00:38

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

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

46 ：44：2006/03/08(水) 13:08:08

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

47 ：デフォルトの名無しさん：2006/03/08(水) 13:10:21

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

48 ：デフォルトの名無しさん：2006/03/08(水) 16:09:07

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

49 ：デフォルトの名無しさん：2006/03/08(水) 20:57:13

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

50 ：デフォルトの名無しさん：2006/03/08(水) 22:16:54

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

51 ：デフォルトの名無しさん：2006/03/08(水) 23:22:36

バカ度7強の発言来た

52 ：デフォルトの名無しさん：2006/03/08(水) 23:28:31

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

53 ：デフォルトの名無しさん：2006/03/08(水) 23:33:45

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

54 ：デフォルトの名無しさん：2006/03/08(水) 23:44:03

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

55 ：デフォルトの名無しさん：2006/03/09(木) 00:08:40

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

56 ：デフォルトの名無しさん：2006/03/09(木) 00:09:13

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

57 ：デフォルトの名無しさん：2006/03/09(木) 00:11:04

>>56 は >>54 宛ね。

58 ：デフォルトの名無しさん：2006/03/09(木) 00:40:45

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

59 ：デフォルトの名無しさん：2006/03/09(木) 01:17:04

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

60 ：デフォルトの名無しさん：2006/03/09(木) 01:19:44

それしか言えんのか

61 ：デフォルトの名無しさん：2006/03/09(木) 01:22:48

それで十分だし

62 ：デフォルトの名無しさん：2006/03/09(木) 01:26:22

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

63 ：デフォルトの名無しさん：2006/03/09(木) 01:31:58

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

64 ：デフォルトの名無しさん：2006/03/09(木) 17:39:50

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

65 ：デフォルトの名無しさん：2006/03/09(木) 19:31:47

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

66 ：デフォルトの名無しさん：2006/03/09(木) 22:02:18

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

67 ：デフォルトの名無しさん：2006/03/10(金) 00:03:10

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

68 ：デフォルトの名無しさん：2006/03/10(金) 00:10:06

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

時が止まる

69 ：デフォルトの名無しさん：2006/03/10(金) 00:30:28

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

70 ：デフォルトの名無しさん：2006/03/10(金) 00:57:39

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

71 ：デフォルトの名無しさん：2006/03/10(金) 01:01:15

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

72 ：デフォルトの名無しさん：2006/03/10(金) 01:16:11

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

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

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

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


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

73 ：デフォルトの名無しさん：2006/03/10(金) 01:22:50

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

74 ：デフォルトの名無しさん：2006/03/10(金) 01:31:35

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

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

75 ：デフォルトの名無しさん：2006/03/10(金) 05:22:44

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

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

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

76 ：デフォルトの名無しさん：2006/03/10(金) 09:13:58

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

77 ：デフォルトの名無しさん：2006/03/10(金) 09:46:45

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

78 ：デフォルトの名無しさん：2006/03/10(金) 09:53:19

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

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

79 ：デフォルトの名無しさん：2006/03/10(金) 09:54:38

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

80 ：デフォルトの名無しさん：2006/03/10(金) 10:00:17

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

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

81 ：デフォルトの名無しさん：2006/03/10(金) 10:05:11

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

82 ：デフォルトの名無しさん：2006/03/10(金) 10:35:56

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

83 ：デフォルトの名無しさん：2006/03/10(金) 10:37:39

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

84 ：デフォルトの名無しさん：2006/03/10(金) 11:32:34

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

85 ：デフォルトの名無しさん：2006/03/10(金) 22:51:59

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

86 ：デフォルトの名無しさん：2006/03/10(金) 22:55:19

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

87 ：デフォルトの名無しさん：2006/03/10(金) 23:29:02

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

88 ：デフォルトの名無しさん：2006/03/10(金) 23:32:46

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

89 ：デフォルトの名無しさん：2006/03/10(金) 23:34:24

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

90 ：デフォルトの名無しさん：2006/03/11(土) 01:36:39

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

91 ：デフォルトの名無しさん：2006/03/11(土) 01:56:03

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

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

うそみたいなホントの話

92 ：デフォルトの名無しさん：2006/03/11(土) 02:17:25

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

93 ：デフォルトの名無しさん：2006/03/11(土) 02:24:05

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

94 ：デフォルトの名無しさん：2006/03/11(土) 02:30:38

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

95 ：デフォルトの名無しさん：2006/03/11(土) 02:39:24

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

96 ：デフォルトの名無しさん：2006/03/11(土) 02:45:22

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

97 ：デフォルトの名無しさん：2006/03/11(土) 03:57:29

>>95
OSによる。

98 ：デフォルトの名無しさん：2006/03/11(土) 10:01:10

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

99 ：デフォルトの名無しさん：2006/03/11(土) 10:21:20

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

100 ：デフォルトの名無しさん：2006/03/11(土) 10:54:04

>>91
これはひどい。

101 ：デフォルトの名無しさん：2006/03/11(土) 12:49:05

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

102 ：デフォルトの名無しさん：2006/03/11(土) 13:43:39

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

103 ：デフォルトの名無しさん：2006/03/11(土) 13:59:50

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

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

104 ：デフォルトの名無しさん：2006/03/11(土) 14:16:17

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

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

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

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

105 ：デフォルトの名無しさん：2006/03/11(土) 14:19:27

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

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

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

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

106 ：デフォルトの名無しさん：2006/03/11(土) 14:19:50

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

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

107 ：デフォルトの名無しさん：2006/03/11(土) 14:21:53

　　　R　　u　　b　　y　　の　　予　　感

108 ：デフォルトの名無しさん：2006/03/11(土) 14:26:38

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

109 ：デフォルトの名無しさん：2006/03/11(土) 14:34:15

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

110 ：デフォルトの名無しさん：2006/03/11(土) 14:42:03

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

111 ：デフォルトの名無しさん：2006/03/11(土) 14:50:41

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

112 ：デフォルトの名無しさん：2006/03/11(土) 20:33:50

CLOSこそが真のOO

113 ：デフォルトの名無しさん：2006/03/11(土) 20:36:28

>>106-112
スレ違い。

114 ：デフォルトの名無しさん：2006/03/14(火) 21:45:10

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

115 ：デフォルトの名無しさん：2006/03/14(火) 21:47:06

ＧＣの利点

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

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

116 ：デフォルトの名無しさん：2006/03/14(火) 21:50:58

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

117 ：デフォルトの名無しさん：2006/03/14(火) 22:04:20

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

118 ：デフォルトの名無しさん：2006/03/14(火) 22:54:44

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

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

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

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

119 ：http://www.vector.co.jp/soft/win95/util/se072729.html：2006/03/18(土) 21:31:22

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

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

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

120 ：デフォルトの名無しさん：2006/03/20(月) 14:06:41

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

121 ：デフォルトの名無しさん：2006/03/20(月) 23:30:03

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

122 ：デフォルトの名無しさん：2006/03/21(火) 07:52:42

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

123 ：デフォルトの名無しさん：2006/03/21(火) 09:45:58

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

124 ：デフォルトの名無しさん：2006/03/21(火) 11:12:56

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

125 ：デフォルトの名無しさん：2006/03/21(火) 19:23:01

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

126 ：デフォルトの名無しさん：2006/03/28(火) 14:44:15

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

127 ：デフォルトの名無しさん：2006/03/28(火) 21:47:06

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

128 ：デフォルトの名無しさん：2006/04/05(水) 17:11:56

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

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

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

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

129 ：デフォルトの名無しさん：2006/04/05(水) 17:14:58

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

130 ：デフォルトの名無しさん：2006/04/05(水) 23:57:52

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

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

どうすんのコレ？

131 ：デフォルトの名無しさん：2006/04/08(土) 00:19:47

もちろんフロー解析して

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

にしてください

132 ：デフォルトの名無しさん：2006/04/08(土) 12:48:24

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

133 ：デフォルトの名無しさん：2006/05/05(金) 17:09:54

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

134 ：デフォルトの名無しさん：2006/05/06(土) 07:54:09

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

135 ：デフォルトの名無しさん：2006/05/06(土) 09:03:51

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

136 ：デフォルトの名無しさん：2006/05/19(金) 16:11:21

㋦㋸㋭°

137 ：デフォルトの名無しさん：2006/05/26(金) 14:44:25

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

138 ：デフォルトの名無しさん：2006/05/26(金) 15:26:27

ない。

139 ：デフォルトの名無しさん：2006/05/26(金) 16:15:33

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

140 ：デフォルトの名無しさん：2006/05/26(金) 22:38:16

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

141 ：デフォルトの名無しさん：2006/05/27(土) 01:16:31

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

142 ：デフォルトの名無しさん：2006/05/27(土) 09:11:05

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

143 ：デフォルトの名無しさん：2006/05/27(土) 14:24:02

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

144 ：デフォルトの名無しさん：2006/05/27(土) 16:01:08

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

145 ：デフォルトの名無しさん：2006/05/27(土) 16:41:06

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

146 ：デフォルトの名無しさん：2006/05/27(土) 16:50:22

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

147 ：デフォルトの名無しさん：2006/05/27(土) 17:42:47

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

148 ：145：2006/05/27(土) 21:17:39

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

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

149 ：デフォルトの名無しさん：2006/05/28(日) 09:14:35

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

150 ：デフォルトの名無しさん：2006/07/18(火) 02:06:37

主流の技術を語って

151 ：デフォルトの名無しさん：2006/07/18(火) 03:06:59

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

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

152 ：デフォルトの名無しさん：2006/07/18(火) 13:07:09

アコギな商売ですね

153 ：デフォルトの名無しさん：2006/07/18(火) 22:00:27

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

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

154 ：デフォルトの名無しさん：2006/07/19(水) 22:01:23

主流の技術を語って

155 ：デフォルトの名無しさん：2006/07/19(水) 22:25:03

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

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

156 ：デフォルトの名無しさん：2006/07/19(水) 23:24:41

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

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

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

157 ：デフォルトの名無しさん：2006/07/19(水) 23:49:41

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

158 ：デフォルトの名無しさん：2006/07/20(木) 00:59:39

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

159 ：デフォルトの名無しさん：2006/07/20(木) 01:57:46

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

160 ：デフォルトの名無しさん：2006/07/20(木) 09:07:19

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

161 ：デフォルトの名無しさん：2006/07/25(火) 02:34:41

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

162 ：デフォルトの名無しさん：2006/11/19(日) 02:34:01

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

163 ：デフォルトの名無しさん：2007/02/27(火) 19:09:55

sageてるじゃねーか

164 ：デフォルトの名無しさん：2007/07/01(日) 21:03:42

保守的GC

165 ：デフォルトの名無しさん：2007/07/02(月) 00:35:11

革新的GC

166 ：デフォルトの名無しさん：2007/07/02(月) 10:35:24

闘争的GC

167 ：デフォルトの名無しさん：2007/07/02(月) 19:12:31

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

168 ：デフォルトの名無しさん：2007/07/03(火) 09:13:37

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

169 ：デフォルトの名無しさん：2007/09/28(金) 22:33:36

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

170 ：デフォルトの名無しさん：2007/09/28(金) 22:49:08

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

171 ：デフォルトの名無しさん：2007/09/28(金) 22:49:56

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

172 ：デフォルトの名無しさん：2007/12/09(日) 15:55:00

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

173 ：デフォルトの名無しさん：2007/12/09(日) 17:54:09

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

174 ：デフォルトの名無しさん：2008/03/04(火) 23:34:59

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

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

175 ：デフォルトの名無しさん：2008/03/05(水) 07:48:58

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

176 ：デフォルトの名無しさん：2008/03/15(土) 23:53:00

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

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

177 ：デフォルトの名無しさん：2008/03/17(月) 10:53:20

藻前ら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でも使うか。

178 ：デフォルトの名無しさん：2008/03/17(月) 11:03:38

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

179 ：デフォルトの名無しさん：2008/03/17(月) 12:17:41

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

180 ：デフォルトの名無しさん：2008/03/17(月) 13:28:48

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

181 ：デフォルトの名無しさん：2008/03/17(月) 13:36:50

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

182 ：デフォルトの名無しさん：2008/03/17(月) 14:20:50

>>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」が取り上げられてるわけだが。誤解だったら指摘よろしく。

183 ：デフォルトの名無しさん：2008/03/17(月) 14:26:41

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

184 ：デフォルトの名無しさん：2008/03/17(月) 14:29:36

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

185 ：デフォルトの名無しさん：2008/03/17(月) 21:20:43

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

186 ：デフォルトの名無しさん：2008/03/17(月) 21:50:35

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

187 ：デフォルトの名無しさん：2008/03/28(金) 11:31:56

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

188 ：デフォルトの名無しさん：2008/03/31(月) 03:54:24

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

189 ：デフォルトの名無しさん：2008/03/31(月) 06:35:43

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

190 ：デフォルトの名無しさん：2008/04/03(木) 07:02:47

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

191 ：デフォルトの名無しさん：2008/04/03(木) 07:34:49

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

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

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

192 ：デフォルトの名無しさん：2008/04/03(木) 23:42:27

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

193 ：デフォルトの名無しさん：2008/04/04(金) 11:29:12

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

194 ：デフォルトの名無しさん：2008/04/06(日) 01:40:06

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

195 ：デフォルトの名無しさん：2008/04/06(日) 11:50:25

>>194
だから何？

196 ：デフォルトの名無しさん：2008/04/06(日) 11:56:41

>>195
お前誰？

197 ：デフォルトの名無しさん：2008/04/06(日) 12:30:36

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

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

198 ：デフォルトの名無しさん：2008/04/07(月) 21:01:35

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

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

199 ：デフォルトの名無しさん：2008/04/08(火) 09:38:57

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

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

200 ：デフォルトの名無しさん：2008/04/08(火) 09:58:29

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

201 ：デフォルトの名無しさん：2008/04/08(火) 10:12:31

じゃあ「ごみ」でいいか

202 ：デフォルトの名無しさん：2008/04/08(火) 11:36:30

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

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

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

203 ：デフォルトの名無しさん：2008/04/08(火) 11:45:29

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

204 ：デフォルトの名無しさん：2008/04/08(火) 12:05:43

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

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

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

205 ：デフォルトの名無しさん：2008/04/08(火) 12:15:47

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

206 ：デフォルトの名無しさん：2008/04/08(火) 13:14:43

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

207 ：デフォルトの名無しさん：2008/04/08(火) 14:45:57

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

208 ：デフォルトの名無しさん：2008/04/08(火) 18:42:39

> phpや
> phpや
> php

209 ：デフォルトの名無しさん：2008/04/08(火) 18:43:41

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

210 ：デフォルトの名無しさん：2008/04/08(火) 18:56:19

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

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

211 ：デフォルトの名無しさん：2008/04/08(火) 19:06:54

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

212 ：デフォルトの名無しさん：2008/04/08(火) 20:29:55

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


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

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

213 ：デフォルトの名無しさん：2008/04/09(水) 09:26:15

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

214 ：デフォルトの名無しさん：2008/04/09(水) 09:48:50

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

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

215 ：デフォルトの名無しさん：2008/04/09(水) 11:15:52

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

216 ：197：2008/04/09(水) 11:29:10

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

217 ：213：2008/04/09(水) 11:30:40

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

218 ：デフォルトの名無しさん：2008/04/09(水) 11:44:27

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

219 ：デフォルトの名無しさん：2008/04/09(水) 13:10:59

以前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もマルチスレッド対応はウインドウズのみだっけ？
妥協するしかないのかー？

220 ：デフォルトの名無しさん：2008/04/10(木) 23:27:23

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

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

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

221 ：220：2008/04/10(木) 23:28:56

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

222 ：デフォルトの名無しさん：2008/04/11(金) 00:05:31

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

223 ：222：2008/04/11(金) 00:06:51

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

224 ：デフォルトの名無しさん：2008/04/11(金) 01:58:17

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

225 ：デフォルトの名無しさん：2008/04/11(金) 10:40:45

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

226 ：デフォルトの名無しさん：2008/04/11(金) 12:15:27

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

227 ：219：2008/04/11(金) 13:58:31

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

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

228 ：デフォルトの名無しさん：2008/04/12(土) 01:43:26

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

229 ：デフォルトの名無しさん：2008/04/12(土) 02:04:37

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

230 ：デフォルトの名無しさん：2008/04/12(土) 16:31:42

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

231 ：デフォルトの名無しさん：2008/04/12(土) 17:41:40

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

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

232 ：デフォルトの名無しさん：2008/04/12(土) 17:54:01

長いしキモい…

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

233 ：デフォルトの名無しさん：2008/04/12(土) 18:22:18

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

234 ：デフォルトの名無しさん：2008/04/12(土) 19:29:04

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

235 ：デフォルトの名無しさん：2008/04/12(土) 19:45:32

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

236 ：デフォルトの名無しさん：2008/04/13(日) 15:11:43

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

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

237 ：デフォルトの名無しさん：2008/04/13(日) 15:43:01

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

238 ：デフォルトの名無しさん：2008/04/14(月) 10:42:40

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

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

239 ：デフォルトの名無しさん：2008/04/14(月) 11:08:16

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

240 ：デフォルトの名無しさん：2008/04/14(月) 20:47:33

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

アホラシ

241 ：デフォルトの名無しさん：2008/04/30(水) 08:27:41

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

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

242 ：デフォルトの名無しさん：2008/04/30(水) 09:28:13

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

243 ：デフォルトの名無しさん：2008/05/02(金) 22:36:58

>>240
よう、学生

244 ：デフォルトの名無しさん：2008/05/02(金) 23:15:58

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

245 ：デフォルトの名無しさん：2008/05/03(土) 00:40:37

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

246 ：デフォルトの名無しさん：2008/05/03(土) 12:44:20

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

kwsk

247 ：デフォルトの名無しさん：2008/05/03(土) 14:23:25

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

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

248 ：デフォルトの名無しさん：2008/05/03(土) 14:28:18

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

249 ：デフォルトの名無しさん：2008/05/03(土) 14:31:04

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

250 ：デフォルトの名無しさん：2008/05/03(土) 15:08:47

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

251 ：245：2008/05/03(土) 15:45:29

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

252 ：デフォルトの名無しさん：2008/05/03(土) 16:19:40

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

253 ：デフォルトの名無しさん：2008/05/03(土) 18:16:50

C&Cはカレーだろ

254 ：デフォルトの名無しさん：2008/05/03(土) 19:20:53

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

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

255 ：デフォルトの名無しさん：2008/05/03(土) 20:00:43

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

256 ：デフォルトの名無しさん：2008/05/03(土) 20:27:11

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

257 ：デフォルトの名無しさん：2008/05/03(土) 20:39:34

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

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

258 ：デフォルトの名無しさん：2008/05/05(月) 14:27:27

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

259 ：デフォルトの名無しさん：2008/05/30(金) 00:38:36

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

260 ：デフォルトの名無しさん：2008/05/30(金) 10:59:32

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

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

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

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

261 ：デフォルトの名無しさん：2008/05/30(金) 11:03:53

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

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

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

262 ：デフォルトの名無しさん：2008/05/30(金) 14:56:02

GCしないという手もある

263 ：デフォルトの名無しさん：2008/05/31(土) 06:48:59

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

264 ：デフォルトの名無しさん：2008/05/31(土) 14:39:22

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

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

265 ：デフォルトの名無しさん：2008/05/31(土) 16:39:13

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

266 ：デフォルトの名無しさん：2008/06/01(日) 15:41:05

LMIとかSymbolics社で聞いた話

267 ：デフォルトの名無しさん：2008/07/17(木) 12:53:14

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

268 ：デフォルトの名無しさん：2008/07/17(木) 13:42:23

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

269 ：デフォルトの名無しさん：2008/10/27(月) 11:14:13

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

270 ：デフォルトの名無しさん：2008/10/29(水) 01:31:31

littlewing のやつか。

271 ：デフォルトの名無しさん：2009/01/14(水) 07:28:54

保守