JP2014225077A - Method for managing object in computer, and program and system - Google Patents
Method for managing object in computer, and program and system Download PDFInfo
- Publication number
- JP2014225077A JP2014225077A JP2013103042A JP2013103042A JP2014225077A JP 2014225077 A JP2014225077 A JP 2014225077A JP 2013103042 A JP2013103042 A JP 2013103042A JP 2013103042 A JP2013103042 A JP 2013103042A JP 2014225077 A JP2014225077 A JP 2014225077A
- Authority
- JP
- Japan
- Prior art keywords
- collection
- collection object
- program
- jvm
- utilization rate
- 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.)
- Granted
Links
Images
Abstract
Description
この発明は、コンピュータにおいてオブジェクトを管理するための技法に関し、より詳しくは、必要に応じてオブジェクトのサイズを縮小するための技法に関する。 The present invention relates to a technique for managing objects in a computer, and more particularly to a technique for reducing the size of an object as needed.
従来より、Java(R)などの処理環境において、ハッシュ表や集合型、コレクション・オブジェクトなどの抽象データ型が標準ＡＰＩに含まれており、これらを用いると、実行時でないと総量が分からないデータも簡単に扱うことができる。 Conventionally, in a processing environment such as Java (R), abstract data types such as hash tables, set types, and collection objects are included in the standard API, and when these are used, the total amount cannot be known unless it is run time. Can also be handled easily.
これらのＡＰＩの実装では、内部で配列を使う場合がある。例えば、一般的なハッシュ表の実装法の１つに、オープン・ハッシュ表がある。この実装では、ハッシュ表はバケット(bucket)配列（もしくはバケット表）と呼ばれる配列と、バケット配列の各要素から指されるリンクリストで構成される。キーとして与えられた値から適当なハッシュ関数を用いてバケット表のインデックスを計算し、対応する要素に繋がっているリンクリストに、キーと値のペアを格納する。 Some implementations of these APIs may use arrays internally. For example, one common hash table implementation is an open hash table. In this implementation, the hash table is composed of an array called a bucket array (or bucket table) and a linked list pointed to by each element of the bucket array. The index of the bucket table is calculated from the value given as the key using an appropriate hash function, and the key / value pair is stored in the linked list linked to the corresponding element.
バケット配列のサイズはライブラリが適当に決めれば良いのであるが、ハッシュ表に含まれる要素数に対して小さすぎるとリンクリストが長くなって実行速度が低下する恐れがある。逆に、大きすぎると、リンクリストが繋がっていない要素が多くなって、メモリが無駄になる。なお、バケット配列については、Alfred V. Aho, Jeffrey D. Ullman, John E. Hopcroft, "Data Structures and Algorithms" (Addison-Wesley Series in Computer Science and Information Pr), 1983などの文献を参照されたい。 The size of the bucket array may be determined appropriately by the library, but if it is too small for the number of elements included in the hash table, the linked list may become long and the execution speed may be reduced. On the other hand, if it is too large, there will be many elements that are not linked to the linked list, and the memory will be wasted. For the bucket arrangement, refer to documents such as Alfred V. Aho, Jeffrey D. Ullman, John E. Hopcroft, “Data Structures and Algorithms” (Addison-Wesley Series in Computer Science and Information Pr), 1983.
そのような内部配列を使用する場合、適当な初期サイズの配列を用意しておき、データが増えて配列が一杯になったら、より大きな配列を作成してデータをコピーする実装が一般的である。しかし、挿入されるデータ数によっては、配列が無駄に大きい場合がある。データが挿入されなかったり、１〜３個程度のデータしか挿入されなかった場合は、初期サイズの配列でも大きすぎてメモリが無駄になる。また、配列を大きく拡張したあとで挿入されたデータが少ないために、利用率が１／３以下にとどまるものも少なくない。 When using such an internal array, it is common to prepare an array of an appropriate initial size and create a larger array and copy the data when the data increases and the array becomes full . However, the array may be uselessly large depending on the number of data to be inserted. If no data is inserted or only about 1 to 3 pieces of data are inserted, the initial size array is too large and the memory is wasted. In addition, since there is little data inserted after the array is greatly expanded, there are many cases where the utilization rate remains below 1/3.
従来技術として、特開２００９−６４２１７号公報は、重複した文字列データをＧＣ時に一つにまとめる、ストリングＧＣ技法を開示するものであるが、コレクション・オブジェクトを個別に縮小することには適用できない。 As a conventional technique, Japanese Patent Application Laid-Open No. 2009-64217 discloses a string GC technique that combines duplicate character string data into one at the time of GC, but is not applicable to individually reducing collection objects. .
http://www.gnu.org/software/guile/manual/html_node/Hash-Table-Reference.htmlには、コレクション・オブジェクトにデータの挿入および削除する時に、必要に応じて内部データ構造を拡大および縮小する処理は、既存のプログラムでも実装されている。しかし、起動時に設定ファイルなどを読み込んで、その内容をハッシュ表などに保持し、その後は参照のみ行う場合、データ削除時に縮小する方法は効果がない。 http://www.gnu.org/software/guile/manual/html_node/Hash-Table-Reference.html expands and expands internal data structures as needed when inserting and deleting data in collection objects The reduction process is also implemented in existing programs. However, if a setting file is read at startup, the contents are stored in a hash table, etc., and thereafter only the reference is performed, the method of reducing when deleting data is not effective.
http://blog.gmane.org/gmane.lisp.scheme.mit-scheme.devel/month=20110901にある、Scheme開発者のメーリングリストでは、ＧＣ時にハッシュ表をリハッシュ(rehash)してバケット配列を縮小することが議論されているが、そこにあるのは、ＧＣ中にハッシュ表オブジェクトのリハッシュ関数を呼ぶ事の是非についての議論だけである。ＧＣがハッシュ表オブジェクトの内容を直接書き換えることで、効率的に実装できることについては言及されていない。また、ハッシュ表以外のデータ構造（JavaのArrayListなど）についての議論はない。 The Scheme developer's mailing list at http://blog.gmane.org/gmane.lisp.scheme.mit-scheme.devel/month=20110901 reshashes the hash table during GC to reduce the bucket array. However, there is only a discussion about the right or wrong of calling the rehash function of the hash table object in the GC. There is no mention that the GC can be efficiently implemented by directly rewriting the contents of the hash table object. There is no discussion on data structures other than hash tables (Java ArrayList, etc.).
http://msdn.microsoft.com/ja-jp/library/system.collections.arraylist%28v=vs.80%29.aspxなどに記述がある、.Net FrameworkのArrayListクラスは、内部データ構造のキャパシティを指定するTrimToSizeメソッドを持つ。しかし、HashTableクラスにはキャパシティを指定するAPIを持たない。そして、実行時システムに組み込まないと、無駄なメモリ使用を削減できるかどうかがAPI仕様に依存する。 As described in http://msdn.microsoft.com/en-us/library/system.collections.arraylist%28v=vs.80%29.aspx, etc., the .Net Framework's ArrayList class is a capacity for internal data structures. Has a TrimToSize method that specifies the city. However, the HashTable class does not have an API for specifying capacity. And if it is not incorporated into the runtime system, it depends on the API specifications whether or not useless memory usage can be reduced.
従って、この発明の目的は、既存のアプリケーションを変更することなく、オブジェクト・サイズの無駄を自動的に削減できるシステムを提供することにある。 Accordingly, an object of the present invention is to provide a system that can automatically reduce waste of object size without changing an existing application.
この発明は、上記課題を解決するものであって、初期化によるデータ挿入が終わっても利用率の低いコレクション・オブジェクトを、プログラム言語実行環境が自動的にキャパシティを縮小するシステムを実現する。ここでの好適なプログラム言語実行環境は、ＪＶＭである。 The present invention solves the above-described problem, and realizes a system in which a program language execution environment automatically reduces the capacity of a collection object having a low utilization rate even after data insertion by initialization is completed. The preferred programming language execution environment here is JVM.
すなわち、この発明のシステムは、初期化が終わり更新が少なくなると予想できるコレクション・オブジェクトを定期的に抽出し、内部データ構造の利用率を調べ、利用率が低い場合は、実行時システムが内部データ構造のキャパシティを自動的に縮小する。このとき、自動的に縮小することで、アプリケーション開発者の技量に依存せずに無駄なメモリ使用を削減できる。 In other words, the system of the present invention periodically extracts collection objects that can be expected to be updated when the initialization is completed, and examines the utilization rate of the internal data structure. Automatically reduce structure capacity. At this time, by automatically reducing the size, useless memory usage can be reduced without depending on the skill of the application developer.
たとえば、クラウド環境では、一つのアプリケーションが無駄にメモリを使用すると、他の仮想マシン上で動くアプリケーションも含め、同じ物理マシン上で実行される全てのアプリケーションの使用可能な物理メモリ量が減少し、マシンの利用効率が低下する。よって、自動的に縮小する処理は効果が大きい。 For example, in a cloud environment, if one application uses memory in vain, the amount of physical memory available to all applications running on the same physical machine, including applications that run on other virtual machines, decreases. Machine use efficiency decreases. Therefore, the automatic reduction process has a great effect.
また、キャパシティの自動縮小後にデータが追加されて内部配列が拡張されると、自動縮小処理は不要なオーバーヘッドとなってしまう。このようなことが発生する可能性を低減するために、初期化が終わり更新が少なくなると予想されるコレクションだけを自動縮小する。 In addition, if data is added after the capacity is automatically reduced and the internal array is expanded, the automatic reduction process becomes unnecessary overhead. To reduce the likelihood of this happening, only the collections that are expected to finish and are expected to have fewer updates are automatically reduced.
好適には、（クラスライブラリを含む）実行時システムが実装を知っているコレクションオブジェクトをキャパシティ自動縮小の対象とし、縮小処理を実行時システムに組み込むことで、クラスライブラリのAPI仕様に依存せず、効率のよい実装を可能にする。 Preferably, the collection object (including the class library) whose implementation is known by the runtime system is subject to automatic capacity reduction, and the reduction processing is incorporated into the runtime system so that it does not depend on the API specification of the class library. , Enabling efficient implementation.
初期化が終わり更新が少なくなると予想できるかどうかの判断は、たとえば以下の方法を用いる。
− プログラム言語実行環境、例えばＪＶＭが世代別ＧＣを用いている場合、コレクション・オブジェクトがtenured領域に移動された場合。
− Mark and sweep GCを用いている場合、コンパクション(compaction)を2回以上生き延びたオブジェクトの場合。
− あるコレクション・オブジェクトに対し、get()メソッドなど、データの挿入・削除以外の操作が一定回数以上実行された場合。
− コレクションに含まれるデータ数の変動幅が、一定期間充分小さく（たとえば10％以内）なった場合。
− 好適には、自動縮小対象を、まだ一度も自動縮小していないコレクション・オブジェクトに限定する。
For example, the following method is used to determine whether or not the initialization is completed and it can be expected that the number of updates will decrease.
-When the programming language execution environment, for example, JVM uses generational GC, the collection object is moved to the tenured area.
− When using Mark and sweep GC, if the object has survived compaction more than once.
− When an operation other than data insertion / deletion, such as the get () method, is executed more than a certain number of times on a collection object.
-The fluctuation range of the number of data included in the collection is sufficiently small (for example, within 10%) for a certain period.
-Preferably, auto-reduction targets are limited to collection objects that have not been auto-reduced yet.
この発明の別の側面によれば、縮小処理をＧＣ時に行うことで、効率よく実装する。すなわち、ＧＣによるオブジェクト移動処理では元々オブジェクト参照を修正が必要なので、キャパシティ縮小も同時に行えば、縮小後のキャパシティにあわせてデータの再配置するためにオブジェクト参照を修正する処理が、追加オーバーヘッドなしで実現できる。 According to another aspect of the present invention, mounting is efficiently performed by performing the reduction process at the time of GC. That is, since the object reference processing is originally required to be corrected in the object movement processing by GC, if the capacity reduction is performed at the same time, the processing for correcting the object reference in order to rearrange the data according to the capacity after the reduction requires additional overhead. Can be realized without.
この発明によれば、ほとんど追加コストなく、オブジェクト・サイズの無駄を自動的に削減できるシステムが提供される。このようなシステムは特に、クラウド環境でメモリ利用効率を向上させる効果が大きい。 The present invention provides a system that can automatically reduce waste of object size with little additional cost. Such a system is particularly effective in improving memory utilization efficiency in a cloud environment.
以下、図面に従って、本発明の実施例を説明する。これらの実施例は、本発明の好適な態様を説明するためのものであり、発明の範囲をここで示すものに限定する意図はないことを理解されたい。また、以下の図を通して、特に断わらない限り、同一符号は、同一の対象を指すものとする。 Embodiments of the present invention will be described below with reference to the drawings. It should be understood that these examples are for the purpose of illustrating preferred embodiments of the invention and are not intended to limit the scope of the invention to what is shown here. Further, throughout the following drawings, the same reference numerals denote the same objects unless otherwise specified.
図１を参照すると、本発明の一実施例に係るシステム構成及び処理を実現するためのコンピュータ・ハードウェアのブロック図が示されている。図１において、システム・バス１０２には、ＣＰＵ１０４と、主記憶（ＲＡＭ）１０６と、ハードディスク・ドライブ（ＨＤＤ）１０８と、キーボード１１０と、マウス１１２と、ディスプレイ１１４が接続されている。ＣＰＵ１０４は、好適には、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のCore(商標) i3、Core(商標) i5、Core(商標) i7、Xeon(R)、AMD社のAthlon(商標)、Phenom(商標)、Sempron(商標)などを使用することができる。主記憶１０６は、好適には、８ＧＢ以上の容量、より好ましくは、１６ＧＢ以上の容量をもつものである。
Referring to FIG. 1, there is shown a block diagram of computer hardware for realizing a system configuration and processing according to an embodiment of the present invention. In FIG. 1, a
ハードディスク・ドライブ１０８には、オペレーティング・システム（ＯＳ）２０２（図２）が、格納されている。オペレーティング・システムは、Linux（商標）、マイクロソフト社のWindows(商標) 7、Windows 8(商標)、Windows(商標)2003サーバ、アップルコンピュータのMac OS(商標)などの、ＣＰＵ１０４に適合する任意のものでよい。
The
ハードディスク・ドライブ１０８にはまた、Apacheなどの、Ｗｅｂサーバとしてシステムを動作させるためのプログラムが保存され、システムの起動時に、主記憶１０６にロードされる。
The
ハードディスク・ドライブ１０８にはさらに、Java(R)仮想マシン（ＪＶＭ）２０４（図２）を実現するためのJava(R) Runtime Environmentプログラムが保存され、システムの起動時に、主記憶１０６にロードされる。ＪＶＭ２０４には、本発明の機能が実装されている。
The
ハードディスク・ドライブ１０８にはさらに、アプリケーション・プログラムのバイトコード２０６（図２）が保存されている。
The
キーボード１１０及びマウス１１２は、オペレーティング・システムが提供するグラフィック・ユーザ・インターフェースに従い、ディスプレイ１１４に表示されたアイコン、タスクバー、テキストボックスなどのグラフィック・オブジェクトを操作するために使用される。
The
ディスプレイ１１４は、これには限定されないが、好適には、１０２４×７６８以上の解像度をもち、３２ビットtrue colorのＬＣＤモニタである。ディスプレイ１１４は例えば、ＪＶＭ上で実行されるアプリケーション・プログラムによる動作の結果を表示するために使用される。
The
通信インターフェース１１６は、好適には、イーサネット(R)プロトコルにより、ネットワークと接続されている。通信インターフェース１１６は、クライアント・コンピュータ（図示しない）からApacheが提供する機能により、ＴＣＰ／ＩＰなどの通信プロトコルに従い、処理リクエストを受け取り、あるいは処理結果を、クライアント・コンピュータ（図示しない）に返す。
The
アプリケーション・プログラム２０８は、Java(R)バイトコードから構成され、ＪＶＭ２０４上で動作する。ＪＶＭ２０４は、本発明のオブジェクト自動縮小機能を備えた、カスタマイズされたＪＶＭである。
The application program 208 is composed of Java (R) byte code, and operates on the
ＪＶＭ２０４は、アプリケーション・プログラム２０８のために、主記憶１０８上にヒープ領域を用意する。アプリケーション・プログラム２０８は、動作中にヒープ領域上にメモリ領域を獲得して、そこに、生成したオブジェクトを割り付ける。
The
ＪＶＭ２０４は、世代別(generational)ヒープ領域をサポートするものであってもよい。世代別ヒープ領域である場合、新しいオブジェクトを割り付けるための、少なくとも１つの第１世代の(nursery)ヒープ領域と、少なくとも１つの第２世代の(tenured)ヒープ領域からなり、ＪＶＭ２０４は、第１世代のヒープ領域が一杯になったとき、第１世代のヒープ領域でガベージ・コレクション（ＧＣ）を行い、第１世代のヒープ領域のＧＣを複数回生き残ったオブジェクトを第１世代のヒープ領域から、第２世代のヒープ領域に移動する。結果的に、第２世代のヒープ領域には、しばらく生き残っているオブジェクトが集まる。また、第２世代のヒープ領域が一杯になると、ＪＶＭ２０４はヒープ領域全体のＧＣを行う。
The
ＪＶＭ２０４は、非世代別(non-generational)ヒープ領域をサポートするものであってもよい。一方、非世代別ヒープ領域である場合、ヒープ領域は全て、第１世代のヒープ領域として扱われる。本発明は、世代別ヒープ領域と非世代別ヒープ領域の両方に適用可能である。
The
さらには、ＪＶＭ２０４は、マーク・アンド・スイープ(mark and sweep)で、ＧＣを実装するものであってもよい。
Further, the
ＪＶＭ２０４は、間欠的に、内部配列を含むコレクション・オブジェクトの利用率を調べ、その利用率が所定の利用率以下であることに応答して、前記コレクション・オブジェクトのうち、初期化が終わり更新が少なくなると予想できるコレクション・オブジェクトに対してのみ、内部配列のサイズを縮小する。
The
このとき例えば、利用率は次のようにして調べられる。すなわち、Java(R)クラスライブラリなど汎用的なハッシュ表の実装では、要素数を返すAPIが用意されていたり、要素数が増えたときにrehashを行う必要があるので、内部変数として要素数を保持している。そこで、バケット配列のサイズから求める「バケット配列のサイズに対して適切な要素数」と、内部変数に保持している要素数の比から利用率を求める。 At this time, for example, the utilization rate is examined as follows. In other words, in general-purpose hash table implementations such as the Java (R) class library, an API that returns the number of elements is prepared, or when the number of elements increases, it is necessary to perform rehash. keeping. Therefore, the utilization factor is obtained from the ratio of the “number of elements appropriate for the size of the bucket array” obtained from the size of the bucket array and the number of elements held in the internal variable.
ＪＶＭ２０４は、好適には、ＧＣに応答して、前記コレクション・オブジェクトのうち、初期化が終わり更新が少なくなると予想できるコレクション・オブジェクトに対してのみ、内部配列のサイズを縮小する。ＪＶＭ２０４は、下記の条件に従い、コレクション・オブジェクトが初期化が終わり更新が少なくなると予想する。
− プログラム言語実行環境、例えばＪＶＭが世代別ＧＣを用いている場合、コレクション・オブジェクトが第２世代の領域に移動された場合。
− Mark and sweep GCを用いている場合、コンパクション(compaction)を2回以上生き延びたオブジェクトの場合。
− あるコレクション・オブジェクトに対し、get()メソッドなど、データの挿入・削除以外の操作が一定回数以上実行された場合。
− コレクションに含まれるデータ数の変動幅が、一定期間充分小さく（たとえば10％以内）なった場合。
− 好適には、自動縮小対象を、まだ一度も自動縮小していないコレクション・オブジェクトに限定する。
In response to the GC, the
-When a programming language execution environment, for example, JVM uses generational GC, the collection object is moved to the second generation area.
− When using Mark and sweep GC, if the object has survived compaction more than once.
− When an operation other than data insertion / deletion, such as the get () method, is executed more than a certain number of times on a collection object.
-The fluctuation range of the number of data included in the collection is sufficiently small (for example, within 10%) for a certain period.
-Preferably, auto-reduction targets are limited to collection objects that have not been auto-reduced yet.
ここで、Mark and sweep GCでは、GCを繰り返すうちにヒープ領域が断片化する傾向にある。そのため、いわゆるデフラグのような処理を行って断片化を解消する処理を、GCの分野ではcompactionと呼ぶ。compactionにより断片化を解消する処理については、http://www.ibm.com/developerworks/library/j-ibmjava2/のoptthruputの章などを参照されたい。また、本発明のために、オブジェクトに「過去にcompactionを生き延びたかどうか」のフラグをつけられる。ＧＣがcompactionを行う際に、まだ生きているコレクション・オブジェクトを見つけたら、このフラグが立っているかどうかを調べる。このフラグが立っていれば、過去に1回以上compactionを生き延び、今回のcompactionも生き延びたので、2回以上生き延びたことが分かる。 Here, in the Mark and sweep GC, the heap area tends to become fragmented as the GC is repeated. For this reason, the process of defragmenting by performing a process such as so-called defragmentation is called compaction in the field of GC. Refer to the optthruput chapter of http://www.ibm.com/developerworks/library/j-ibmjava2/ for the process of eliminating fragmentation by compaction. Also, for the purposes of the present invention, an object can be flagged as “whether or not it has survived compaction in the past”. When the GC performs a compaction, if it finds a collection object that is still alive, it checks whether this flag is set. If this flag is on, you have survived one or more compactions in the past and this compaction has survived, so you know that you survived two or more times.
また、この発明によれば、各コレクション・オブジェクトに、get()メソッド（その他、値を返す機能をもつ、size()などのメソッド）が何回呼ばれたかを記録する変数を用意して、呼び出し回数が把握される。ここでの一定回数は、数百から１０００程度が妥当である。 In addition, according to the present invention, each collection object is provided with a variable for recording how many times the get () method (other methods such as size () having a function for returning a value) is called, The number of calls is known. A certain number of times here is about several hundred to 1,000.
なお、発明の別の側面によれば、縮小処理をＧＣ時に行うことで、効率よく実装する。すなわち、ＧＣによるオブジェクト移動処理では元々オブジェクト参照を修正が必要なので、キャパシティ縮小も同時に行えば、縮小後のキャパシティにあわせてデータの再配置するためにオブジェクト参照を修正する処理が、追加オーバーヘッドなしで実現できる。 Note that according to another aspect of the invention, the reduction process is performed at the time of GC, thereby efficiently mounting. That is, since the object reference processing is originally required to be corrected in the object movement processing by GC, if the capacity reduction is performed at the same time, the processing for correcting the object reference in order to rearrange the data according to the capacity after the reduction requires additional overhead. Can be realized without.
内部配列の縮小と移動を同時に行えば、移動先のメモリ領域に縮小後のサイズの内部配列を確保すればよく、縮小処理のために内部配列を別途アロケートする必要がなくなる。さらに、オブジェクトの移動は元々コストがかかる処理なので、バケット配列のインデックス計算などrehash処理のコストは、移動処理のコストと比較すると無視できる。 If the internal array is reduced and moved at the same time, it is sufficient to secure the internal array of the reduced size in the destination memory area, and there is no need to separately allocate the internal array for the reduction process. Furthermore, since the movement of an object is originally a costly process, the cost of rehash processing such as bucket array index calculation can be ignored compared to the cost of movement processing.
また、コレクション・オブジェクトの初期化が終わったかどうかの判断を、ＧＣが通常行う処理と同時に行えるので、自動縮小の対象となるオブジェクトを検索するための追加コストがない。 Further, since it is possible to determine whether or not the collection object has been initialized at the same time as the processing normally performed by the GC, there is no additional cost for searching for an object to be automatically reduced.
GCによるオブジェクト移動はオブジェクト単位で行われるので、移動と同時にオブジェクトがコレクションか否かや利用率などを調べることで、自動縮小対象のオブジェクトを追加コストなしに検索できる。また、世代別GCを用いている場合、第１世代領域から第２世代領域に移動されるオブジェクトは一定期間以上長生きしているので、そのようなコレクション・オブジェクトを自動縮小の対象とすれば、初期化が終わって更新が少なくなったと予想できるオブジェクトを、追加コストなしに検索できる。 Since object movement by GC is performed on an object-by-object basis, the object to be automatically reduced can be searched without additional cost by examining whether the object is a collection and the utilization rate at the same time as the movement. Also, when using a generational GC, objects moved from the 1st generation area to the 2nd generation area have lived longer than a certain period, so if such collection objects are subject to automatic reduction, You can search for objects that can be expected to have fewer updates after initialization, at no additional cost.
Mark and sweep GCを使っている場合、compactionが行われる時にオブジェクトが移動されるので、同時に自動縮小対象のオブジェクトかどうかを検査すれば、追加コストなしに対象オブジェクトを検索できる。 When Mark and sweep GC is used, the object is moved when compaction is performed, so if the object is automatically reduced, it can be searched without additional cost.
次に、以上のようにして初期化が終わり更新が少なくなると予想できるコレクション・オブジェクトが特定できた場合の処理を、HashMapオブジェクトとArrayListオブジェクトの各々について、図３〜５のフローチャートを参照して説明する。 Next, the processing when the collection object that can be expected to be updated after the initialization is completed as described above can be identified as described above for each of the HashMap object and the ArrayList object will be described with reference to the flowcharts of FIGS. To do.
図３及び図４は、ＧＣによるHashMapオブジェクトの移動処理のフローチャートを示す図である。 FIG. 3 and FIG. 4 are flowcharts showing the movement processing of the HashMap object by GC.
図３のステップ３０２において、ＪＶＭ２０４は、移動先にHashMapオブジェクトのメモリを確保し、内容をコピーする。
In
ステップ３０４において、ＪＶＭ２０４は、移動先に縮小後のバケット配列のサイズで、メモリを確保する。
In
ステップ３０６において、ＪＶＭ２０４は、HashMapの内のすべてのエントリを移動して、処理を終わる。
In
図４は、図３のステップ３０６の、より詳細な処理のフローチャートを示す図である。
FIG. 4 is a flowchart showing a more detailed process of
図４のステップ４０２で、ＪＶＭ２０４は、移動してないエントリがあるかどうか判断し、そうでないなら、直ちに戻る。
In
まだ移動してないエントリがあるなら、ＪＶＭ２０４は、ステップ４０４で移動元のバケット配列からエントリを取り出し、ステップ４０６で移動先にエントリのメモリを確保し、内容をコピーする。
If there is an entry that has not yet been moved, the
次にＪＶＭ２０４は、ステップ４０８で、エントリのハッシュ値から、移動先バケット配列のインデックスを求め、ステップ４１０で移動先バケット配列の、ステップ４０８で求めたインデックスのリストに、移動先のエントリをつなげて、ステップ４０２に戻る。
Next, in
図５は、ＧＣによるArrayListオブジェクトの移動処理であり、ステップ５０２において、ＪＶＭ２０４は、移動先にArrayListオブジェクトのメモリを確保し、内容をコピーする。
FIG. 5 shows a process of moving the ArrayList object by GC. In
ステップ５０４において、ＪＶＭ２０４は、移動先に縮小後の内部配列のサイズで、メモリを確保する。
In
次にステップ５０６において、ＪＶＭ２０４は、内部配列内の有効な要素を、移動先の内部配列にコピーして、処理を終わる。
Next, in
上記実施例では、HashMap及びArrayListの例で説明したが、本発明はこれには限定されず、ConcurrentHashMap、LinkedListなど、AbstractCollection、AbstractList、AbstractMapなどの抽象コレクション・オブジェクトのクラスを継承する、任意のオブジェクトに適用可能である。 In the above embodiment, the examples of HashMap and ArrayList have been described. However, the present invention is not limited to this, and any object that inherits the classes of abstract collection objects such as AbstractCollection, AbstractList, and AbstractMap such as ConcurrentHashMap and LinkedList. It is applicable to.
以上、この発明を、Java(R)処理系における処理を例として説明してきたが、この発明はそれには限定されず、配列をもつオブジェクトを縮小する処理が可能な任意のオペレーティング・システムあるいは処理系の下で実装可能であることを理解されたい。 As described above, the present invention has been described by taking the processing in the Java (R) processing system as an example. However, the present invention is not limited to this, and any operating system or processing system capable of reducing an object having an array. It should be understood that it can be implemented under.
１０４ ＣＰＵ
１０６ 主記憶
１０８ ハードディスク・ドライブ
２０２ オペレーティング・システム
２０４ ＪＶＭ
104 CPU
106
Claims (13)
内部配列を含むコレクション・オブジェクトを生成するステップと、
間欠的に前記コレクション・オブジェクトの利用率を調べるステップと、
前記利用率が所定の利用率以下であることに応答して、前記コレクション・オブジェクトのうち、初期化が終わり更新が少なくなると予想できるコレクション・オブジェクトに対してのみ、内部配列のサイズを縮小するステップを有する、
方法。 A method of managing computer memory by computer processing,
Generating a collection object containing an internal array;
Intermittently checking the utilization rate of the collection object;
Responding to the fact that the utilization rate is equal to or lower than a predetermined utilization rate, reducing the size of the internal array only for the collection object that can be expected to be updated after the initialization is completed. Having
Method.
(a) ＪＶＭが世代別GCを用いている場合、コレクション・オブジェクトが第２世代領域に移動された場合、
(b) Mark and sweep GCを用いている場合、compactionを2回以上生き延びたオブジェクトの場合、
(c) get()メソッドなどによって、データの挿入・削除以外の操作が一定回数以上実行されたオブジェクトの場合、
(d) 自動縮小対象を、まだ一度も自動縮小していないコレクション・オブジェクト。 The determination that the collection object can be predicted that the initialization is completed and updates are reduced is performed based on any of the following (a), (b), (c), or (d): the method of.
(a) When the JVM uses a generational GC, when the collection object is moved to the second generation area,
(b) When using Mark and sweep GC, if the object has survived compaction more than once,
(c) For an object for which operations other than data insertion / deletion have been executed more than a certain number of times, such as by get () method,
(d) Collection objects that have not been auto-shrinked yet.
前記コンピュータに、
内部配列を含むコレクション・オブジェクトを生成するステップと、
間欠的に前記コレクション・オブジェクトの利用率を調べるステップと、
前記利用率が所定の利用率以下であることに応答して、前記コレクション・オブジェクトのうち、初期化が終わり更新が少なくなると予想できるコレクション・オブジェクトに対してのみ、内部配列のサイズを縮小するステップを実行させる、
プログラム。 A program for managing computer memory by computer processing,
In the computer,
Generating a collection object containing an internal array;
Intermittently checking the utilization rate of the collection object;
Responding to the fact that the utilization rate is equal to or lower than a predetermined utilization rate, reducing the size of the internal array only for the collection object that can be expected to be updated after the initialization is completed. To execute,
program.
(a) ＪＶＭが世代別GCを用いている場合、コレクション・オブジェクトが第２世代領域に移動された場合、
(b) Mark and sweep GCを用いている場合、compactionを2回以上生き延びたオブジェクトの場合、
(c) get()メソッドなどによって、データの挿入・削除以外の操作が一定回数以上実行されたオブジェクトの場合、
(d) 自動縮小対象を、まだ一度も自動縮小していないコレクション・オブジェクト。 The determination that the collection object can be predicted that the initialization is completed and the number of updates is reduced is made based on any of the following (a), (b), (c), or (d): Program.
(a) When the JVM uses a generational GC, when the collection object is moved to the second generation area,
(b) When using Mark and sweep GC, if the object has survived compaction more than once,
(c) For an object for which operations other than data insertion / deletion have been executed more than a certain number of times, such as by get () method,
(d) Collection objects that have not been auto-shrinked yet.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013103042A JP6173031B2 (en) | 2013-05-15 | 2013-05-15 | Method, program and system for managing objects in a computer |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013103042A JP6173031B2 (en) | 2013-05-15 | 2013-05-15 | Method, program and system for managing objects in a computer |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2014225077A true JP2014225077A (en) | 2014-12-04 |
| JP6173031B2 JP6173031B2 (en) | 2017-08-02 |
Family
ID=52123728
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2013103042A Expired - Fee Related JP6173031B2 (en) | 2013-05-15 | 2013-05-15 | Method, program and system for managing objects in a computer |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6173031B2 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106547603A (en) * | 2015-09-23 | 2017-03-29 | 北京奇虎科技有限公司 | The method and apparatus for reducing the golang language system garbage reclamation times |
| US9921858B2 (en) | 2014-09-16 | 2018-03-20 | International Business Machines Corporation | Apparatus and method for realizing runtime system for programming language |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS6476227A (en) * | 1987-09-18 | 1989-03-22 | Nec Corp | System for adapting hash table size |
| JPH07334366A (en) * | 1994-06-07 | 1995-12-22 | Fujitsu Ltd | Method and device for optimizing graph reduction mechanism |
| JP2000040006A (en) * | 1998-04-21 | 2000-02-08 | Internatl Business Mach Corp <Ibm> | Method and system for improving program accessing memory array |
| US20080005403A1 (en) * | 2006-06-29 | 2008-01-03 | Nokia Corporation | Overcoming compilation buffer overloads in virtual machines |
-
2013
- 2013-05-15 JP JP2013103042A patent/JP6173031B2/en not_active Expired - Fee Related
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS6476227A (en) * | 1987-09-18 | 1989-03-22 | Nec Corp | System for adapting hash table size |
| JPH07334366A (en) * | 1994-06-07 | 1995-12-22 | Fujitsu Ltd | Method and device for optimizing graph reduction mechanism |
| JP2000040006A (en) * | 1998-04-21 | 2000-02-08 | Internatl Business Mach Corp <Ibm> | Method and system for improving program accessing memory array |
| US20080005403A1 (en) * | 2006-06-29 | 2008-01-03 | Nokia Corporation | Overcoming compilation buffer overloads in virtual machines |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9921858B2 (en) | 2014-09-16 | 2018-03-20 | International Business Machines Corporation | Apparatus and method for realizing runtime system for programming language |
| US10331465B2 (en) | 2014-09-16 | 2019-06-25 | International Business Machines Corporation | Apparatus and method for realizing runtime system for programming language |
| US10922107B2 (en) | 2014-09-16 | 2021-02-16 | International Business Machines Corporation | Apparatus and method for realizing runtime system for programming language |
| CN106547603A (en) * | 2015-09-23 | 2017-03-29 | 北京奇虎科技有限公司 | The method and apparatus for reducing the golang language system garbage reclamation times |
| CN106547603B (en) * | 2015-09-23 | 2021-05-18 | 北京奇虎科技有限公司 | Method and device for reducing garbage recovery time of golang language system |
Also Published As
| Publication number | Publication date |
|---|---|
| JP6173031B2 (en) | 2017-08-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100384905B1 (en) | Relation-based ordering of objects in an object heap | |
| US8849876B2 (en) | Methods and apparatuses to optimize updates in a file system based on birth time | |
| US8429633B2 (en) | Managing memory to support large-scale interprocedural static analysis for security problems | |
| US10838857B2 (en) | Multi-section garbage collection | |
| US20140068572A1 (en) | Java native interface array handling in a distributed java virtual machine | |
| US8983908B2 (en) | File link migration for decommisioning a storage server | |
| JP2015524593A (en) | System and method for deleting objects in persistent memory using a bitmap window | |
| US11755556B2 (en) | Method, device, and computer program product for managing storage system | |
| US20210089442A1 (en) | Dynamically allocating memory pool subinstances | |
| US20200183835A1 (en) | Multi-Ring Shared, Traversable, and Dynamic Advanced Database | |
| US8447793B2 (en) | Efficient remembered set for region-based garbage collectors | |
| JP6173031B2 (en) | Method, program and system for managing objects in a computer | |
| US10120796B2 (en) | Memory allocation for long-lived objects | |
| US11474832B2 (en) | Intelligently determining a virtual machine configuration during runtime based on garbage collection characteristics | |
| US10922107B2 (en) | Apparatus and method for realizing runtime system for programming language | |
| JP5889270B2 (en) | Method, program and system for reducing stack scan cost | |
| US20180293164A1 (en) | Automatic persistent memory management | |
| US20200142677A1 (en) | Fields Hotness Based Object Splitting | |
| US11017032B1 (en) | Document recovery utilizing serialized data | |
| JP6103994B2 (en) | Character string data processing method, program and system | |
| US20240126688A1 (en) | Lazy compaction in garbage collection | |
| Sutherland et al. | Managing Memory for Game Developers |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20160419 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20170214 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20170314 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20170601 |
|
| 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: 20170613 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20170704 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6173031 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |