アカウント名:
パスワード:
GCを利点として挙げる人がいますが、それも僕はどうかと思っています。 GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。
GC を単にメモリリークを防ぐためのものと考えると大したありがたみはありませんが,メモリフラ
確認ですが、
Java の Heap に関しては、激しくオブジェクトの生成/回収を繰り返してもフラグメンテーションによって新規オブジェクトが生成できない、とゆー事態には陥ったことがない
というのは、異なるサイズのオブジェクトを生成、回収した場合ですか? というのは、同じサイズばっかりだったらそもそも空きメモリの断片化は問題にならないはずなので。
ちなみに、アドレス空間を長持ちさせると(Unixのkernelはその典型)、オブジェクトの生成にともなう再初期化が大きなオーバヘッドになってきます。これは、オブジェクトが不要になった
それ、もしかして、解放された領域を、「同じ種類」ごとに別々のフリーリストにぶら下げたりする、んでしょうか?
厳密には、page level allocator(つまりvirtual memory)から切り出してきた、free objectのcacheに放り込みます。このcacheはper object typeです。
だとしたら、種類という概念がクラスのおかげ(乱暴な言いかただが)でC的世界よりずっとはっきりしているoop処理系においては、より旨くやれるんではないでしょうか?
それはなんともいえません。Uresh Vahaliaは著書Unix Internals: The New Frontiers [amazon.com]の中で、以下のようなslab allocatorの欠点を指摘しています(以下は邦訳より)。
スラブ・アロケータの1つの欠点は、それぞれのオブジェクトの種類に対してことなるキャッシュを持つことに起因する、管理上のオーバヘッドである。 (中略) (キャッシュに含まれる)要素が少なく、あまり使用されないキャッシュの場合のオーバヘッドは、しばしば、無視できないものである。
となると、cacheを使うか否かを決める問題が生じます。Solarisの場合、私が本や実装を(誰か1994年夏のUsenix [usenix.org]予稿集持ってませんか?)見た限りでは、cacheを使うか否かはobject type毎にhardcodeされている(すなわち人間が決めている)ようです。Unix kernelならこれでも何とかなりますが、個々のプログラムを支える枠組み、すなわち言語処理系やruntime libraryなどの場合は機械的に決めないと使いものにならないでしょう。Solarisがこれをやっていないということは、機械的な決定は難しいということでしょうか。
より多くのコメントがこの議論にあるかもしれませんが、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)
確認ですが、
というのは、異なるサイズのオブジェクトを生成、回収した場合ですか? というのは、同じサイズばっかりだったらそもそも空きメモリの断片化は問題にならないはずなので。
ちなみに、アドレス空間を長持ちさせると(Unixのkernelはその典型)、オブジェクトの生成にともなう再初期化が大きなオーバヘッドになってきます。これは、オブジェクトが不要になった
Re:GCの必要性 (スコア:1)
それ、もしかして、解放された領域を、「同じ種類」ごとに
別々のフリーリストにぶら下げたりする、んでしょうか?
だとしたら、種類という概念がクラスのおかげ(乱暴な言いかただが)で
C的世界よりずっとはっきりしているoop処理系においては、
より旨くやれるんではないでしょうか?
Re:GCの必要性 (スコア:1)
厳密には、page level allocator(つまりvirtual memory)から切り出してきた、free objectのcacheに放り込みます。このcacheはper object typeです。
それはなんともいえません。Uresh Vahaliaは著書Unix Internals: The New Frontiers [amazon.com]の中で、以下のようなslab allocatorの欠点を指摘しています(以下は邦訳より)。
となると、cacheを使うか否かを決める問題が生じます。Solarisの場合、私が本や実装を(誰か1994年夏のUsenix [usenix.org]予稿集持ってませんか?)見た限りでは、cacheを使うか否かはobject type毎にhardcodeされている(すなわち人間が決めている)ようです。Unix kernelならこれでも何とかなりますが、個々のプログラムを支える枠組み、すなわち言語処理系やruntime libraryなどの場合は機械的に決めないと使いものにならないでしょう。Solarisがこれをやっていないということは、機械的な決定は難しいということでしょうか。