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

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 さんの書込みでい
                うところの「それとも、その副作用のあるGCしか使う予定が無い、
                言い換えれば使おうとしている処理系のGCがお望みのアルゴリズム
                であることが既に判っている、という状況」といえるのではないか、
                前の書込みに補足すれば「GC がどのようなアルゴリズムで行われ
                るにせよ、JavaVM においては常に compaction は行われている
                と考えていいのではないでしょうか?」というのが趣旨です。

                #組み込み系まで含めると必ずしも真ではないかもしれませんが、
                #J2SE 以上の各社の実装を見ているとそう言えるのではないかと。

                J2SE 以上の実装では半ば常識的なことながら、JavaVM Spec. で
                はっきり規定された仕様ではない、という点を、G7 さんは暗に指
                摘されていたのかな…?
                --
                Only Jav^Hpanese available :-)
                親コメント
              • by G7 (3009) on 2002年02月16日 13時46分 (#63516)
                >ご存じの通り Java にはポインタがありませんから、C でのよう
                >にプログラム側でフラグメンテーションに対処することが非常に難しく、

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

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

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

                >JavaVM においては常に compaction は行われている

                そこでいう「JavaVM」がどこまでを指すか?に拠るでしょうね。

                Sunなりなんなりの1つ(^^;の実装について語りたいなら、
                メーカーに質問するとか、気に入らないなら(金を出して)変更を迫るとか、
                いろんな手が有り得そうです。

                でも、KaffeやWavaみたいな偽Java(^^;とか、あるいは各種(?)小型組み込み向けJavaとか、も
                含めて考えると、その期待が満たされてるかどうかは、また違う話になるわけですよね。

                >#J2SE 以上の各社の実装を見ているとそう言えるのではないかと。

                上に書きましたが、Kaffeって、どう捉えたらいいんでしょうね?(^^;

                J2SEとは…あ、どうせ言えないのか。
                Java1.2相当にも、まだなってないんでしたっけかあれ?
                … http://www.kaffe.org/ … あ。まだ1.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 がはじまるまでのタイムラグだとかがあります。
                --
                コンタミは発見の母
                親コメント
              • by Digitune (119) on 2002年02月18日 16時23分 (#63988) ホームページ 日記
                > compaction をやることが現代的な GC だとは思いません。

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

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

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

普通のやつらの下を行け -- バッドノウハウ専門家

処理中...