パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Java 1.4SE正式リリース」記事へのコメント

  • 未だにJava人気あるんですね。
    僕はいまいちJavaの良さが分かりません。
    誰かJavaのすばらしさを語ってもらえないでしょうか。
    • 「Java は駄目」とか言う人の話をよく聞いてみると、
      Java Applet のことだったり、 JavaScript のことだったりする
      ことがあるので、いっかい問い詰めてみたほうがいいです。
      • 僕がJavaで駄目だと思うところはまず実行速度です。
        JITの技術がありますが本質的な解決策では無いと思います。
        しかもテキスト処理なんかはJITを使ってもAwkよりもPerlよりも遅い。

        次に移植性です。
        Write Once Run Anywareとか言っていますがはっきり言って実現されて無いと思います。
        移植性 + 速度
        で考えるとCの方が上だと思っています。

        GCを利点として挙げる人がいますが、それも僕はどうかと思っています。
        GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。
        1時間ぐらいだったら動くけど長時間動かしているとVMが落ちることがありますし、その時のバ
        • GCを利点として挙げる人がいますが、それも僕はどうかと思っています。
          GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。

          GC を単にメモリリークを防ぐためのものと考えると大したありがたみはありませんが,メモリフラ

          • >GC を単にメモリリークを防ぐためのものと考えると大したありがたみはありませんが,メモリフラグメン
            >テーションを防ぐためのものと考えれば,その恩恵は計り知れないと思います。

            え?

            http://www.is.s.u-tokyo.ac.jp/~vu/jugyo/processor/process/soft/compilerresume/gc/gc.html
            >Copying GCの興味深い性質は、コピーするときにオブジェクトの空きをつめるため、fragmentationが発生しないということである。

            によると、フラグメンテーションを無くす機能(つーか嬉しい副作用?)を期待できるかどうかは
            GCのアルゴリズム次第であって、GC一般の性質ではない、と読めます
            • > によると、フラグメンテーションを無くす機能(つーか嬉しい副作用?)を期待できるかどうかは
              > GCのアルゴリズム次第であって、GC一般の性質ではない、と読めますけど?

              GC がどのようなアルゴリズムで行われるにせよ、compaction は
              行われてるのではないでしょうか? compaction されるというこ
              とは、その時点でフラグメンテーションも解消される、ということ
              ですよね?違う?

              Java の Heap に関しては、激しくオブジェクトの生成/回収を
              繰り
              --
              Only Jav^Hpanese available :-)
              • > GC がどのようなアルゴリズムで行われるにせよ、compaction は 行われて るのではないでしょうか?

                いいえ。G7さんが紹介してくれましたURLがよい資料なので、詳しくは そちらを見てください。ここでは簡単に言いますと、GCは古典的には、

                1. Reference Count (被参照数が0になったオブジェクトを回収)
                2. Mark & Sweep (生きているオブジェクトにマークをつけ、最終的にマークがつかなかっ
              • > このうち、1.と2.は compactionしません。

                実際に compaction を行わない GC 実装が存在することはもちろ
                ん知っていますし、JavaVM Spec. が Heap 管理については 100%
                実装者の裁量に任せている、ことも分かっていますが、しかし、
                ご存じの通り Java にはポインタがありませんから、C でのよう
                にプログラム側でフラグメンテーションに対処することが非常に難しく、
                となると、まっとうな実装者ならばフラグメンテーションが起こら
                ないように GC を設計するのではないか、という予想のもと、こと
                現代的な実装の JavaVM に関していうなら、G7 さんの書込みでい
                うところの「それ
                --
                Only Jav^Hpanese available :-)
              • >ご存じの通り Java にはポインタがありませんから、C でのよう
                >にプログラム側でフラグメンテーションに対処することが非常に難しく、

                ああ。メモリプールというかmallocに相当するものを自作するという話題ですか。
                たしかにjavaでは何処をどういじってもソレっぽいことは出来ないですね。

                >現代的な実装の JavaVM に関していうなら、G7 さんの書込みでい
                >うところの「それとも、その副作用のあるGCしか使う予定が無い、
                >言い換えれば使おうとしている処理系のGCがお望みのアルゴリズム
                >であることが既に判っている、という状況」といえるのではないか、

                それを称して「
              • > それを称して「現代的」と呼ぶんでしょうか?>識者諸兄
                > 俺は知らないんですが。

                compaction をやることが現代的な GC だとは思いません。

                長い GC の歴史の中である程度 よい GC の条件が見えてきています。
                非並列 GC の場合に限ると以下の 4点ぐらいを押さえた GC が現代的
                な GC ではないでしょうか?

                1. オブジェクトの寿命を意識すること

                    オブジェクトには生成されたけど一度も使われずに終わる
                    単寿命なやつから VM が終わるまで居続ける長生きなオブ
                    ジェクトまで寿命に差があります。
                    現代の GC
                --
                コンタミは発見の母
              • by Digitune (119) on 2002年02月18日 16時23分 (#63988) ホームページ 日記
                > compaction をやることが現代的な GC だとは思いません。

                「現代的」は JavaVM にかけたのであって GC にかけたつもりはないのです。GC に関しては nminoru さんのおっしゃる通りだと思います (というか僕はそこまで理解していませんでした)。

                とはいえ、「ヒープを詰める」処理 (compaction という用語が不適切だそうなので) を行わない VM が現代的でない、と言えないことは、G7 さんがすでに指摘されており、僕も納得しています。

                いろいろなトレードオフの中の一要素、ということですよね。事実、kaffe の実装では詰めないようですし…。
                --
                Only Jav^Hpanese available :-)
                親コメント

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

処理中...