5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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いらないのに」
と5文字のラベル時代に妄想したことがある(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指してる?
仮想マシンとか構文木のまま実行するインタプリタのとか生Cから使うとかの違い?
それともスレッドの話が出てるから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
GCのパフォーマンスなら観察してパラメータ調整するのは常識化してる<<エンタープライズ用途


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
GC付きの言語評価器を書く場合はGC使えないわな

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
GCの利点

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

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


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にネイティブ対応している2chブラウザてありましたっけ?

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(w



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間の同期機構
そのときメジャーなアプリ

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

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ページでページ単位にGCと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てるじゃねーか

33 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)