【コラム】

Java API、使ってますか?

2 JSR 1 リアルタイムJava仕様

2/60

いちばん最初に登録されたJSR

本連載で最初に紹介するJSRとしては、「JSR 1: Real-time Specification for Java」を取り上げたい。Real-time Specification for Java(以下、RTSJ)はリアルタイム性を考慮したJavaプラットフォーム仕様で、制御装置や組み込み機器の分野で耐えられるJavaVMの拡張機能を定義している。「JSR 1」という番号からもわかるように、RTSJはJCPが発足して一番初めに登録されたJSRである。

RTSJの主な特徴を以下に示す。

  • リアルタイムシステムに対応したスケジューリング機能を提供
  • リアルタイム性を確保したJavaスレッドを作成可能
  • 非同期な割り込みイベントに対応
  • ガベージコレクションによる最長中断時間を保証
  • 非リアルタイムなJavaプログラムとの互換性を保つ

RTSJは1998年12月にJSRとして登録され、2002年10月には最終仕様がリリースされていた。現在はFinal Release 3が公開されており、参照実装はこのサイトから入手することができる。

ただし、この参照実装を使用するためにはTimeSysによるLinuxディストリビュージョンか、pthreadrtライブラリをインストールしたLinuxシステムが必要となる。

RTSJの概要

それでは、RTSJの中身をもう少し詳しく見てみよう。RTSJではリアルタイム処理を実現するために大きく分けて以下の7つのポイントを挙げている。

  • スレッドのスケジューリングとディスパッチング
  • メモリ管理
  • 物理メモリへのアクセス
  • 同期とリソースシェアリング
  • 非同期イベントハンドリング
  • 非同期転送制御
  • 非同期なスレッドの停止

スレッドのスケジューリング/ディスパッチング

リアルタイムシステムにおいてはスレッドのスケジューリングは非常に重要な問題だ。RTSJではリアルタイムOSと同様のメカニズムを採用することで適切なスレッドのスケジューリングを可能にする。しかし、実際には特定のスケジューリングメカニズムがすべての環境で有効に働くとは限らない。そこでRTSJではすべての実装で共通のポリシーとなるベーススケジューラを用意し、それと同時に、その他のスケジューリングポリシーも許容する柔軟な仕組みを提供する。

ベーススケジューラはスレッドに28段階の優先度を割り当てて管理するスケジューラで、javax.realtime.PrioritySchedulerクラスとして提供される。またRTSJのスケジューラによって管理されるスレッドはSchedulableインタフェースを実装していなければならず、スケジューラインスタンス(Schedulerクラスを継承したクラスのインスタンス)への参照を保持する。

なお、RTSJ自身にはリアルタイムのためのスレッドクラスとしてヒープメモリを使用するNoHeapRealtimeThreadクラスと非ヒープメモリを使用するRealtimeThreadクラスが用意されている。

メモリ管理

Javaでリアルタイムシステムを構築する場合、ガーベジコレクション(GC)の動作というのはとくに気になる部分である。プログラムの動作中にGCが実行されると、そのための遅延によってリアルタイム性が損われる危険性がある。

RTSJではそのような問題に対応するため、従来のヒープメモリに加えて次の概念を導入している。

  • スコープドメモリ
  • イモータルメモリ

スコープドメモリは通常のヒープメモリとは区別されるメモリ領域で、GCによって管理されない。メモリスコープにあるオブジェクトは最後に使用したスレッドが破棄されるまで保持される。イモータルメモリはスコープドメモリと同様にGCの影響を受けず、オブジェクトはアプリケーションが終了するまで保持される。ヒープメモリはイモータルメモリへの参照を、イモータルメモリはヒープメモリへの参照を、スコープドメモリはイモータルやヒープ、そして他のスコープドメモリへの参照をそれぞれ保持することができる。

スコープドメモリはScopedMemoryを継承したクラス(RTMemoryやVTMemoryなど)によって利用することができる。またイモータルメモリを利用するためにはImmortalMemoryなどのクラスが用意されている。それに対して従来のヒープメモリを扱うためのクラスとしてはHeapMemoryクラスが提供される。ヒープメモリはリアルタイム用のGCによって管理される。

その他、RTSJでは特定の物理メモリにマップされたメモリ領域を利用することができる。この機能はVTPhysicalMemoryやLTPhysicalMemory、ImmortalPhysicalMemoryといったクラスによって提供される。これによって、オブジェクトのためのメモリ領域を確保する際に物理メモリ上のベースアドレスやサイズなどを指定することができる。またRawMemoryAccessやRawMemoryFloatAccessなど、直接物理メモリにアクセスするためのクラスも用意されている。

同期とリソースシェアリング

RTSJはリアルタイムシステムが安全に同期処理を行えるように、優先度の逆転をコントロールするアルゴリズムを実装する。この機能はMonitorControlクラスやそのサブクラスによって提供され、これによってリソースに対するモニタを管理することができる。また、スケジュール管理されたオブジェクトやJavaスレッド間でのコミュニケーションのために非ブロックの待ち行列を提供する。

非同期処理

リアルタイムシステムでは実世界と密接に結び付いた動作を必要とされる。実世界のシステムはきわめて非同期的であるため、非同期処理の機能も充実していなければならない。

RTSJでは、まず非同期イベントをハンドリングするメカニズムが提供される。非同期イベントはAsyncEventクラスで定義され、それを処理するハンドラとしてAsyncEventHandlerクラスが用意されている。AsyncEventHandlerクラスはSchedulableインタフェースを実装しているため、非同期イベントのハンドリングもRTSJのスケジューラによって管理される点が特徴だ。

また、RTSJで提供される機能のひとつに非同期転送制御がある。これはJavaの例外処理を拡張したメカニズムで、非同期な割り込みを処理することができる。これはAsynchronouslyInterruptedExceptionクラスとして定義される。

非同期転送制御と同様に、RTSJでは非同期にスレッドを終了させるメカニズムも持っている。通常のJavaスレッドの場合、非同期なスレッドの停止は非常に危険であるとされている。RTSJではこれを安全にコントロールして終了させることが可能になる。

RTSJ version 1.1に向けて

現在、JCPにはRTSJの次期バージョンとなる「JSR 282: RTSJ version 1.1」が登録されており、仕様策定の議論が進められている。RTSJ 1.1はJSR 1からのマイナーバージョンアップであり、これによってパフォーマンスや使い勝手がより向上する予定だ。

JSR 1が申請されたころに比べると、ハードウェアの性能はもとよりJavaそのもののパフォーマンスも格段に向上しており、リアルタイム分野でのJavaの活躍に期待する声も大きい。2005年にはボーイング社がRTSJを採用したことでも話題になった。RTSJが浸透することで、今後Javaの活躍する場面はさらに拡がっていくだろう。

提供:毎日就職ナビ

会員登録はこちら

学生のための就職情報サイト「毎日就職ナビ」。6,000社以上の新卒採用情報が常時掲載され、社内の雰囲気が伝わる情報画面、さまざまな項目での会社検索、エントリーや説明会検索など、機能も充実。無料適職診断、就活Q & A、エントリーシート添削講座など、就職活動に役立つ記事も満載です。研究者、エンジニアを目指す学生の方々も是非エントリーしてください。お待ちしています!

毎日コミュニケーションズはプライバシーマークを取得しています。

2/60

インデックス

連載目次
第60回 どうなる? 今後のJavaプラットフォーム(Java SE編)
第59回 どうなる? 今後のJavaプラットフォーム(Java EE編)
第58回 Java SE 7の要注目機能"クロージャ"はどうなるのか その6
第57回 Java SE 7の要注目機能"クロージャ"はどうなるのか その5
第56回 Java SE 7の要注目機能"クロージャ"はどうなるのか その4
第55回 Java SE 7の要注目機能"クロージャ"はどうなるのか その3
第54回 Java SE 7の要注目機能"クロージャ"はどうなるのか その2
第53回 Java SE 7の要注目機能"クロージャ"はどうなるのか
第52回 Early Draftが公開されたJSF 2.0
第51回 EJBから独立したJava Persistence 2.0
第50回 モバイルJavaの新しい潮流となるか - MSA 2.0のドラフト公開
第49回 やっぱり基本はServlet - Servlet 3.0のEarly Draftを読む
第48回 JOGLで3Dプログラミング その4
第47回 JOGLで3Dプログラミング その3
第46回 JOGLで3Dプログラミング その2
第45回 JOGLで3Dプログラミング
第44回 JARファイルを効率的にネットワーク転送するためのPack200形式
第43回 Early Draftで把握するEJB 3.1の新機能
第42回 次世代の携帯端末向けJava仕様"MIDP 3.0"はどうなるか その2
第41回 次世代の携帯端末向けJava仕様"MIDP 3.0"はどうなるか その1
第40回 リソースアダプタによる接続の仕組み
第39回 JCAを利用したシステム間接続
第38回 Java EEと外部システムの接続性を支えるJCAがバージョンアップ
第37回 Javaのモジュラリティ強化を担う"スーパーパッケージ"とは
第36回 JSR 308対応のコンパイラを試す
第35回 公開されたJSR 308のEarly Draftを検証する
第34回 スクリプト言語とJavaを結びつけるJSR 223
第33回 Java EE環境に統一されたコンポーネントモデルを提供するJSR 299 その2
第32回 Java EE環境に統一されたコンポーネントモデルを提供するJSR 299 その1
第31回 Javaの文法がそのまま使えるスクリプト言語"BeanShell"
第30回 Javaアプリケーションにオブジェクトのキャッシュ機構を提供するJCache API
第29回 Javaアプリケーションからのリソース管理を可能にするJSR 284
第28回 XMLデータソースへの問い合わせはJSR 225で
第27回 Portlet Specification 2.0をもっと手軽に利用する
第26回 次期Javaポートレット仕様となるJSR 286
第25回 JSFとポートレットをつなげるJSR 301
第24回 Webサービス向けのポートレット仕様「WSRP」
第23回 高い相互運用性を実現するポートレットAPI - JSR 168
第22回 Java EE環境でタスクのスケジューリングを可能にするJSR 236
第21回 Java EE環境でのスレッドプログラミングを可能にするJSR 237
第20回 音声認識/合成のためのAPI - Java Speech APIとJSR 113
第19回 JSR 291でJavaプラットフォームにダイナミックコンポーネントモデルを導入
第18回 JAX-RSで簡単RESTful - JSR 311
第17回 待望のServlet 3.0がJSRに登場 - JSR 315
第16回 アノテーションを使ってバグ退治 - JSR 305
第15回 アノテーションをさらに広い範囲で利用可能にするJSR 308
第14回 Webアプリケーション開発の要となるか - JSF 2.0がJSRに登場
第13回 Webサービス経由でのJMX Agentへの接続を可能にするJSR 262
第12回 Javaアプリケーションのモジュール化をサポートするJava Module System
第11回 "NIO.2"がやってきた - JSR 203: More New I/O APIs for the Java Platform
第10回 JSR 295: Beans Bindingの参照実装を試す
第9回 けっこう便利! 単位を扱うAPI -- JSR 275: Units Specification
第8回 アノテーションでバリデーション - JSR 303: Bean Validator
第7回 Swing開発の救世主となるか - Swing Application Framework
第6回 JavaBeansのプロパティを同期させるバインディングAPI
第5回 誰よりも早く"Java SE 7"を睨む
第4回 日時情報の取り扱いを改善する JSR 310: Date and Time API
第3回 古いAPIも進化している!? - JSR 919: JavaMail 1.4
第2回 JSR 1 リアルタイムJava仕様
第1回 JCPによって進められるJava関連技術の標準化

もっと見る



人気記事

一覧

イチオシ記事

新着記事