アカウント名:
パスワード:
GCを利点として挙げる人がいますが、それも僕はどうかと思っています。 GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。
GC を単にメモリリークを防ぐためのものと考えると大したありがたみはありませんが，メモリフラ
いいえ。G7さんが紹介してくれましたURLがよい資料なので、詳しくは そちらを見てください。ここでは簡単に言いますと、GCは古典的には、
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
Javaの必要性 (スコア:1)
僕はいまいちJavaの良さが分かりません。
誰かJavaのすばらしさを語ってもらえないでしょうか。
Re:Javaの必要性 (スコア:1)
Java Applet のことだったり、 JavaScript のことだったりする
ことがあるので、いっかい問い詰めてみたほうがいいです。
Re:Javaの必要性 (スコア:2, 参考になる)
JITの技術がありますが本質的な解決策では無いと思います。
しかもテキスト処理なんかはJITを使ってもAwkよりもPerlよりも遅い。
次に移植性です。
Write Once Run Anywareとか言っていますがはっきり言って実現されて無いと思います。
移植性 + 速度
で考えるとCの方が上だと思っています。
GCを利点として挙げる人がいますが、それも僕はどうかと思っています。
GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。
1時間ぐらいだったら動くけど長時間動かしているとVMが落ちることがありますし、その時のバ
GCの必要性 (スコア:2, 参考になる)
GC を単にメモリリークを防ぐためのものと考えると大したありがたみはありませんが，メモリフラ
Re:GCの必要性 (スコア:1)
>テーションを防ぐためのものと考えれば，その恩恵は計り知れないと思います。
え？
http://www.is.s.u-tokyo.ac.jp/~vu/jugyo/processor/process/soft/compilerresume/gc/gc.html
＞Copying GCの興味深い性質は、コピーするときにオブジェクトの空きをつめるため、fragmentationが発生しないということである。
によると、フラグメンテーションを無くす機能(つーか嬉しい副作用?)を期待できるかどうかは
GCのアルゴリズム次第であって、GC一般の性質ではない、と読めます
Re:GCの必要性 (スコア:1)
> GCのアルゴリズム次第であって、GC一般の性質ではない、と読めますけど？
GC がどのようなアルゴリズムで行われるにせよ、compaction は
行われてるのではないでしょうか？ compaction されるというこ
とは、その時点でフラグメンテーションも解消される、ということ
ですよね？違う？
Java の Heap に関しては、激しくオブジェクトの生成／回収を
繰り
Only Jav^Hpanese available :-)
Re:GCの必要性 (スコア:1)
いいえ。G7さんが紹介してくれましたURLがよい資料なので、詳しくは そちらを見てください。ここでは簡単に言いますと、GCは古典的には、
Re:GCの必要性 (スコア:1)
実際に compaction を行わない GC 実装が存在することはもちろ
ん知っていますし、JavaVM Spec. が Heap 管理については 100%
実装者の裁量に任せている、ことも分かっていますが、しかし、
ご存じの通り Java にはポインタがありませんから、C でのよう
にプログラム側でフラグメンテーションに対処することが非常に難しく、
となると、まっとうな実装者ならばフラグメンテーションが起こら
ないように GC を設計するのではないか、という予想のもと、こと
現代的な実装の JavaVM に関していうなら、G7 さんの書込みでい
うところの「それ
Only Jav^Hpanese available :-)
Re:GCの必要性 (スコア:1)
>にプログラム側でフラグメンテーションに対処することが非常に難しく、
ああ。メモリプールというかmallocに相当するものを自作するという話題ですか。
たしかにjavaでは何処をどういじってもソレっぽいことは出来ないですね。
>現代的な実装の JavaVM に関していうなら、G7 さんの書込みでい
>うところの「それとも、その副作用のあるGCしか使う予定が無い、
>言い換えれば使おうとしている処理系のGCがお望みのアルゴリズム
>であることが既に判っている、という状況」といえるのではないか、
それを称して「
現代的な GC (スコア:1)
> 俺は知らないんですが。
compaction をやることが現代的な GC だとは思いません。
長い GC の歴史の中である程度 よい GC の条件が見えてきています。
非並列 GC の場合に限ると以下の 4点ぐらいを押さえた GC が現代的
な GC ではないでしょうか？
1. オブジェクトの寿命を意識すること
オブジェクトには生成されたけど一度も使われずに終わる
単寿命なやつから VM が終わるまで居続ける長生きなオブ
ジェクトまで寿命に差があります。
現代の GC はこの性質を旨く使う事が何より求められています。
2. キャッシュを意識すること
現代的なプロセッサはキャッシュの性能におんぶでだっこ。
GC といえどもキャッシュミスヒットを避ける努力が必要です。
3. 排他制御は最小に
fetch & add や compare & swap のようなアトミック命令は
最初にするのが吉です。
OS の同期オブジェクトの極力使わないことが求められます。
4. 処理は短く
それぞれの操作(例えば 1回の new)にかかる時間を減らすことも
重要です。
それ以外にも stop the world を掛けてから本当にすべてのスレッド
が止まって GC がはじまるまでのタイムラグだとかがあります。
コンタミは発見の母
いいわけ (スコア:1)
「現代的」は JavaVM にかけたのであって GC にかけたつもりはないのです。GC に関しては nminoru さんのおっしゃる通りだと思います (というか僕はそこまで理解していませんでした)。
とはいえ、「ヒープを詰める」処理 (compaction という用語が不適切だそうなので) を行わない VM が現代的でない、と言えないことは、G7 さんがすでに指摘されており、僕も納得しています。
いろいろなトレードオフの中の一要素、ということですよね。事実、kaffe の実装では詰めないようですし…。
Only Jav^Hpanese available :-)