JP6295193B2

JP6295193B2 - 情報処理装置、情報処置装置のリソース制御方法及びそのプログラム

Info

Publication number: JP6295193B2
Application number: JP2014254091A
Authority: JP
Inventors: 知之藤野; 啓一郎柏木; 田中　裕之; 裕之田中
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2014-12-16
Filing date: 2014-12-16
Publication date: 2018-03-14
Anticipated expiration: 2034-12-16
Also published as: JP2016115180A

Description

本発明は、リソースの制御を行なうことができる情報処理装置に関する。

図３は、従来のブラウザを説明するための図である。

同図に示すように、従来のブラウザは、ＪａｖａＳｃｒｉｐｔ（登録商標）エンジン１、レンダリングエンジン２、画面表示・ＵＩ部３及びアプリケーションフレームワーク４を有している（例えば、非特許文献１参照）。

ＪａｖａＳｃｒｉｐｔエンジン１は、ＪａｖａＳｃｒｉｐｔの解析、機械語変換、処理実行を行い、レイアウトを動的に変更するインタプリタである。ＪａｖａＳｃｒｉｐｔエンジン１は、レンダリングエンジン２の命令を受けて駆動される。

レンダリングエンジン２は、ブラウザの主処理部分であり、ＷＥＢサーバ１１からWebコンテンツ取得、HTML/CSS解析、レイアウト・描画等の処理を行なう。

画面表示・ＵＩ部３は、レイアウト情報を取得し、画面表示を行なう。また、ユーザからの入力を待ちうける。

アプリケーションフレームワーク（App FW）４は、Qt, Gtk+等、イベント駆動のプログラミング機構を与え、NW処理や描画処理等を容易に開発可能にするフレームワークである。

ブラウザはユーザの命令を待ちうけ、Webページを読込み、解析し、画面表示を行なうソフトウェアである。

まず、ユーザからの命令（ページ読込やスクロール等）を画面表示・ＵＩ部３にて受け取り、レンダリングエンジン２の所定の関数を呼び出す。レンダリングエンジン２は新たなページの読込が必要な場合、外部のWebサーバ１１とHTTP通信を行いHTMLや画像をはじめとするWebコンテンツを構成するデータをダウンロードする。

レンダリングエンジン２は、ダウンロードが完了したデータから解析を行い、レイアウト情報を抽出する。同時に、ＪａｖａＳｃｒｉｐｔを抽出し、ＪａｖａＳｃｒｉｐｔエンジン１に渡す。ＪａｖａＳｃｒｉｐｔエンジン１は、図４に示すように、ＪａｖａＳｃｒｉｐｔを解析して、機械語の命令リストに変換し（Ｓ１）、その先頭から順番に実行する（Ｓ２）。Ｓ２における命令の実行は、リストの先頭の命令が１つ実行されるごとに、リストから先頭の命令が削除されることを意味する。

そして、その実行結果として、レンダリングエンジン２が保持するレイアウト情報を書き換えることができる。レイアウト情報は変更があるたびに画面表示・ＵＩ部３に渡され、画面描画が行なわれる。

これらの処理の際、ユーザ入力の処理・データのダウンロード・解析・レイアウト処理・画面描画などがそれぞれ並行して処理される。これにはApp FW４のイベント駆動機構が用いられる。

具体的にはレンダリングエンジン２や画面表示・ＵＩ部３にてApp FW４のイベントキューに必要な処理を登録し、App FW４が定期的にキュー内の処理を実行していくことで実現している。

Ｓ２において、命令が実行されると、次に、未実行命令があるか否かの判断が行われる（Ｓ３）。Ｓ３において、未実行命令がないと判断された場合には、ＪａｖａＳｃｒｉｐｔ処理を終了する。一方、未実行命令があると判断された場合には、Ｓ２の処理に移る。

情報処理端末上で、ブラウザによるWeb閲覧を行なう際、ＪａｖａＳｃｒｉｐｔの処理が複雑なページを表示させると動作が遅くなりユーザ体感品質が低下する。これは、従来のブラウザではＪａｖａＳｃｒｉｐｔの処理に割くＣＰＵリソース量に制限が無く、閲覧するページによってはＪａｖａＳｃｒｉｐｔ処理が多くのCPUリソースを占有し、端末のＣＰＵリソースの不足が生じるためである。

このような問題を解決するため、ブラウザにおける過度なＪａｖａＳｃｒｉｐｔ処理によるCPU消費を抑制する技術がある。具体的には、ＪａｖａＳｃｒｉｐｔエンジンで使用しているＣＰＵ時間が一定時間以上になった場合にコールバックを呼ぶことにより、ＪａｖａＳｃｒｉｐｔの負荷の重いページを閲覧して動作が固まってしまったときに、ユーザにＪａｖａＳｃｒｉｐｔを停止させる選択肢を与えるものである（例えば、非特許文献２参照）。

また、上記課題を解決するため、ブラウザにおける処理をマルチスレッドで動作させる技術もある（例えば、非特許文献３参照）。

A. Grosskurth and M. W. Godfrey, "A reference architecture for Web browsers", Proceedings of the 21st IEEE International Conference on Software Maintenance (ICSM’05), P. 661 (2005). JavaScript Core, https://github.com/aosm/ＪａｖａＳｃｒｉｐｔCore/blob/master/runtime/Watchdog.h Compositor Thread Architecture , http://www.chromium.org/developers/design-documents/compositor-thread-architecture

しかしながら、従来のブラウザでは、停止させること無く柔軟にＪａｖａＳｃｒｉｐｔ処理のCPUリソース消費量を制御することは難しいという問題があった。

本発明は上記実情に鑑みてなされたものであり、ＪａｖａＳｃｒｉｐｔの動作を制限し、ユーザからの入力処理やレンダリング処理等にＣＰＵリソースを割り当てることにより、ユーザ体感を向上することができる、情報処理装置、情報処置装置のリソース制御方法及びそのプログラムを提供することを目的とする。

本発明の第１の観点によれば、ＪａｖａＳｃｒｉｐｔ処理の動作を監視するＪａｖａＳｃｒｉｐｔ側タイマと、アプリケーションフレームワーク処理に時間を割り当てるためのアプリケーション側タイマとを具備し、前記ＪａｖａＳｃｒｉｐｔ側タイマは、前記ＪａｖａＳｃｒｉｐｔ処理の累積消費時間が閾値となる第１の累積消費時間を超えた場合に、前記アプリケーション側タイマを起動させる起動手段を具備し、前記アプリケーション側タイマは、前記ＪａｖａＳｃｒｉｐｔ側タイマにより起動されると、処理を前記アプリケーションフレームワーク処理に渡すとともに、前記アプリケーションフレームワーク処理の累積消費時間が閾値となる第２の累積消費時間を超えた場合に、処理を前記ＪａｖａＳｃｒｉｐｔ側タイマに渡すアプリケーション側切替手段を具備し、前記ＪａｖａＳｃｒｉｐｔ側タイマは、さらに、前記アプリケーション側切替手段により処理が渡された場合、前記渡された処理を前記ＪａｖａＳｃｒｉｐｔ処理に戻すＪａｖａＳｃｒｉｐｔ側切替手段を具備する、情報処理装置、である。

本発明の第２の観点によれば、第１の観点において、前記ＪａｖａＳｃｒｉｐｔ側タイマは、ＪａｖａＳｃｒｉｐｔを受け取り、実行するＪａｖａＳｃｒｉｐｔエンジンから前記ＪａｖａＳｃｒｉｐｔ側タイマがチェックされる毎に、前記ＪａｖａＳｃｒｉｐｔ処理の消費時間が加算される、情報処理装置である。

本発明の第３の観点によれば、第１の観点において、前記アプリケーション側切替手段により、前記ＪａｖａＳｃｒｉｐｔ側タイマによる前記ＪａｖａＳｃｒｉｐｔ処理の動作の監視に切り替えた場合、前記ＪａｖａＳｃｒｉｐｔ側タイマ及びアプリケーション側タイマをクリアする、情報処理装置である。

本発明の第４の観点によれば、第１の観点において、前記第１の累積消費時間及び前記第２の累積消費時間のうちの少なくとも１つは、前記情報処理装置のリソースに基づいて定められる、情報処理装置である。

本発明によれば、ＪａｖａＳｃｒｉｐｔの動作を制限し、ユーザからの入力処理やレンダリング処理等にＣＰＵリソースを割り当てることにより、ユーザ体感を向上することができる。

本実施の形態に係るブラウザの構成を示す図である。本実施の形態のブラウザの動作について説明するためのフローチャートである。従来のブラウザを説明するための図である。従来のブラウザの動作について説明するためのフローチャートである。

＜本発明の実施の形態の概要＞
上述のように、従来のブラウザでは、外部から処理ごとにCPUリソース消費量を制御することは難しい。そこで、本発明は、内部にタイマを設置し、ＪａｖａＳｃｒｉｐｔ処理とその他の処理のCPUリソース消費を個別に制御する仕組みを実現する。

そして、このタイマを利用し、ＪａｖａＳｃｒｉｐｔ処理の消費するCPUリソースを制限することで、上記課題を解決し、ユーザ体感品質を向上させる。

本実施形態では、非特許文献１のアーキテクチャにリソース制御を行なう手段を追加することにより、非特許文献３のようにマルチスレッド化を行なうことなく、シングルスレッドのままで簡易にリソースを配分する。
＜実施の形態＞
以下、実施の形態について、図面を参照して説明する。

図１は、本実施の形態に係るブラウザの構成を示す図である。なお、図３と同一部分には、同一符号を付して説明する。同図において、本実施の形態のＪａｖａＳｃｒｉｐｔ側タイマ２１、App側タイマ２２及びタイマ制御モジュール２３は、ブラウザ内に設けられている。

実施形態のＪａｖａＳｃｒｉｐｔエンジン１には、定期的にＪａｖａＳｃｒｉｐｔ側タイマ２１のチェックを行なうチェックポイント１ａが設けられる。チェックポイント１ａは、処理中に頻繁に呼ばれる関数内に設置される。

App FW４は、Qt, Gtk+等、イベント駆動のプログラミング機構を与え、NW処理や描画処理等を容易に開発可能にするフレームワークである。

ＪａｖａＳｃｒｉｐｔ側タイマ２１は、ＪａｖａＳｃｒｉｐｔの動作を監視するタイマであり、消費したCPU時間が一定時間以上になったらタイムアウトし、App側タイマ２２を呼び出す。

App側タイマ２２は、App FW４用に時間を割り当てるためのタイマであり、一定時間、ＪａｖａＳｃｒｉｐｔに時間を渡さないようにApp FW４のイベント処理に時間を割り当てる。App FW４は、App FW４のイベントキューが空の場合は、短い時間sleepし再度App FW４に時間を割り当てる。前記時間割り当てを繰り返し、累積時間が一定時間以上になったらタイムアウトし、ＪａｖａＳｃｒｉｐｔ側タイマを呼び出す。

タイマ制御モジュール２３は、情報処理端末のリソース状況を測定し、ＪａｖａＳｃｒｉｐｔ側タイマ２１および App側タイマ２２のタイムアウト値を制御する。

次に、本実施の形態のブラウザの動作について、図２のフローチャートを参照して説明する。本実施の形態のブラウザの動作は、従来のブラウザの動作に加え、ＪａｖａＳｃｒｉｐｔエンジン１の処理実行時に独自の動作を行なう。ＪａｖａＳｃｒｉｐｔエンジン１は、レンダリングエンジン２からＪａｖａＳｃｒｉｐｔを受け取り実行する。

ＪａｖａＳｃｒｉｐｔエンジン１は、ＪａｖａＳｃｒｉｐｔ処理が開始されると、ＪａｖａＳｃｒｉｐｔを解析して、機械語の命令リストに変換する（Ｓ１１）。次に、ＪａｖａＳｃｒｉｐｔ側タイマ２１により、ＪａｖａＳｃｒｉｐｔ処理時間のカウントが開始される（Ｓ１２）。

その後、ＪａｖａＳｃｒｉｐｔ側タイマ２１は、ＪａｖａＳｃｒｉｐｔ処理時間がタイムアウト時間を超えているか否かの判断を行なう（Ｓ１３）。Ｓ１３において、ＪａｖａＳｃｒｉｐｔ処理時間がタイムアウト時間を超えていると判断された場合、ＪａｖａＳｃｒｉｐｔ側タイマ２１は、App側タイマ２２をスタートさせる。App側タイマ２２は、ある一定時間をApp FW４に処理時間として与え、カウントを開始する（Ｓ１４）。

具体的には、上述のように、ＪａｖａＳｃｒｉｐｔエンジン１内で定期的に呼ばれる関数内に、ＪａｖａＳｃｒｉｐｔ側タイマ２１をチェックする処理が加えられている。ＪａｖａＳｃｒｉｐｔ側タイマ２１は、チェックされる度に消費CPU時間を加算して行き、累積消費CPU時間がタイムアウト時間（閾値）以上になったらApp側タイマ２２をスタートさせてカウントを開始させる。

App FW４の処理が終了した際、App側タイマ２２は消費時間を加算していく。Ｓ１４における処理の後、App側タイマ２２は、累積消費時間がタイムアウト時間（閾値）以上であるか否かの判断を行なう（Ｓ１５）。

Ｓ１５において、累積消費時間がタイムアウト時間（閾値）以上ではないと判断された場合、App側タイマ２２は短時間のsleepを行った後、再びApp FW４に一定時間処理時間を与え、App FW４の処理を実行させ（Ｓ１６）、Ｓ１５の処理に戻る。

一方、Ｓ１５において、累積消費時間がタイムアウト時間（閾値）以上であると判断された場合、Ｓ１２の処理に戻る。この場合、App側タイマ２２は、タイマをクリアし、再びＪａｖａＳｃｒｉｐｔ側タイマに処理を戻す。App側タイマ２２からＪａｖａＳｃｒｉｐｔ側タイマ２１に処理が戻ってきたら、ＪａｖａＳｃｒｉｐｔ側タイマ２１は、タイマをクリアし、ＪａｖａＳｃｒｉｐｔエンジン１に処理を戻すとともにカウントを開始する。

一方、Ｓ１３において、ＪａｖａＳｃｒｉｐｔ処理時間がタイムアウト時間を超えていないと判断された場合には、Ｓ１１において作成された命令を実行し（Ｓ１７）、未実行命令があるか否かの判断が行われる（Ｓ１８）。

Ｓ１８において、未実行命令があると判断された場合には、Ｓ１３の処理に移り、未実行命令がないと判断された場合には、ＪａｖａＳｃｒｉｐｔ処理を終了する。

タイマ制御モジュール２３は、ＪａｖａＳｃｒｉｐｔ側タイマ２１のタイムアウト時間（閾値）、App側タイマ２２のタイムアウト時間（閾値）、App側タイマ２２のスリープ時間を制御することが可能である。これにより、ＪａｖａＳｃｒｉｐｔエンジンとその他の処理に消費される時間を制御できる。タイマ制御モジュール２３は、情報処理端末のリソース状況（情報処理端末内の余剰CPUリソース量）を測定し、この測定されたリソース状況に基づいて、これらのパラメータ（タイムアウト時間、スリープ時間）を最適化し、ユーザ体感品質を向上させることができる。

測定するリソース状況としては、CPU情報（コア数、クロック、キャッシュ）、CPU使用率、ロードアベレージ、コンテキストスイッチ数などがある。例えば、コア数とCPU使用率、ロードアベレージからCPUリソース量を把握するようにしてもよい。パラメータの最適化手法としては、CPUリソースの余剰量が増えていればＪａｖａＳｃｒｉｐｔ側のタイマに与える時間を増やし、減っていれば App側のタイマに与える時間を増やすようにしてもよい。

なお、タイマ制御モジュール２３の最適化ロジックは、下記のポリシに基づいて決定しても良い。

画面更新間隔を例えば、16fpsとすると、約60ms毎に入力と出力が一通り終了すればユーザにとって動作の遅れは認識できない。即ち、ＪａｖａＳｃｒｉｐｔのタイムアウト実時間＋AppFW４のタイムアウト実時間の和が更新間隔以下になり、かつAppFW４の全ての処理が終了しているという条件が成り立つ。すると、最適な時間配分は、AppFW４終了までの実時間とＪａｖａＳｃｒｉｐｔエンジン１のタイムアウト時間の和が画面更新間隔以下ということが成り立つ。

しかし、AppFW４の処理量が多いばあいや他のプロセスによる処理量が多い場合は当てはまらないであろう。これらの場合は、AppFW４の処理を優先して行なう。実際には、AppFW４の処理量は推測することしかできないため、その処理時間から適応的な処理を行なうことになる。

即ち、予想よりAppFW４の処理が多ければ、次のＪａｖａＳｃｒｉｐｔ側タイマ２１のタイムアウト時間は短く、AppFW４の処理が少なければ反対にＪａｖａＳｃｒｉｐｔ側タイマ２１のタイムアウト時間を長く取れば良い。

従って、本実施の形態によれば、Ｗｅｂページを読込み、画面表示を行うブラウザにおいて、ＪａｖａＳｃｒｉｐｔ処理の動作を制御するＪａｖａＳｃｒｉｐｔ側タイマ２１とアプリケーションフレームワーク（App FW）４の処理の動作を制御するApp側タイマ２２とを設ける。

そして、ＪａｖａＳｃｒｉｐｔ処理の実行中には、ＪａｖａＳｃｒｉｐｔ側タイマ２１が、定期的にチェックされる度にＣＰＵ消費時間を加算し、ＣＰＵ消費時間の累積値が閾値以上になった時にApp側タイマ２２を起動するとともに、処理の実行をＪａｖａＳｃｒｉｐｔ処理からApp FW処理に移行させる。

App FW４の処理の実行中には、App側タイマ２２が、App FW４の処理が終了する度にＣＰＵ消費時間を加算し、ＣＰＵ消費時間の累積値が閾値以上になった時にＪａｖａＳｃｒｉｐｔ側タイマ２１を起動するとともに、処理の実行をApp FW４の処理からＪａｖａＳｃｒｉｐｔ処理に移行させる。これにより、ＪａｖａＳｃｒｉｐｔ処理が複雑なページを表示させる際のユーザ体感品質の低下を防ぐことができる。

なお、本発明の装置はコンピュータプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを介して提供することも可能である。また、本発明の実施形態を説明したが、実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１…ＪａｖａＳｃｒｉｐｔエンジン１ａ…チェックポイント２…レンダリングエンジン３…画面表示・ＵＩ部４…アプリケーションフレームワーク（App FW）１１…ＷＥＢサーバ２１…ＪａｖａＳｃｒｉｐｔ側タイマ２２…App側タイマ２３…タイマ制御モジュール。

Claims

ＪａｖａＳｃｒｉｐｔ処理の動作を監視するＪａｖａＳｃｒｉｐｔ側タイマと、
アプリケーションフレームワーク処理に時間を割り当てるためのアプリケーション側タイマとを具備し、
前記ＪａｖａＳｃｒｉｐｔ側タイマは、
前記ＪａｖａＳｃｒｉｐｔ処理の累積消費時間が閾値となる第１の累積消費時間を超えた場合に、前記アプリケーション側タイマを起動させる起動手段を具備し、
前記アプリケーション側タイマは、
前記ＪａｖａＳｃｒｉｐｔ側タイマにより起動されると、処理を前記アプリケーションフレームワーク処理に渡すとともに、前記アプリケーションフレームワーク処理の累積消費時間が閾値となる第２の累積消費時間を超えた場合に、処理を前記ＪａｖａＳｃｒｉｐｔ側タイマに渡すアプリケーション側切替手段を具備し、
前記ＪａｖａＳｃｒｉｐｔ側タイマは、さらに、
前記アプリケーション側切替手段により処理が渡された場合、前記渡された処理を前記ＪａｖａＳｃｒｉｐｔ処理に戻すＪａｖａＳｃｒｉｐｔ側切替手段を具備する、
情報処理装置。
前記ＪａｖａＳｃｒｉｐｔ側タイマは、
ＪａｖａＳｃｒｉｐｔを受け取り、実行するＪａｖａＳｃｒｉｐｔエンジンから前記ＪａｖａＳｃｒｉｐｔ側タイマがチェックされる毎に、前記ＪａｖａＳｃｒｉｐｔ処理の消費時間が加算される、請求項１記載の情報処理装置。
前記アプリケーション側切替手段により、前記ＪａｖａＳｃｒｉｐｔ側タイマによる前記ＪａｖａＳｃｒｉｐｔ処理の動作の監視に切り替えた場合、前記ＪａｖａＳｃｒｉｐｔ側タイマ及び前記アプリケーション側タイマをクリアする、請求項１記載の情報処理装置。
前記第１の累積消費時間及び前記第２の累積消費時間のうちの少なくとも１つは、前記情報処理装置のリソースに基づいて定められる、請求項１記載の情報処理装置。
前記ＪａｖａＳｃｒｉｐｔ側タイマ及び前記アプリケーション側タイマは、ブラウザに設けられている、請求項１記載の情報処理装置。
ＪａｖａＳｃｒｉｐｔ処理の動作を監視するＪａｖａＳｃｒｉｐｔ側タイマと、
アプリケーションフレームワーク処理に時間を割り当てるためのアプリケーション側タイマとを具備する情報処理装置のリソース制御方法において、
前記ＪａｖａＳｃｒｉｐｔ側タイマの具備する起動手段が、前記ＪａｖａＳｃｒｉｐｔ処理の累積消費時間が閾値となる第１の累積消費時間を超えた場合に、前記アプリケーション側タイマを起動させ、
前記アプリケーション側タイマの具備するアプリケーション側切替手段が、前記ＪａｖａＳｃｒｉｐｔ側タイマにより起動されると、処理を前記アプリケーションフレームワーク処理に渡すとともに、前記アプリケーションフレームワーク処理の累積消費時間が閾値となる第２の累積消費時間を超えた場合に、処理を前記ＪａｖａＳｃｒｉｐｔ側タイマに渡し、
前記ＪａｖａＳｃｒｉｐｔ側タイマの具備するＪａｖａＳｃｒｉｐｔ側切替手段が、さらに、前記アプリケーション側切替手段により処理が渡された場合、前記渡された処理を前記ＪａｖａＳｃｒｉｐｔ処理に戻す、
リソース制御方法。
前記ＪａｖａＳｃｒｉｐｔ側タイマは、
ＪａｖａＳｃｒｉｐｔを受け取り、実行するＪａｖａＳｃｒｉｐｔエンジンから前記ＪａｖａＳｃｒｉｐｔ側タイマがチェックされる毎に、前記ＪａｖａＳｃｒｉｐｔ処理の消費時間が加算される、請求項６記載のリソース制御方法。
コンピュータを、請求項１乃至請求項５いずれか１項に記載の情報処理装置が具備する前記ＪａｖａＳｃｒｉｐｔ側タイマ及び前記アプリケーション側タイマとして機能させるための、プログラム。