クラス・ローダーAPIの修正によるデッドロックの回避

完全な製品バージョン：
Java のバージョン"1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition（build 1.3.1_01）
Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)

完全なオペレーティング・システム・バージョン：
カスタマ  Windows 2000 [Version 5.00.2195]

問題の説明：
バグID 4406709で、最近、以下のメソッドの"private synchronized"
修飾子に関するバグの届け出がありました（ただし対処
されませんでした）。

java.lang.ClassLoader.loadClassInternal(String name)
throws ClassNotFoundException;

これにより、そのユーザーの特殊な用途向けの
派生クラスローダーでデッドロックが発生します。

このバグは、仕様に違反するものではないという理由で、クローズされ
ました。 それはまったくそのとおりです。

それでも、そのトピックをここで再度取り上げたいと思います。ただし今回は、
"膨大な素晴らしい可能性"のカテゴリではなく、
"使いやすさ"のカテゴリに入れるものとします。

JBoss3.0（http://www.jboss.org）で、私たちは（というよりはむしろ
Marc Fleuryは）、モジュール性とホット・デプロイ機能を豊富に持つ、
ツリー・ベースではない実行時依存関係チェック用クラスローダーの
委譲モデルを使用した実験で、かなりの成果を
あげました。 "従来型の"ツリー・モデルでは、このような
機能は利用できません。

実験したモデルでは、ツリー・モデルとは対照的に、
loadClass(String name)呼出しを、（たとえばリンクしようとしている）
開始クラスローダーの親ではない別の
クラスローダーにディスパッチしても違反には
なりません。

そのため、クラスローダーへのアクセス中にはスレッド作成を
制限するなどの対策をとらなければ、クラスローダーグラフの
トポロジーによっては、インターセプト不可のloadClassInternal
呼出しに起因するデッドロックが発生する
可能性があります。 安全にそのような対策をとる方法が
ないため、やはり不要なデッドロックは発生します。

以前に報告のあったバグに応えて、SUNのエンジニアの1人が、
クラスローダーの影響を受けない
別個のオブジェクトに委譲することを提案しましたが、
これは不可能です。最終的には、
他の（ロックされている可能性のある）クラスローダーに
再度委譲しなければならないためです。

私がこの問題に対する現在の決定に深く失望していることがお分かり
いただけるでしょう。 現在の解決策を緩和することで、
非常に大きな可能性が開かれることをご理解いただきたいと
思います。 私見ですが、loadClass()を同期させるか、
loadClassInternal()を保護すれば、仕様の
要件を満たすのに十分なのではないでしょうか。

自分はこの問題について十分に理由を述べたり
説明したりできる立場にはないかもしれませんが、
これがVMのうちでも非常に重要な部分であることは承知して
います。

この問題にさらに深い関わりのある他のユーザーが、コードとともに
コメントを付けて、私よりも適切にこの要求を裏付けて
くれることを期待します。
（レビュー ID：145293） 
=====================================================

該当なし

xxxxx@xxxxx   2002-05-28
この決定について再び取り上げます（バグ4406709から）。


xxxxx@xxxxx   2002-06-20
これは、バグとして扱うことが妥当であると
考える必要があります。バグ4699981で示されて
いるように、ClassCircularityErrorが
スローされた場合に、クラスローダー・オブジェクトは
ロックを保持することはできません。
このようになる原因は、ユーザー・
クラスローダーがクラスローダーの
ロックを放棄したときに、どのスレッドが
どのクラスをロードしているかに関してVMが
混乱しているためです。  ユーザーが
クラスローダーのロックを放棄する
可能性があるため、ロックが保持されることは
保証できず、ロックに依存すべきではありません。

4699981のテスト・ケースをここで使用します。
----------------------------------------------------

この作業はDolphinを対象とします。
これにより、いくつかの対策が実施されます。
一部は既に進行中ですが、作業全体は、Dolphinが完成するまで
続きます。

この作業では、クラスのロードをあるレベルで再構築する必要が
あり、下位互換性の制約のため、おそらくAPIを追加する
ことになります。

このテストケースおよびカスタマが提供する追加のテストケースが
非常に役立ち、解決を目的とした改良によって
問題が解決されると確信しています。

新しい設計と実装によって、対応可能なすべてのニーズを
確実に満たすために、このレポート作成者や、
名前をこのレポートに追加したユーザーと
緊密に連携することも望んでいます。 

この問題を解決するために実行される具体的なステップ：

1) 4699981 クラスの循環性検出を修正する - Mustang

2) - 内部ロックのためにクラスローダー・オブジェクトを使用しない
ように、VMの内部ロック・メカニズムと粒度を再設計する
- VMのクラスロードのロジックがMTセーフであるようにする
3) - ライブラリ内に新規クラスロードAPIを設計/実装する
4) 4670071 - 新規クラスロードAPIをVMでサポートする

明らかに、これらのステップのいくつかは並行して実施されますが、
このステップで必要な変更の概略が分かりやすくなります。

最大の技術的な課題の1つは、下位互換性です。
このステップは、かなり多くの
カスタマのクラスロード・モデルに適合しないため、
これを変更する必要があるという問題がある一方で、
古いAPIも引き続き現在と同じ動作をするように保証する
必要もあります。

アプリケーションが引き続き実行できるように、
現在のクラスロード動作について、カスタマから
テスト・ケースを寄稿していただければ、
下方互換性について対処するために役立ちます。 

新規APIの設計およびテストの両方において、また、現在の
アプリケーションが引き続き問題なく実行されることを
保証できるように、コミュニティと緊密に
連携していきたいと考えています。


xxxxx@xxxxx   25.04.05 14:06:57 GMT

xxxxx@xxxxx   2005-04-27 12:56:48 GMT
APIの変更をプロトタイプ化できるようにするためにJVMで必要な、
基盤となる技術変更が遂に完了しました。

これらのクラスローダーAPIの変更の試案を、以下の場所に投稿します。

http:dcstaff.invokedynamic.info/index.php?
title=Image:classloaderproposal.tgz

この案をお読みになり、ご検討の上、フィードバックをお送りください。
最初のフィードバックを取り入れた後、
2008年12月中旬にプロトタイプを提供することを目標としています。

時間がかかったことについてお詫びいたします。 
デッドロックを発生させることなく複数のクラスを
並行してロードできるように、VMロジックに対して基礎部分の
変更を行っていました。
JDK6: クラス循環性のバグを修正
Hotspot 10： JDK 6u4： パラレル・クラス・
ローディングを処理するためにVM共通クラス解決のロジックを変更

更新された提案の参照先は、以下の場所に示されています。
http://openjdk.java.net/groups/core-libs

core-libs-  xxxxx@xxxxx というメール・エイリアスで話し合いに
ご参加ください。

エイリアスに参加するには、
http://mail.openjdk.java.net/mailman/listinfoを参照してください。
投稿日： 2008-11-13 18:54:53.0

この修正のVM側の変更は、4670071でVMに追加されます。
クラス・ライブラリへの変更は、4735126で行われます。
変更には、パラレル・クラス・ローディングをサポート可能な、
クラスローダー用の新規APIが含まれます。
すなわち、デッドロックを回避する新しい
パラレル・クラス・ローディング機能を利用する
カスタム・クラスローダーには、コードの変更が必要です。

既存のクラスローダーは、変更されずに、
引き続き現在と同じように機能します。
投稿日： 2008-12-19 21:19:09.0

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c81d2ef51ca3
投稿日： 2009-01-06 17:54:15.0