JP5889270B2 - スタック・スキャンのコストを削減するための方法、プログラム及びシステム - Google Patents

スタック・スキャンのコストを削減するための方法、プログラム及びシステム Download PDF

Info

Publication number
JP5889270B2
JP5889270B2 JP2013257970A JP2013257970A JP5889270B2 JP 5889270 B2 JP5889270 B2 JP 5889270B2 JP 2013257970 A JP2013257970 A JP 2013257970A JP 2013257970 A JP2013257970 A JP 2013257970A JP 5889270 B2 JP5889270 B2 JP 5889270B2
Authority
JP
Japan
Prior art keywords
stack
scan
address
start pointer
reference list
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2013257970A
Other languages
English (en)
Other versions
JP2015114957A (ja
Inventor
清久仁 河内谷
清久仁 河内谷
民也 小野寺
民也 小野寺
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to JP2013257970A priority Critical patent/JP5889270B2/ja
Priority to US14/567,526 priority patent/US11314640B2/en
Priority to US14/743,285 priority patent/US10423526B2/en
Publication of JP2015114957A publication Critical patent/JP2015114957A/ja
Application granted granted Critical
Publication of JP5889270B2 publication Critical patent/JP5889270B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free address space management
    • G06F12/0253Garbage collection, i.e. reclamation of unreferenced memory
    • G06F12/0261Garbage collection, i.e. reclamation of unreferenced memory using reference counting
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free address space management
    • G06F12/0253Garbage collection, i.e. reclamation of unreferenced memory
    • G06F12/0269Incremental or concurrent garbage collection, e.g. in real-time systems
    • G06F12/0276Generational garbage collection
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10Providing a specific technical effect
    • G06F2212/1016Performance improvement
    • G06F2212/1024Latency reduction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/70Details relating to dynamic memory management
    • G06F2212/702Conservative garbage collection

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System (AREA)
  • Executing Machine-Instructions (AREA)

Description

本発明は、コンピュータにおいてガベージ・コレクション(GC)におけるスタック・スキャンのコストを削減するための技術に関し、より詳細には、GCの結果を再利用することでGCにおけるスタック・スキャンのコストを削減するための技術に関する。
最近のJava(R)処理系では、GCのコストがJava(R)アプリケーションの性能に大きく影響することから、世代別GCを用いることでGCの停止時間を低減している。世代別GCではヒープ領域を、新しいオブジェクトを割り付けるための第1世代の(nursery)ヒープ領域と、第1世代のヒープ領域のGCを複数回生き残ったオブジェクトを移動させるための第2世代の(tenure)ヒープ領域に分割する。そして、通常は第1世代のヒープ領域のGCだけを行い、空き領域が確保できなくなった場合に限りヒープ領域全体のGCを行うことで、GCにかかる全体の時間の短縮を図っている。
上記第1世代のヒープ領域のGCは、当該領域に存在するオブジェクトの生死だけをチェックするため、高速に行うことができる。しかし、生きているオブジェクトを漏れなく確認するには、「GCルート(root)」と呼ばれる領域のスキャンは省略することができない。GCルートにはスタティック変数や各種のテーブル、第2世代のヒープ領域からの参照を示す「リメンバーセット」などがある。
さて、最近の大規模アプリケーションでは、スタックフレームの段数が深くなり、また、大量のスレッドが生成される傾向にある。これは、最近の大規模アプリケーションが、Java(R)上の各種フレームワーク(WAS,ICA,IOCなど)の上に構築されることが多くなり、また、Java(R) VMの上に別の言語処理系を実装する(JRuby,Jython,P8など)ことが一般的になっているためである。このため、大規模アプリケーションでは、スタック・スキャンにかかる時間が増大し、スタック・スキャンのコストが第1世代のヒープ領域のGCのオーバーヘッドの主要因となっている。
GCのコスト削減に関する従来技術として、特許文献1〜3が存在する。特許文献1は、アプリケーション・プログラムが生成するオブジェクトを、1つのスレッドと対応付けられたスレッドローカルヒープに生成し、上記生成されたオブジェクトを参照することができるスレッドが変化することに応じて、適切なスレッドグループヒープに移動させ、不要になったオブジェクトを回収する際に、上記不要になったオブジェクトを参照することができるスレッドのみを停止する技術を開示する。
また特許文献2は、アプリケーション・プログラムの起動時に実行時ライブラリを呼び出して、そのアプリケーション・プログラムの解析を行うことによりその生成される各オブジェクトが、メソッド内部でのみ利用されるオブジェクトであるか否かをそれぞれ判定し、メソッド内部でのみ利用されるオブジェクトはスタック領域のフレーム上に生成し、それ以外のオブジェクトはヒープ領域上に生成する技術を開示する。
また特許文献3は、ガベージコレクション実行手段と、ガベージコレクションを実行する毎にガベージコレクションの回数とガベージコレクションを実行した後のメモリ量を記録するガベージコレクション記録手段と、ガベージコレクション記録手段の記録に基づいて、ガベージコレクションの実行によりメモリの拡張を必要とする場合の拡張メモリ量を定めるメモリチャートを求める拡張メモリ量変換手段と、拡張メモリ量変換手段の求めた拡張メモリ量を保持する拡張メモリ量保持手段と、プログラムの実行においてメモリの拡張を必要とする場合に、拡張メモリ量保持手段を参照し、メモリ拡張チャートをもとに拡張メモリ量を決定するメモリ拡張手段とを備えるメモリ管理装置を開示する。
特許文献1〜3は、GCによる実行停止時間や回数を減らす技術を開示するが、いずれの技術も、GCにおけるスタック・スキャンにかかる時間を短縮することには適用できない。
一方、非特許文献1は、スタックが深いプログラムについてはスタック・スキャンのコストが高くなることから、変化のないスタック領域については繰り返しスキャンを行わずに以前のGCの結果を再利用する技術(セクション5. Generational Stack Collectionを参照。)を開示する。
しかしながら、非特許文献1の技術は、第1世代のヒープ領域にあるライブオブジェクトを次回のGC時に必ず第2世代のヒープ領域に移す初期の単純な世代別GCを対象としているため、一度スキャンしたスタック領域に、第1世代のヒープ領域に存在するオブジェクト(以下、「nurseryオブジェクト」ともいう)への参照が残っている状況を考慮することはない。そのため、非特許文献1の技術を、第1世代のヒープ領域のGCを複数回生き残ったオブジェクトを第2世代のヒープ領域に移す近代の世代別GCに対して、そのまま適用することはできない。
特開第2004−246753号公報 特開2004−78750号公報 特開平11−312117号公報
Perry Cheng, Robert Hrper,Peter Lee, "Generational Stack Collection andProfile-Driven Pretenuring",Proceedings of the ACM SIGPLAN 1998 conference on Programming language designand implementation, p.162-173, June 17-19, 1998, Montreal, Quebec, Canada
従って、本発明の目的は、近代的な世代別GCを含むGCにおけるスタック・スキャンにかかる時間の短縮を図ることのできる技術を提供することにある。
上記課題を解決するために、本発明の1態様によれば、以下のような、世代別GCをサポートするコンピュータ・システムの処理により、スタック・スキャンのコストを削減する方法が提供される。そのようなスタック・スキャンのコストを削減する方法は、スレッドごと、そのスタック内を指すスキャン不要領域開始ポインタを用意するステップと、第1世代の(nursery)ヒープ領域のGCにおいて、スタックの底から前記スキャン不要領域開始ポインタが指すアドレスまでの領域が、前記第1世代のヒープ領域に存在するnurseryオブジェクトへの参照が一つも存在しない領域となるように、各スレッドの前記スキャン不要領域開始ポインタに値を設定するステップと、次回の第1世代のヒープ領域のGCにおいて、各スレッドのスタックのスキャンを、前記スキャン不要領域開始ポインタが指すスタックフレームよりも上(言い換えると、前記スタックの先頭側)のスタックフレームに対してのみ実行するステップとを含む。
好ましくは、上記方法は、第1世代のヒープ領域のGCにおいて、前記nurseryオブジェクトを参照する又は参照しうる各スタック内の1以上のアドレスを、スレッドごとに用意するnurseryオブジェクト参照リストに登録するステップ、及び、前記スキャン不要領域開始ポインタを、前記nurseryオブジェクト参照リストにリストされたアドレスが前記スタックの底から前記スキャン不要領域開始ポインタが指すアドレスまでの領域内に含まれるように更新するステップを更に含み、次回の第1世代のヒープ領域のGCでは、前記スタックの底から前記スキャン不要領域開始ポインタが指すアドレスまでの領域については、前記nurseryオブジェクト参照リストに含まれるアドレスに対してGC処理を行うのみとする。
より好ましくは、上記方法は、前記次回の第1世代のヒープ領域のGCにおいて、各スレッドのスタックのスキャンを行う前に、前記nurseryオブジェクト参照リストに含まれる各アドレスについて、前記スキャン不要領域開始ポインタが指すスタックフレームよりも上(言い換えると、前記スタックの先頭側)のスタックフレームに含まれるか否かを判定し、前記より上のスタックフレームに含まれることを条件に、該アドレスを前記nurseryオブジェクト参照リストから削除するステップを更に含む。
前記nurseryオブジェクト参照リストにリストされるアドレスに対するGC処理は、各アドレスについて、該アドレスに格納される参照によりアクセスされるオブジェクトの移動に応答して、移動後の前記オブジェクトを正しく指すように前記アドレスに格納される参照を更新することを含む。
より好ましくは、前記nurseryオブジェクト参照リストにリストされるアドレスに対するGC処理は、前記nurseryオブジェクト参照リストに含まれる各アドレスについて、当該アドレスから参照されるオブジェクトが第2世代の(tenured)ヒープ領域に移動することを条件に、該アドレスを前記nurseryオブジェクト参照リストから削除するステップを含む。
また好ましくは、上記方法は、少なくとも一部のスタックフレームの破棄に応答して、前記スキャン不要領域開始ポインタが破棄される前記スタックフレームを指すか否かを判定し、破棄される前記スタックフレームを指すことを条件に、前記スタックフレームが破棄された後の新しいスタック・ポインタの値を前記スキャン不要領域開始ポインタに設定する調整処理を行うステップを更に含む。
より好ましくは、上記方法は、前記次回の第1世代のヒープ領域のGCにおいて、前処理として、前記スキャン不要領域開始ポインタを、前記調整処理を含むコードに対応する最初のスタックフレームまで下げるステップを更に含む。
また、より好ましくは、上記方法は、記スキャン不要領域開始ポインタの値の更新に応答して、更新後の前記値により指されるスタックフレームに格納されるメソッドのリターン先の情報を、前記メソッドのリターン先へ戻る前に前記調整処理が行われるように書き換えるステップを更に含む。
また好ましくは、上記方法は、前記スレッドごとのスタック内に配置されたオブジェクトが存在する場合に、該オブジェクト内の参照フィールドのアドレスを、対応する前記nurseryオブジェクト参照リストに追加するステップを更に含む。
また好ましくは、上記方法は、前記スキャン不要領域開始ポインタの上限を、先頭のスタックフレームから所定数のスタックフレーム分移動した位置のアドレスに設定し、設定された前記上限より上に積まれたデータのアドレスの前記nurseryオブジェクト参照リストへの登録を禁止するステップを更に含む。
本発明の他の態様によれば、以下のような、GCをサポートするコンピュータ・システムの処理により、スタック・スキャンのコストを削減する方法が提供される。そのようなスタック・スキャンのコストを削減する方法は、スレッドごと、その実行スタック内を指すスキャン不要領域開始ポインタと、オブジェクトを参照する又は参照しうるスタック内の1以上のアドレスを登録するオブジェクト参照リストとを用意するステップと、GCにおいて、オブジェクトを参照する又は参照しうるスタック内の1以上のアドレスを前記オブジェクト参照リストに登録し、かつ、前記スキャン不要領域開始ポインタを、スタックの底から前記スキャン不要領域開始ポインタが指すアドレスまでの領域内に前記オブジェクト参照リストにリストされたアドレスが含まれるように設定するステップとを含み、次回以降のGCにおいては、前記スタックの底から前記スキャン不要領域開始ポインタが指すアドレスまでの領域については、前記オブジェクト参照リストに含まれるアドレスに対してGC処理を行うのみとする。
以上、スタック・スキャンのコストを削減する方法として本発明を説明したが、本発明は、上記説明したスタック・スキャンのコストを削減する方法の各ステップをコンピュータに実行させるためのスタック・スキャンのコストを削減するためのプログラムとして把握することもできる。また、そのようなスタック・スキャンのコストを削減する方法の各ステップを実行するように適合された手段を備えるスタック・スキャンのコストを削減するためのコンピュータ・システムとして把握することもできる。
本発明によれば、スレッドごと、そのスタック内を指すスキャン不要領域開始ポインタが用意され、GCにおいて、スタックの底からスキャン不要領域開始ポインタが指すアドレスまでの領域が、ヒープ領域に存在するオブジェクトへの参照が一つも存在しえない領域となるように、各スレッドの上記スキャン不要領域開始ポインタに値が設定されるので、次回のヒープ領域のGCでは、各スレッドのスタックのスキャンを、スキャン不要領域開始ポインタが指すスタックフレームよりも上のスタックフレームに対してのみ実行すればよくなり、近代的な世代別GCを含むGCにおけるスタック・スキャンにかかる時間の短縮を図ることが可能となる。
更に、GCにおいて、オブジェクトを参照する又は参照しうる各スタック内の1以上のアドレスを、スレッドごとに用意するオブジェクト参照リストに登録し、かつ、スキャン不要領域開始ポインタを、オブジェクト参照リストにリストされたアドレスが、スタックの底からスキャン不要領域開始ポインタが指すアドレスまでの領域内に含まれるように更新することで、次回のヒープ領域のGCでは、スタックの底からスキャン不要領域開始ポインタが指すアドレスまでの領域については、オブジェクト参照リストに含まれるアドレスに対してGC処理を行うだけでよくなり、近代的な世代別GCを含むGCにおけるスタック・スキャンにかかる時間の更なる短縮を図ることが可能となる。本発明のその他の効果については、各実施の形態の記載から理解される。
本発明を実施するのに好適なコンピュータ・システムのハードウェア構成の一例を示した図である。 本発明を実施するためのソフトウェアの階層を示す図である。 スキャン不要開始ポインタが示す情報とnurseryオブジェクト参照リストに含まれる情報を説明する図である。 第1世代のヒープ領域のGC処理のフローチャートの一例を示す図である。 nurseryオブジェクト参照リストを用いたGC処理のフローチャートの一例を示す図である。 スタックフレームの破棄に応答して実行される処理のフローチャートの一例を示す図である。
以下、本発明を実施するための形態を図面に基づいて詳細に説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。なお、実施の形態の説明の全体を通じて同じ要素には同じ番号を付している。
図1を参照すると、本発明の一実施例に係るシステム構成及び処理を実現するためのコンピュータ・ハードウェアのブロック図が示されている。図1において、システム・バス102には、CPU104と、主記憶(RAM)106と、ハードディスク・ドライブ(HDD)108と、キーボード110と、マウス112と、ディスプレイ114が接続されている。CPU104は、好適には、32ビットまたは64ビットのアーキテクチャに基づくものであり、例えば、インテル社のCore(商標)i3、Core(商標) i5、Core(商標)i7、Xeon(R)、AMD社のAthlon(商標)、Phenom(商標)、Sempron(商標)などを使用することができる。主記憶106は、好適には、8GB以上の容量、より好ましくは、16GB以上の容量をもつものである。
ハードディスク・ドライブ108には、オペレーティング・システム(OS)202(図2)が、格納されている。オペレーティング・システムは、Linux(商標)、マイクロソフト社のWindows(商標) 7、Windows8(商標)、Windows(商標)2003サーバ、アップルコンピュータのMac OS(商標)などの、CPU104に適合する任意のものでよい。
ハードディスク・ドライブ108にはまた、Apacheなどの、Webサーバとしてシステムを動作させるためのプログラムが保存され、システムの起動時に、主記憶106にロードされる。
ハードディスク・ドライブ108にはさらに、Java(R)仮想マシン(JVM)204(図2)を実現するためのJava(R) Runtime Environmentプログラムが保存され、システムの起動時に、主記憶106にロードされる。JVM204には、本発明の機能が実装されている。
ハードディスク・ドライブ108にはさらに、アプリケーション・プログラムのバイトコード206(図2)が保存されている。
キーボード110及びマウス112は、オペレーティング・システムが提供するグラフィック・ユーザ・インターフェースに従い、ディスプレイ114に表示されたアイコン、タスクバー、テキストボックスなどのグラフィック・オブジェクトを操作するために使用される。
ディスプレイ114は、これには限定されないが、好適には、1024×768以上の解像度をもち、32ビットtrue
colorのLCDモニタである。ディスプレイ114は例えば、JVM上で実行されるアプリケーション・プログラムによる動作の結果を表示するために使用される。
通信インターフェース116は、好適には、イーサネット(R)プロトコルにより、ネットワークと接続されている。通信インターフェース116は、クライアント・コンピュータ(図示しない)からApacheが提供する機能により、TCP/IPなどの通信プロトコルに従い、処理リクエストを受け取り、あるいは処理結果を、クライアント・コンピュータ(図示しない)に返す。
図2を参照すると、本発明を実施するためのソフトウェアの階層が示されている。アプリケーション・プログラム206は、Java(R)バイトコードから構成され、JVM204上で動作する。JVM204は、本発明のスタック・スキャンのコストを削減するための機能をGCの機能の一部として備えた、カスタマイズされたJVMである。JVM204はまた、JITコンパイラを含んでよい。
JVM204は、アプリケーション・プログラム206のために、主記憶106上にヒープ領域を用意する。アプリケーション・プログラム208は、動作中にヒープ領域上にメモリ領域を獲得して、そこに、生成したオブジェクトを割り付ける。
JVM204は、好ましくは、世代別ヒープ領域をサポートする。世代別ヒープ領域は、新しいオブジェクトを割り付けるための、少なくとも1つの第1世代の(nursery)ヒープ領域と、少なくとも1つの第2世代の(tenured)ヒープ領域からなり、JVM204は、第1世代のヒープ領域にオブジェクトが割り当てられなくなったとき、第1世代のヒープ領域に対するGCを行い、第1世代のヒープ領域のGCを複数回生き残ったオブジェクトを第1世代のヒープ領域から、第2世代のヒープ領域に移動する。結果的に、第2世代のヒープ領域には、しばらく生き残っているオブジェクトが集まる。また、第2世代のヒープ領域が一杯になると、JVM204はヒープ領域全体のGCを行う。
JVM204は、非世代別ヒープ領域をサポートするものであってもよい。一方、非世代別ヒープ領域である場合、ヒープ領域は全て、第2世代のヒープ領域として扱われる。本発明は、世代別ヒープ領域と非世代別ヒープ領域の両方に適用可能である。以下では、JVM204は、世代別GCをサポートするものとして説明する。なお、非世代別GCをサポートするJVM204に対しては、ヒープ領域全体のGCに対して本発明を適用すればよく、世代別GCと非世代別GCとの間で適用の仕方に違いはない。
上述したように最近のJava(R)アプリケーションは、スレッドのスタックが深くなる傾向にある。しかしながら、スタックの下の方には各種フレームワークや言語処理系の初期化コードのフレームが積みあげられているため、実際の処理は専らスタックの上の方だけで行われ、下の方は全く変更されないことが多い。そこで本発明ではこの性質を利用して、スタックの変更されていない部分については前回のGCにおけるスキャン結果を利用し、スキャン処理のコストを下げる。なお、本明細書において、スタックのエントリは下から上(ボトムアップ)に格納するものとする。もちろん本発明は、スタックのエントリを上から下(トップダウン)に格納する場合や、エントリが複数のメモリ領域に分かれている場合にも適用可能である。
スキャン結果の再利用で重要になるのは、スタックの変更されていない部分に存在する、第1世代のヒープ領域に存在するnurseryオブジェクトへの参照の扱いである。近代の世代別GCでは、第1世代のヒープ領域に存在するオブジェクトはGCを複数回生き残った後第2世代のヒープ領域に移される。そのため、スキャンしたスタック領域にnurseryオブジェクトへの参照がある場合は、第2世代のヒープ領域へ移されるまでそのnurseryオブジェクトを監視する必要がある。
そこでJVM204は、管理するスレッドごとにスキャン不要領域開始ポインタと、nurseryオブジェクト参照リストとを新たに導入する。ここで、スレッドごとのスキャン不要領域開始ポインタは、そのスレッドに割り当てられたスタック内を指すものであり、第1世代のヒープ領域のGCにおいて従来のスタック・スキャンを必要としない領域を示すためのものである。また、スレッドごとのnurseryオブジェクト参照リストは、そのスレッドに割り当てられたスタックについて、nurseryオブジェクトへの参照を格納するアドレスをリストするものである。
JVM204は、第1世代のヒープ領域のGCにおいてスタック・スキャンを行う際に、スタックの底からスキャン不要領域開始ポインタが指すアドレスまでの領域が、nurseryオブジェクトへの参照が一つも存在しない領域となるように、各スレッドのスキャン不要領域開始ポインタに値を設定する。そして、JVM204は、次回の第1世代のヒープ領域のGCにおいて、各スレッドのスタックのスキャンを、スキャン不要領域開始ポインタが指すスタックフレームより上のスタックフレームに対してのみ実行する。
上記に代えて、又は、上記に加えて、JVM204は、第1世代のヒープ領域のGCにおいてスタック・スキャンを行う際に、nurseryオブジェクトを参照する又は参照しうるスタックのアドレスをnurseryオブジェクト参照リストに登録してもよい。また、JVM204は、スキャン不要領域開始ポインタを、nurseryオブジェクト参照リストにリストされたアドレスがスタックの底からスキャン不要領域開始ポインタが指すアドレスまでの領域内に含まれるように更新してよい。そして、JVM204は、次回の第1世代のヒープ領域のGCにおいて、スタックの底からスキャン不要領域開始ポインタが指すアドレスまでの領域については、スタック・スキャンを行うことなく、nurseryオブジェクト参照リストに含まれるアドレスに対してGC処理を行ってよい。
図3を参照すると、上記他の実施例におけるスキャン不要領域開始ポインタ316と、nurseryオブジェクト参照リスト318とが、スレッドのスタック300と共に示されている。スタックのエントリはボトムアップに格納されており、第1世代のヒープ領域のGC処理時のスタック・ポインタ314は、一番上のスタックフレームを指している。
nurseryオブジェクト参照リスト318には、前回の第1世代のヒープ領域のGCにおいて見つけられた、nurseryオブジェクトへの参照が格納されたスタック領域306、308それぞれのアドレスがリストされている。そして、スキャン不要領域開始ポインタ316には、nurseryオブジェクト参照リストにリストされたアドレスがスタックの底からスキャン不要領域開始ポインタが指すアドレスまでの領域内に含まれるように値が設定されている。より具体的には、そのようなスキャン不要領域開始ポインタ316の値として、前回のGC処理以降のスタック・ポインタの下限値(つまり、それより下のスタックフレームは変更されていない)が設定されている。
第1世代のヒープ領域のGC処理時には、JVM204は、スキャン不要領域開始ポインタが指すスタックフレームより上のスタックフレームの領域310に対してのみスタック・スキャンを実行する。スタックの底からスキャン不要領域開始ポインタ316が指すアドレスまでの領域312については、JVM204はスキャンを行わず、nurseryオブジェクト参照リストに含まれるアドレスに対してGC処理のみを行う。結果、近代的な世代別GCを含むGCにおけるスタック・スキャンにかかる時間の更なる短縮が図られる。
以下、新たに導入するスレッドごとのスキャン不要領域開始ポインタと、nurseryオブジェクト参照リストの管理方法及び利用方法について、当初よりnurseryオブジェクト参照リストを用いる例に従い詳細に説明する。
1. スレッド生成時の追加処理
1.1 スキャン不要領域開始ポインタには、該スレッドに割り当てられたスタックの底を設定する。
1.2 nurseryオブジェクト参照リストとして空のリストを生成する。
2. スレッド消滅時の追加処理
スキャン不要領域開始ポインタ及びnurseryオブジェクト参照リストを破棄する。
3. スタックフレーム作成時(メソッドの入り口)の追加処理
なし
4. スタックフレーム破棄時(メソッドの出口)の追加処理
スキャン不要領域開始ポインタが破棄されるスタックフレームを指すか否かを判定し、破棄されるスタックフレームを指すことを条件に、スキャン不要領域開始ポインタに新しいスタック・ポインタの値を設定する調整処理を行うように全てのメソッドの出口のコードを書き換える。スキャン不要領域開始ポインタが、破棄されるスタックフレームを指すか否かの判定に代えて、新しいスタック・ポインタが、スキャン不要領域開始ポインタよりも下である否かの判定を実行するようにしてもよい。そして新しいスタック・ポインタが、スキャン不要領域開始ポインタよりも下であることを条件に、スキャン不要領域開始ポインタに新しいスタック・ポインタの値を設定する調整処理を行うようにしてもよい。
5. 第1世代のヒープ領域のGCにおける処理
5.1 例えば、スタティック変数や各種のテーブル等、スタック以外のGCルートのスキャンは従来と同様に行う。
5.2 各スレッドのnurseryオブジェクト参照リストにリストされている各アドレスについて、以下の処理を行う。
5.2.1 各スレッドのスタックのスキャンを行う前に、各アドレスについて、該アドレスが、対応するスキャン不要領域開始ポインタが指すスタックフレームよりも上のスタックフレームに含まれるか否かを判定し、上記アドレスが、対応するスキャン不要領域開始ポインタが指すスタックフレームよりも上のスタックフレームに含まれることを条件に、上記アドレスをnurseryオブジェクト参照リストから削除する。なお、削除したアドレスのスタック領域は、変更されている可能性があるため、後で通常のスキャンを行う。
5.2.2各アドレスについて、該アドレスから参照されるオブジェクト、言い換えると、該アドレスに格納される参照によりアクセスされるオブジェクト、に対してGC処理を行う。オブジェクトは、第1世代のヒープ領域の新しい領域か、又は、第2世代のヒープ領域に移されるので、移動後のオブジェクトを正しく指すように上記アドレスに格納されている参照を更新する。なお、当該処理以前にオブジェクトが移動済みの場合は、参照の更新のみ行う。
5.2.3各スレッドのスタックのスキャンの後、対応するnurseryオブジェクト参照リストに含まれる各アドレスについて、該アドレスに格納される参照によりアクセスされるオブジェクトが第2世代のヒープ領域に移動するなどによって当該アドレスから上記nurseryオブジェクトを参照する可能性がなくなることを条件に、該アドレスをnurseryオブジェクト参照リストから削除する。
5.3 各スレッドのスキャン不要領域開始ポインタが指すスタックフレームより上のスタックフレームに対して、従来と同様にスキャンしGC処理を行う。この際、nurseryオブジェクトを参照する又は参照しうる各スタック内のアドレスを全て、対応するnurseryオブジェクト参照リストに登録する。なお、nurseryオブジェクトを参照しうるスタック内のアドレスの詳細については、7.の拡張Aで後述する。
5.4 各スレッドのスキャン不要領域開始ポインタを、対応するnurseryオブジェクト参照リストにリストされたアドレスがスタックの底からスキャン不要領域開始ポインタが指すアドレスまでの領域内に含まれるように更新する。
6. 第2世代のヒープ領域のGCにおける処理
従来通りの処理をする。
7. 拡張
上述した実施例に対し、様々な拡張が考えられる。
オブジェクトをスタック内に配置する場合、そのオブジェクト内の参照フィールドは、より上のスタックフレームを実行中でも書き換えられることがある。この問題は、スタック内に配置したオブジェクト内の参照フィールドのアドレスは常にnurseryオブジェクト参照リストに登録することで対応できる(拡張A)。なお、スタックフレーム内にどのような種類のデータが保持されるか、JVM204は、メソッドの情報から判断できる。そのため、スタック内に配置したオブジェクト内の参照フィールドのアドレスに限定されず、JVM204は、nurseryオブジェクトを現在参照していなくても書き換えにより将来参照する可能性の有る全てのスタック内のアドレスを、nurseryオブジェクト参照リストに登録してよい。
スタックの上の方のスタックフレームは頻繁に変更されると考えられる。そこで、スキャン不要領域開始ポインタに上限を設け、第1世代のヒープ領域のGCにおいて、スキャン不要領域開始ポインタの更新は、上限を超えない範囲で行うものとする(拡張B)。ここで、スキャン不要領域開始ポインタの上限には、先頭のスタックフレームから所定数のスタックフレーム分下に移動した位置を設定するのが好ましい。当然ながら、設定された上限より上に積まれたデータのアドレスがnurseryオブジェクト参照リストに含まれる場合、そのアドレスは削除する。若しくはそのようなデータのアドレスのnurseryオブジェクト参照リストへの追加を禁止する。これによりリストのサイズを小さくすることが可能となる。
4.で上述したように、スタックフレームが破棄される際、スキャン不要領域開始ポインタの値はチェックされ必要に応じて更新される。全てのメソッドの出口においてかかる処理を行うとなるとオーバーヘッドとなるため、一部のメソッドの出口でのみ4.で説明した調整処理を行うものとする。この場合、スキャン不要領域開始ポインタがスタック内の不適切な位置を指すことも起こりえる。そこで第1世代のヒープ領域のGCにおいて、前処理として、スキャン不要領域開始ポインタを、上述した調整処理のためのコードを含むメソッドに対応する最初のスタックフレームまで下げる(拡張C)。
上記処理に代えて、5.4で上述したスキャン不要領域開始ポインタの値の更新に応答して、更新後の値により指されるスタックフレームに格納されるメソッドのリターン先の情報を、メソッドのリターン先へ戻る前に4.で上述した調整処理が行われるように書き換えてもよい(拡張D)。すなわち、各スタックフレームのメソッドのリターンアドレスは、本来はその呼び出し元を指しているが、5.4で上述したスキャン不要領域開始ポインタを更新する(上げる)処理の際に、更新前の元の位置から更新後の新しい位置までの間にある各スタックフレームのメソッドのリターンアドレスを修正し、4.で説明した調整処理を行うようにする。この修正後のアドレスは、調整処理を行ってから本来のリターン先に飛ぶ処理を行うコードを指し、該コードは、JVM204が内部的にランタイムとして用意しておくことで実装してよい。なお、本来の呼び出し元を指すアドレスは、書き換え時にスタックフレームごとに用意した場所に格納して退避させる。かかる構成によれば、スキャン不要領域開始ポインタの値のチェックは必要最低限に抑えることが可能となる。
次に図4〜図6を参照して、本発明のスタック・スキャンのコストを削減するための処理の流れを説明する。図4は、第1世代のヒープ領域のGC処理のフローチャートの一例を示す図である。図5は、nurseryオブジェクト参照リストを用いたGC処理のフローチャートの一例を示す図である。図6は、スタックフレームの破棄に応答して実行される処理のフローチャートの一例を示す図である。
図4に示す第1世代のヒープ領域のGC処理は、ステップ400で開始し、JVM204は、スタックを除くGCルートのスキャンを行う。続いて、JVM204は、スキャン不要領域開始ポインタの修正処理を行う(ステップ402)。即ち、JVM204は、スキャン不要領域開始ポインタを、4.で説明した調整処理のためのコードを含むメソッドに対応する最初のスタックフレームまで下げる。但しステップ402の処理はオプションである。
続いてJVM204は、nurseryオブジェクト参照リストを用いてGC処理を行う(ステップ404)。ステップ404の処理の詳細は図5を参照して後述する。続いてJVM204は、スキャン不要領域開始ポインタが指すスタックフレームよりも上のスタックフレームのスキャンを実行する(ステップ406)。
続いてJVM204は、ステップ406におけるスキャンの結果、nurseryオブジェクトへの参照を格納するスタックのアドレスが見つかれば、これをnurseryオブジェクト参照リストに追加する(ステップ408)。JVM204はまた、スキャン不要領域開始ポインタを更新して、スタックの底からスキャン不要領域開始ポインタが指すアドレスまでの領域に、nurseryオブジェクト参照リストにリストされたアドレスが全て含まれるようにする(ステップ408)。
続いてJVM204は、スキャン不要領域開始ポインタの値を更新したことに応答して、更新後のスキャン不要領域開始ポインタが指すスタックフレームに対応するメソッドについて、そのリターン位置において4.で上述した調整処理が行われるように、コード、より詳細には、上記スタックフレームに格納されたメソッドのリターン先の情報を書き換える(ステップ410)。更なる詳細は、拡張Dの説明の繰り返しになるため省略する。なお、ステップ410の処理はオプションである。そして処理は終了する。
図5に示すnurseryオブジェクト参照リストを用いたGC処理は、ステップ500で開始し、JVM204は、nurseryオブジェクト参照リストをチェックし、スキャン不要領域開始ポインタが指すスタックフレームよりも上のスタックフレームに含まれるアドレスを削除する。
続いてJVM204は、nurseryオブジェクト参照リストから順にアドレスを読み出し、該アドレスのスタック領域に格納される参照によってアクセスされるnurseryオブジェクトについてGC処理を行う(ステップ502)。
続いてJVM204は、nurseryオブジェクト参照リストに含まれる各アドレスについて、該アドレスから参照されるnurseryオブジェクトがステップ502の処理の結果、第2世代のヒープ領域に移動するなどによって当該アドレスから前記nurseryオブジェクトを参照する可能性がなくなることを条件に、該アドレスをnurseryオブジェクト参照リストから削除する(ステップ504)。そして処理は終了する。
図6に示す処理は、スタックフレームの破棄に応答して実行され、ステップ600において、JVM204は、スキャン不要領域開始ポインタが破棄されるスタックフレームを指すか否かを判定する。スキャン不要領域開始ポインタが破棄されるスタックフレームを指す場合(ステップ600:YES)、続いて、JVM204は、スキャン不要領域開始ポインタに、スタックフレーム破棄後の新しいスタック・ポインタの値を設定する(ステップ602)。ステップ600において、スキャン不要領域開始ポインタが破棄されるスタックフレームを指さない場合(ステップ600:NO)、又は、ステップ602の後処理は終了する。
以上、実施形態を用いて本発明の説明をしたが、本発明の技術範囲は上記実施形態に記載の範囲には限定されない。上記の実施形態に、種々の変更または改良を加えることが可能であることが当業者に明らかである。従って、そのような変更または改良を加えた形態も当然に本発明の技術的範囲に含まれる。
なお、特許請求の範囲、明細書、及び図面中において示した装置、システム、プログラム、及び方法における動作、手順、ステップ、及び段階等の各処理の実行順序は、特段「より前に」、「先立って」等と明示しておらず、また、前の処理の出力を後の処理で用いるのでない限り任意の順序で実現しうることに留意すべきである。また、前の処理の出力を後の処理で用いる場合でも、前の処理と後の処理の間に他の処理が入ることは可能である場合があること、又は間に他の処理が入るように記載されていても前の処理を後の処理の直前に行うよう変更することも可能である場合があることも留意されたい。特許請求の範囲、明細書、及び図面中の動作フローに関して、便宜上「まず、」、「次に、」、「続いて、」等を用いて説明したとしても、この順で実施することが必須であることを必ずしも意味するとは限らない。

Claims (13)

  1. 世代別ガベージ・コレクション(GC)をサポートするコンピュータ・システムの処理により、スタック・スキャンのコストを削減する方法であって、
    スレッドごと、そのスタック内を指すスキャン不要領域開始ポインタを用意するステップと、
    第1世代の(nursery)ヒープ領域のGCにおいて、スタックの底から前記スキャン不要領域開始ポインタが指すアドレスまでの領域が、前記第1世代のヒープ領域に存在するnurseryオブジェクトへの参照が一つも存在しない領域となるように、各スレッドの前記スキャン不要領域開始ポインタに値を設定するステップと、
    次回の第1世代のヒープ領域のGCにおいて、各スレッドのスタックのスキャンを、前記スキャン不要領域開始ポインタが指すスタックフレームより上のスタックフレームに対してのみ実行するステップと
    を含む、スタック・スキャンのコストを削減する方法。
  2. 第1世代のヒープ領域のGCにおいて、前記nurseryオブジェクトを参照する又は参照しうる各スタック内の1以上のアドレスを、スレッドごとに用意するnurseryオブジェクト参照リストに登録するステップ、及び、前記スキャン不要領域開始ポインタを、前記nurseryオブジェクト参照リストにリストされたアドレスが前記スタックの底から前記スキャン不要領域開始ポインタが指すアドレスまでの領域内に含まれるように更新するステップを更に含み、次回の第1世代のヒープ領域のGCでは、前記スタックの底から前記スキャン不要領域開始ポインタが指すアドレスまでの領域については、前記nurseryオブジェクト参照リストに含まれるアドレスに対してGC処理を行うのみとする、請求項1に記載のスタック・スキャンのコストを削減する方法。
  3. 少なくとも一部のスタックフレームの破棄に応答して、前記スキャン不要領域開始ポインタが破棄される前記スタックフレームを指すか否かを判定し、破棄される前記スタックフレームを指すことを条件に、前記スキャン不要領域開始ポインタに新しいスタック・ポインタの値を設定する調整処理を行うステップを更に含む、請求項2に記載のスタック・スキャンのコストを削減する方法。
  4. 前記スキャン不要領域開始ポインタの値の更新に応答して、更新後の前記値により指されるスタックフレームに格納されるメソッドのリターン先の情報を、前記メソッドのリターン先へ戻る前に前記調整処理が行われるように書き換えるステップを更に含む、請求項3に記載のスタック・スキャンのコストを削減する方法。
  5. 前記次回の第1世代のヒープ領域のGCにおいて、前処理として、前記スキャン不要領域開始ポインタを、前記調整処理のためのコードを含むメソッドに対応する最初のスタックフレームまで下げるステップを更に含む、請求項3に記載のスタック・スキャンのコストを削減する方法。
  6. 前記次回の第1世代のヒープ領域のGCにおいて、各スレッドのスタックのスキャンを行う前に、前記nurseryオブジェクト参照リストに含まれる各アドレスについて、前記スキャン不要領域開始ポインタが指すスタックフレームよりも上のスタックフレームに含まれるか否かを判定し、前記上のスタックフレームに含まれることを条件に、該アドレスを前記nurseryオブジェクト参照リストから削除するステップを更に含む、請求項3に記載のスタック・スキャンのコストを削減する方法。
  7. 前記nurseryオブジェクト参照リストにリストされるアドレスに対するGC処理は、各アドレスについて、該アドレスに格納される参照によりアクセスされるオブジェクトの移動に応答して、移動後の前記オブジェクトを正しく指すように前記アドレスに格納される参照を更新することを含む、請求項3に記載のスタック・スキャンのコストを削減する方法。
  8. 前記nurseryオブジェクト参照リストにリストされるアドレスに対するGC処理は、前記nurseryオブジェクト参照リストに含まれる各アドレスについて、 該アドレスから参照されるオブジェクトが第2世代の(tenured)ヒープ領域に移動することを条件に、該アドレスを前記nurseryオブジェクト参照リストから削除するステップを含む、請求項3に記載のスタック・スキャンのコストを削減する方法。
  9. 前記スレッドごとのスタック内に配置されたオブジェクトが存在する場合に、該オブジェクト内の参照フィールドのアドレスを、対応する前記nurseryオブジェクト参照リストに追加するステップを更に含む、請求項3に記載のスタック・スキャンのコストを削減する方法。
  10. 前記スキャン不要領域開始ポインタの上限を、先頭のスタックフレームから所定数のスタックフレーム分移動した位置のアドレスに設定し、設定された前記上限より上に積まれたデータのアドレスの前記nurseryオブジェクト参照リストへの登録を禁止するステップを更に含む、請求項3に記載のスタック・スキャンのコストを削減する方法。
  11. ガベージ・コレクション(GC)をサポートするコンピュータ・システムの処理により、スタック・スキャンのコストを削減する方法であって、
    スレッドごと、その実行スタック内を指すスキャン不要領域開始ポインタと、オブジェクトを参照する又は参照しうるスタック内の1以上のアドレスを登録するオブジェクト参照リストとを用意するステップと、
    GCにおいて、オブジェクトを参照する又は参照しうるスタック内の1以上のアドレスを前記オブジェクト参照リストに登録し、かつ、前記スキャン不要領域開始ポインタを、スタックの底から前記スキャン不要領域開始ポインタが指すアドレスまでの領域内に前記オブジェクト参照リストにリストされたアドレスが含まれるように設定するステップと、
    次回以降のGCにおいて、前記スタックの底から前記スキャン不要領域開始ポインタが指すアドレスまでの領域については、前記オブジェクト参照リストに含まれるアドレスに対してGC処理を行うのみとする、スタック・スキャンのコストを削減する方法。
  12. コンピュータに、請求項1乃至11のいずれか1項に記載のスタック・スキャンのコストを削減する方法の各ステップを実行させるためのスタック・スキャンのコストを削減するためのプログラム。
  13. 請求項1乃至11のいずれか1項に記載のスタック・スキャンのコストを削減す方法の各ステップを実行するように適合された手段を備える、スタック・スキャンのコストを削減するためのコンピュータ・システム。
JP2013257970A 2013-12-13 2013-12-13 スタック・スキャンのコストを削減するための方法、プログラム及びシステム Expired - Fee Related JP5889270B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2013257970A JP5889270B2 (ja) 2013-12-13 2013-12-13 スタック・スキャンのコストを削減するための方法、プログラム及びシステム
US14/567,526 US11314640B2 (en) 2013-12-13 2014-12-11 Method, program, and system for reducing the cost of stack scanning
US14/743,285 US10423526B2 (en) 2013-12-13 2015-06-18 Method, program, and system for reducing the cost of stack scanning

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013257970A JP5889270B2 (ja) 2013-12-13 2013-12-13 スタック・スキャンのコストを削減するための方法、プログラム及びシステム

Publications (2)

Publication Number Publication Date
JP2015114957A JP2015114957A (ja) 2015-06-22
JP5889270B2 true JP5889270B2 (ja) 2016-03-22

Family

ID=53368596

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013257970A Expired - Fee Related JP5889270B2 (ja) 2013-12-13 2013-12-13 スタック・スキャンのコストを削減するための方法、プログラム及びシステム

Country Status (2)

Country Link
US (2) US11314640B2 (ja)
JP (1) JP5889270B2 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10459656B1 (en) * 2018-06-25 2019-10-29 International Business Machines Corporation Method and apparatus to represent activation frame for pause-less garbage collection
US11416392B2 (en) * 2019-06-20 2022-08-16 Microsoft Technology Licensing, Llc Arena-based memory management
US11068393B2 (en) * 2019-10-17 2021-07-20 Microsoft Technology Licensing, Llc Enhanced concurrency garbage collection stack scanning

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3795669B2 (ja) 1998-04-28 2006-07-12 富士通株式会社 メモリ管理装置およびメモリ管理プログラムを記憶した記憶媒体
US6763440B1 (en) * 2000-06-02 2004-07-13 Sun Microsystems, Inc. Garbage collection using nursery regions for new objects in a virtual heap
US6865657B1 (en) * 2000-06-02 2005-03-08 Sun Microsystems, Inc. Garbage collector for a virtual heap
US6912554B2 (en) * 2001-11-14 2005-06-28 Omron Corporation Method and apparatus for garbage collection using advanced marking techniques and restricted barrier to protect the data
JP2004078750A (ja) 2002-08-21 2004-03-11 Nippon Telegr & Teleph Corp <Ntt> オブジェクト管理装置および方法とプログラム
JP2004246753A (ja) 2003-02-17 2004-09-02 Nippon Telegr & Teleph Corp <Ntt> メモリ管理装置およびプログラム
GB2399897B (en) 2003-03-26 2006-02-01 Advanced Risc Mach Ltd Memory recycling in computer systems
US7730016B2 (en) * 2005-01-31 2010-06-01 Oracle International Corporation Identification of false ambiguous roots in a stack conservative garbage collector
US20070100919A1 (en) * 2005-11-01 2007-05-03 Electronics And Telecommunications Research Institute Garbage collection unit and method thereof
US8024505B2 (en) * 2006-05-11 2011-09-20 Oracle International Corporation System and method for optimistic creation of thread local objects in a virtual machine environment
US8868623B2 (en) * 2007-10-30 2014-10-21 International Business Machines Corporation Enhanced garbage collection in a multi-node environment
US20090119352A1 (en) * 2007-11-05 2009-05-07 Steven Joseph Branda Method for Optimizing Generational Garbage Collection Through Object Life Heuristics
JP2010015223A (ja) * 2008-07-01 2010-01-21 Internatl Business Mach Corp <Ibm> メモリ領域中のオブジェクトを隔離するための方法
US8825719B2 (en) * 2008-10-30 2014-09-02 Microsoft Corporation Incremental lock-free stack scanning for garbage collection
JP5380695B2 (ja) * 2010-02-23 2014-01-08 株式会社日立製作所 メモリ管理方法、計算機システム及びメモリ管理プログラム
JP5509164B2 (ja) * 2011-08-18 2014-06-04 株式会社日立製作所 計算機、管理方法及びプログラム
JP5719278B2 (ja) 2011-11-11 2015-05-13 インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation 情報処理装置、プロファイル対象決定プログラム及び方法
US8694562B2 (en) * 2012-05-22 2014-04-08 Microsoft Corporation Generational garbage collection for a pool-based heap
US9292359B2 (en) * 2012-07-27 2016-03-22 Intel Corporation System and method for memory management

Also Published As

Publication number Publication date
US10423526B2 (en) 2019-09-24
US20150286566A1 (en) 2015-10-08
JP2015114957A (ja) 2015-06-22
US20150169444A1 (en) 2015-06-18
US11314640B2 (en) 2022-04-26

Similar Documents

Publication Publication Date Title
US9870317B2 (en) Incremental class unloading in a region-based garbage collector
US8024505B2 (en) System and method for optimistic creation of thread local objects in a virtual machine environment
JP4917138B2 (ja) オブジェクト最適配置装置、オブジェクト最適配置方法、及びオブジェクト最適配置プログラム
CN110325969B (zh) 多阶段垃圾收集器
US9740716B2 (en) System and method for dynamically selecting a garbage collection algorithm based on the contents of heap regions
US8769230B2 (en) Parallel, single-pass compaction in a region-based garbage collector
US20100011357A1 (en) System and method for garbage collection in a virtual machine
US7627621B2 (en) Method and system for minor garbage collection
CN110291508B (zh) 垃圾收集器
US20160328319A1 (en) Managing memory in a computer system
JP5889270B2 (ja) スタック・スキャンのコストを削減するための方法、プログラム及びシステム
US8447793B2 (en) Efficient remembered set for region-based garbage collectors
JP5588072B2 (ja) メモリ割り当て方法、プログラム、及びシステム
US8838874B2 (en) Method, program, and system for processing object in computer
US7756912B2 (en) Method and system for minor garbage collection in a multitasking environment
US7404061B2 (en) Permanent pool memory management method and system
US10922107B2 (en) Apparatus and method for realizing runtime system for programming language
JP2011100230A (ja) メモリ管理機能を有するプログラム及び装置
JP6173031B2 (ja) コンピュータにおいてオブジェクトを管理するための方法、プログラム及びシステム
US20120131069A1 (en) Object consolidation to a grid of a virtual machine
JP6223002B2 (ja) コンピュータにおけるオブジェクトの処理方法、プログラム及びシステム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20151127

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20160104

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20160119

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160126

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160216

R150 Certificate of patent or registration of utility model

Ref document number: 5889270

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees