Tigerを使いこなす: 仮想マシンに関するアップデート情報

J2SE

developerWorksの記事．

http://www-6.ibm.com/jp/developerworks/java/050331/j_j-tiger03175.html

5.0でスレッドの優先度の扱いが変わったのが知っていたが，この文章を読んでもよくわからなかった．そこで次の文章"Thread Priority on the Solaris Platform"を読んでみた．

http://java.sun.com/j2se/1.5.0/docs/guide/vm/thread-priorities.html

非常に簡単にまとめると次のようになりそうだ．

  • Solaris 8まではM個のネイティブスレッドがN個のカーネルスレッド/LWP(Light Weight Process)に対応するM:Nモデル．
  • Solaris 9からは，1対1モデルに変更（びっくり．まあ，それ以前のモデルはよくまともに実装できたなあと思っていたから，これも当然のなりゆき？）．
  • Solaris 9からは，スレッドとLWPが1:1に対応するので，Thread.setPriorityメソッドでは，ネイティブプロセスローカル優先度の変更のためにthr_setprio()関数を実行するだけでなく，さらにLWPのディスパッチ優先度を変更するためにpriocntl()関数を実行するように変更．
  • TS (timeshare)クラスとIA (interactive)クラスのデフォルトのネイティブスレッドの優先度は，そのクラスに許されている最高値（←重要）．
  • Thread.setPriority(int)メソッドで設定したJavaレベルの優先度をpriocntl()関数を使ってOSの優先度に「素直に」マップする場合には，最高値を一致させることになるので，デフォルト優先度（NORM_PRIORITY）のJavaスレッドは，デフォルト優先度のCスレッドに比べると相対的に優先度が低くなるように実装せざるをえない．その場合には，I/Oなどでブロックされずに，計算を繰り返したり，スリープせずにスピンしているような場合には，CプログラムよりCPUサイクル的に不利になってしまう！
  • そこで，5.0では，Javaスレッドの5〜10までの優先度は，ネイティブスレッドと同様にTSクラスとIAクラスの最高値に設定されるようにした．これで，性能上の不利は解消された．
  • 明示的に優先度を変更しなければ，以前とまったく同じセマンティクス（そりゃ，当然）．
  • 問題点は，これらの範囲の優先度はSolaris上では同等に扱われてしまうこと．
  • Thread.setPriority(int)メソッドはコストが高いので，あまりやらない方がよい．

だが，こ，これが初級か？（笑）結局，翻訳が（原文も？）怪しいのが問題だったようだ．