JP2004078636A - Memory management system, memory arranging method and its program and recording medium - Google Patents
Memory management system, memory arranging method and its program and recording medium Download PDFInfo
- Publication number
- JP2004078636A JP2004078636A JP2002238938A JP2002238938A JP2004078636A JP 2004078636 A JP2004078636 A JP 2004078636A JP 2002238938 A JP2002238938 A JP 2002238938A JP 2002238938 A JP2002238938 A JP 2002238938A JP 2004078636 A JP2004078636 A JP 2004078636A
- Authority
- JP
- Japan
- Prior art keywords
- thread
- memory
- area
- threads
- computer
- 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.)
- Pending
Links
Images
Abstract
Description
【0001】
【発明の属する技術分野】
本発明は、計算機におけるプロセス実行時に生成されるオブジェクトの動的メモリ配置技術に係わり、例えば、キャッシュ性能の向上等を図るのに好適なメモリ管理技術に関するものである。
【0002】
【従来の技術】
通常の計算機(コンピュータ)においては、プロセスの実行単位はスレッドであり、プロセス実行時に個々のスレッドより生成される個々のオブジェクトは、当該プロセス用のヒープ領域に、生成順に格納され、その後、スレッド単位でプロセスが実行される際、中央演算装置(CPU)が前出のオブジェクトをヒープ領域から読み出して実行する。
【0003】
この際、使用頻度の高いオブジェクトは、ヒープ領域よりもアクセス速度の速いデータキャッシュに保持し、実行速度を高速化することが従来行われている。
【0004】
しかしながら、一般的に、データキャッシュのサイズは有限であり、データキャッシュに取り込まれるデータサイズは固定長であり、基本的に、データキャッシュに取り込まれるデータは、プロセスが使用するメモリの部分的な複製であり、ヒープ領域の部分的な複製でもある。従って、データキャッシュにおいても、オブジェクトはその生成順に保持された状態である。
【0005】
このように、データキャッシュにおいては、1つのプロセスの各スレッドが生成した全てのオブジェクトを保持するものではない。そのため、中央演算装置がデータキャッシュから読み出したデータ内のオブジェクト全てが、1つのスレッドにおいて使用頻度の高いオブジェクトとは限らず、キャッシュミスが発生する。
【0006】
また、一般的に、1つのプロセスで使用される論理メモリ空間は、そのプロセス内のみで有効であり、かつ、一般的に、プロセス毎に使用する論理メモリ空間を切り替えるため、論理メモリ空間と物理メモリ空間のマッピングが必要になる。
【0007】
プロセスから見える論理メモリ空間のアドレス(仮想アドレス)から実際のメモリ・アドレス(物理アドレス)への対応表の中で頻繁に使用されるものを一時的に保存するバッファをTLB(Translation Look−aside Buffer)といい、このTLBを用いることにより、これら仮想アドレスと物理アドレスの変換を高速に実行できる。
【0008】
ところが、前出の論理メモリ空間は、上述したヒープ領域を含んでおりオブジェクトが生成順にヒープ領域上に配置されていけば、TLBに保存された1つの変換に含まれるオブジェクトの全てが1つのスレッドで頻繁に参照されるとは限らない。
【0009】
【発明が解決しようとする課題】
解決しようとする問題点は、従来の技術では、データキャッシュおよびTLBに含まれるオブジェクトの全てが1つのスレッドで頻繁に使用されるとは限らない点である。
【0010】
本発明の目的は、これら従来技術の課題を解決し、プロセス実行時にデータキャッシュおよびTLBに取り込まれるデータ、すなわちヒープ領域に、1つのスレッドから頻繁に参照されるオブジェクトを集約させることで、データキャッシュおよびTLBキャッシュのヒット率を向上させることである。
【0011】
【課題を解決するための手段】
上記目的を達成するため、本発明では、計算機におけるプロセス実行時に複数スレッドが生成するオブジェクトのメモリ配置先を動的に制御し、使用頻度の高いオブジェクト同士を近傍に配置することを特徴とする。すなわち、プロセスにおける論理メモリ空間のヒープ領域に、スレッド毎の固有領域を割り当てることで、1つのスレッドが生成するオブジェクトを、メモリ、もしくは記憶装置上で連続して配置させる。このことにより、ヒープ領域内に生成されるオブジェクトがスレッド単位でまとまり、データキャッシュに取り込まれる単位データ内の複数のオブジェクトに、同一のスレッドのオブジェクトが入る可能性が高くなり、結果として、データキャッシュのヒット率が向上する。
【0012】
【発明の実施の形態】
以下、本発明の実施の形態を、図面により詳細に説明する。
【0013】
図1は、本発明に係わるメモリ管理システムの構成例を示すブロック図であり、図2は、図1におけるメモリ管理システムを実装したコンピュータのハードウェア構成例を示すブロック図である。
【0014】
図2において、21はCRT(Cathode Ray Tube)やLCD(Liquid Crystal Display)等からなる表示装置、22はキーボードやマウス等からなる入力装置、23はHDD(Hard Disk Drive)等からなる外部記憶装置、24はCPU(Central Processing Unit)24aや主メモリ24bおよび入出力インタフェース24c等を具備してコンピュータ処理を行なう情報処理装置、25は本発明に係わるプログラムやデータを記録したCD−ROM(Compact Disc−Read Only Memory)もしくはDVD(Digital Video Disc/Digital Versatile Disc)等からなる光ディスク、26は光ディスク25に記録されたプログラムおよびデータを読み出すための駆動装置、27はLAN(Local Area Network)カードやモデム等からなる通信装置である。
【0015】
光ディスク25に格納されたプログラムおよびデータを情報処理装置24により駆動装置26を介して外部記憶装置23内にインストールした後、外部記憶装置23から主メモリ24bに読み込みCPU24aで処理することにより、情報処理装置24内に図1に示すメモリ管理システムを含む各処理部が構成される。
【0016】
図1において、1はメモリ管理システム、2はプロセス実行部であり、メモリ管理システム1は、領域割当部11、マップ生成部12、マップ情報記憶部13オブジェクト配置部14により構成されるメモリ管理部10を有する。
【0017】
このような構成により、本例のメモリ管理システム1では、コンピュータにおけるプロセス実行時に、複数スレッドが生成するオブジェクトをメモリに配置する際、スレッド単位でメモリ領域を割り当て、スレッドが生成したオブジェクトを、当該スレッドに割り当てたメモリ領域に配置する。
【0018】
すなわち、領域割当部11により、プロセス用のヒープ領域をスレッド単位で割り当て、マップ生成部12において、スレッドに割り当てた領域と当該スレッドとの対応付け情報を生成し、マップ情報記憶部13で、その情報をテーブル(スレッドヒープ領域マップ15)に記憶し、オブジェクト配置部14において、スレッドが生成するオブジェクトを、マップ情報記憶部13でスレッドヒープ領域マップ15に記憶している対応付け情報を参照して、当該スレッドに割り当てた領域に配置する。
【0019】
スレッドヒープ領域マップ15においては、各スレッドの特定に用いるスレッド識別情報が登録されるスレッドID15aと、各スレッドに割り当てたメモリ領域の特定に用いる領域情報15bとの項目が設けられており、このスレッドヒープ領域マップ15の内容に基づき、例えば、スレッドAaが生成するオブジェクトは、アドレス情報Aaで特定されるメモリ領域に配置される。
【0020】
このように、本例では、メモリ管理部10を新たに設けることにより、コンピュータのプロセス実行過程において、プロセスの実行単位であるスレッドによるオブジェクトの生成時に、スレッド毎にオブジェクトの生成場所を動的に制御することで、使用頻度の高いオブジェクト同士を近傍に配置する。
【0021】
ここでの動的な制御は、メモリ管理部10において、当該プロセスにおける論理メモリ空間のヒープ領域に、スレッド毎の固有領域を割り当てることで行われる。また、オブジェクトの近傍配置とは、メモリ、もしくはデータキャッシュやTLB(Translation Look−aside Buffer)等の記憶装置上でオブジェクトが連続して配置されていることを意味する。
【0022】
このオブジェクトの近傍配置により、ヒープ領域内に生成されるオブジェクトがスレッド単位でまとまり、例えばデータキャッシュに取り込まれる単位データ内の複数のオブジェクトに、同一のスレッドのオブジェクトが入る可能性が高くなる。
【0023】
プロセス実行時には複数のスレッドが実行されるが、一般的に、データキャッシュは1つのスレッドに対してのみ有効であり、スレッド切り替えが生じればデータキャッシュの有効性はなく、有効なデータキャッシュが再構築される。
【0024】
上述したように、本例では、データキャッシュの中に同一スレッドのオブジェクトが入る可能性が高く、結果として、従来の技術よりもデータキャッシュのヒット率が向上する。
【0025】
同様に、TLBキャッシュにおいても、1スレッドに使用されるオブジェクトが同一ページ上に存在する可能性が高く、それらのページをTLBキャッシュに取り込むことで、同一スレッド実行時におけるTLBキャッシュヒット率が向上する。
【0026】
さらに、スレッド切り替え時には、常に一定数のページファイルの切り替えが要求されるが、このページファイル切り替え数は、オブジェクトが生成順にヒープ領域に格納されている場合よりも、スレッド数が十分多い場合には、少なくなるので、大規模アプリケーションに対して、本例が極めて有効であることがわかる。
【0027】
以下、図3から図5を用いて、本例のメモリ管理システムの処理動作を説明する。
【0028】
図3は、図1におけるメモリ管理システムによるメモリ配置処理例を示すフローチャートであり、図4は、図1におけるメモリ管理システムの第1の処理動作例を示す説明図、図5は、図1におけるメモリ管理システムの第2の処理動作例を示す説明図である。
【0029】
図3に示すように、プロセスAにおけるスレッドAaの生成要求があれば(ステップ301)、図1におけるメモリ管理システム1は、当該スレッドAaに、プロセスA用のヒープ領域における領域Aaを割り当て(ステップ302)、その割当結果を、例えば、図1におけるスレッドヒープ領域マップ15に示すように、各スレッドの特定に用いるスレッド識別情報(スレッドID:Aa)と、各スレッドに割り当てたメモリ領域の特定に用いる領域情報(アドレスAa)とを対応付け、記憶装置に記憶する(ステップ303)。
【0030】
その後、スレッドAaによるオブジェクトの生成要求があれば(ステップ304)、図1におけるスレッドヒープ領域マップ15を参照して、当該スレッドAaに割り当てた領域Aaを特定し、この領域Aaに、当該オブジェクトを配置する(ステップ305)。
【0031】
次の図4および図5の処理においては、「JAVA(登録商標) VM」における例を説明する。
【0032】
「JAVA(登録商標) VM」ではヒープ領域管理技術として、「Garbage Collection」(GC)を使用しており、本例では、GCの技術として「Generation GC」を使用した場合について述べる。
【0033】
「Generation GC」では図4に示すように、ヒープ領域は大きく「New Generation」、「Old Generation」、「Permanent Generation」という3つの領域に分けられ、その中でも更に「New Generation」は「Eden」と「Survivor」という2つの領域に分けられる。
【0034】
上記構造において新規にオブジェクトが生成される場合には常に、「Eden」領域からオブジェクトが生成される。
【0035】
本例ではメモリ管理部10を新たに設け、プロセス実行時にスレッド生成要求が生じた場合、そのスレッド生成要求をメモリ管理部10が取得し、メモリ管理部10はプロセスのヒープ領域をスレッドヒープ領域マップ15で管理する。
【0036】
メモリ管理部10は、スレッド毎に一定ヒープ領域を「GenerationGC」に使用される複数ジェネレーションにわたって確保を行い、その領域をスレッドに対して通知を行う。
【0037】
尚、この際に生成されるスレッド毎のヒープ領域は、事前に静的に決定されているものであり、ユーザからの要求によって任意の領域を割り当てることが可能である。
【0038】
例えば、プロセスを実行中にスレッドAaの生成要求が生じれば(図4中(1))、メモリ管理部10は、その通知を取得し、メモリ管理部10が持つスレッドヒープ領域マップ15から新たなスレッド用エリアを判断し(図4中(2))、実ヒープ領域の確保を行う(図4中(3))。その情報を基にスレッドAaが作成される(図4中(4),(5),(6))。
【0039】
図5においては、スレッド実行時のオブジェクト生成例を示しており、オブジェクト生成要求が生じた場合、生成要求をメモリ管理部10に通知し、メモリ管理部10は、スレッドヒープ領域マップ15に従って、要求されたオブジェクトを「New Generation」の「Eden」領域に生成する。
【0040】
例えば、プロセス実行中にスレッドAaに処理が移った場合(図5中(1))、スレッドAを実行するに当たってオブジェクトの生成要求はメモリ管理部10に通知され(図5中(2))、メモリ管理部10がそのスレッドAaに割り当てられたヒープ領域(「Eden」領域)に、要求されたオブジェクトを生成する(図5中(3))。
【0041】
メモリ管理部10は、生成されたヒープ領域のアドレスを返り値としてスレッドAaに通知する。
【0042】
以上、図1〜図5を用いて説明したように、本例では、コンピュータ(計算機)におけるプロセス実行時に複数スレッドが生成するオブジェクトのメモリ配置先を動的に制御し、使用頻度の高いオブジェクト同士を近傍に配置する。すなわち、プロセスにおける論理メモリ空間のヒープ領域に、スレッド毎の固有領域を割り当てることで、1つのスレッドが生成するオブジェクトを、メモリ、もしくは記憶装置上で連続して配置させる。
【0043】
このことにより、ヒープ領域内に生成されるオブジェクトがスレッド単位でまとまり、使用頻度の高いオブジェクト同士が近傍に配置されることにより、例えばデータキャッシュに取り込まれる単位データ内の複数のオブジェクトに、同一のスレッドのオブジェクトが入る可能性が高くなり、結果として、データキャッシュのヒット率が向上する。
【0044】
さらに、1つのプロセス内でスレッド数が十分多い場合には、使用頻度の高いオブジェクト同士が近傍に配置されることにより、同一ページ内に配置される可能性が高くなり、その結果としてTLBのヒット率を向上させることができる。
【0045】
尚、本発明は、図1〜図5を用いて説明した例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。例えば、本例では、「JAVA(登録商標) VM」を例として説明したが、「JAVA(登録商標)」以外の他のプログラム言語で動作するコンピュータにおいても適用可能である。
【0046】
また、各スレッドに割り当てるヒープ領域(スレッド割り当てヒープ)のサイズに関しては、全てのスレッドに対して同じ大きさにすることでも、それぞれ異なるように設定しても良い。
【0047】
また、本例では、コンピュータ(計算機)の構成として図2の構成例を示したが、キーボードや光ディスクの駆動装置の無いコンピュータ構成としても良い。また、本例では、光ディスクを記録媒体として用いているが、FD(Flexible Disk)等を記録媒体として用いることでも良い。また、プログラムのインストールに関しても、通信装置を介してネットワーク経由でプログラムをダウンロードしてインストールすることでも良い。
【0048】
【発明の効果】
本発明によれば、使用頻度の高いオブジェクト同士が近傍に配置され、このことにより、例えばデータキャッシュのデータ取り込み時に1つのスレッドからの使用頻度の高いオブジェクトが取り込まれ、その結果としてデータキャッシュのヒット率を向上させることができ、かつ、1つのプロセス内でスレッド数が十分多い場合には、使用頻度の高いオブジェクト同士が近傍に配置されることにより、同一ページ内に配置される可能性が高くなり、その結果としてTLBのヒット率を向上させることが可能である。
【図面の簡単な説明】
【図1】本発明に係わるメモリ管理システムの構成例を示すブロック図である。
【図2】図1におけるメモリ管理システムを実装したコンピュータのハードウェア構成例を示すブロック図である。
【図3】図1におけるメモリ管理システムによるメモリ配置処理例を示すフローチャートである。
【図4】図1におけるメモリ管理システムの第1の処理動作例を示す説明図である。
【図5】図1におけるメモリ管理システムの第2の処理動作例を示す説明図である。
【符号の説明】
1:メモリ管理システム、2:プロセス実行部、10:メモリ管理部、11:領域割当部、12:マップ生成部、13:マップ情報記憶部、14オブジェクト配置部、15:スレッドヒープ領域マップ、15a:スレッドID、15b:領域情報、21:表示装置、22:入力装置、23:外部記憶装置、24:情報処理装置、24a:CPU、24b:主メモリ、24c:入出力インタフェース、25:光ディスク、26:駆動装置、27:通信装置。[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a technique for dynamically allocating objects generated when a process is executed in a computer, and more particularly to a memory management technique suitable for improving cache performance and the like.
[0002]
[Prior art]
In a normal computer (computer), the execution unit of a process is a thread, and individual objects generated by the individual threads when the process is executed are stored in the heap area for the process in the order of generation, and thereafter, the thread unit When the process is executed by the CPU, the central processing unit (CPU) reads the above-mentioned object from the heap area and executes it.
[0003]
At this time, conventionally, frequently used objects are stored in a data cache having an access speed higher than that of a heap area, thereby increasing the execution speed.
[0004]
However, in general, the size of the data cache is finite, the size of the data taken into the data cache is fixed, and basically, the data taken into the data cache is a partial copy of the memory used by the process. And is also a partial copy of the heap area. Therefore, even in the data cache, the objects are held in the order of generation.
[0005]
As described above, the data cache does not hold all the objects generated by each thread of one process. Therefore, all objects in the data read from the data cache by the central processing unit are not necessarily objects frequently used in one thread, and a cache miss occurs.
[0006]
In general, the logical memory space used by one process is effective only within that process, and generally, the logical memory space used for each process is switched. Memory space mapping is required.
[0007]
A buffer for temporarily storing frequently used ones in a correspondence table from an address (virtual address) of a logical memory space visible to a process to an actual memory address (physical address) is provided in a TLB (Translation Look-Aside Buffer). ), The use of this TLB enables high-speed conversion between these virtual addresses and physical addresses.
[0008]
However, the above-described logical memory space includes the above-described heap area, and if objects are arranged on the heap area in the order of generation, all of the objects included in one conversion stored in the TLB are one thread. Is not always referred to.
[0009]
[Problems to be solved by the invention]
The problem to be solved is that in the related art, not all objects included in the data cache and TLB are frequently used by one thread.
[0010]
SUMMARY OF THE INVENTION An object of the present invention is to solve the problems of the prior art, and to collect data frequently fetched from one thread into a data fetched into a data cache and a TLB at the time of executing a process, that is, a heap area. And to improve the hit rate of the TLB cache.
[0011]
[Means for Solving the Problems]
In order to achieve the above object, the present invention is characterized in that a memory allocation destination of an object generated by a plurality of threads when a process is executed in a computer is dynamically controlled, and frequently used objects are arranged near each other. That is, by allocating a unique area for each thread to a heap area of a logical memory space in a process, objects generated by one thread are continuously arranged on a memory or a storage device. As a result, the objects generated in the heap area are grouped in units of threads, and the possibility that an object of the same thread is included in a plurality of objects in the unit data taken into the data cache is increased. Hit rate is improved.
[0012]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
[0013]
FIG. 1 is a block diagram showing a configuration example of a memory management system according to the present invention, and FIG. 2 is a block diagram showing a hardware configuration example of a computer on which the memory management system in FIG. 1 is mounted.
[0014]
2, reference numeral 21 denotes a display device such as a CRT (Cathode Ray Tube) or an LCD (Liquid Crystal Display); 22, an input device including a keyboard and a mouse; and 23, an external storage device including a HDD (Hard Disk Drive). , 24 are an information processing apparatus having a CPU (Central Processing Unit) 24a, a
[0015]
After the programs and data stored in the
[0016]
In FIG. 1, 1 is a memory management system, 2 is a process execution unit, and the
[0017]
With such a configuration, in the
[0018]
That is, the
[0019]
In the thread
[0020]
As described above, in the present example, by newly providing the
[0021]
The dynamic control here is performed by the
[0022]
Due to the close arrangement of the objects, the objects generated in the heap area are grouped in units of threads, and for example, there is a high possibility that an object of the same thread enters a plurality of objects in the unit data taken into the data cache.
[0023]
When a process is executed, a plurality of threads are executed. Generally, however, the data cache is valid for only one thread, and if a thread switch occurs, the data cache is not valid, and the valid data cache is restored. Be built.
[0024]
As described above, in this example, there is a high possibility that an object of the same thread enters the data cache, and as a result, the hit ratio of the data cache is improved as compared with the related art.
[0025]
Similarly, in the TLB cache, there is a high possibility that an object used for one thread exists on the same page, and by taking those pages into the TLB cache, the TLB cache hit rate during execution of the same thread is improved. .
[0026]
Furthermore, when switching threads, switching of a certain number of page files is always required.However, this number of page files is switched when the number of threads is sufficiently larger than when the objects are stored in the heap area in the order of generation. It can be seen that this example is extremely effective for large-scale applications.
[0027]
Hereinafter, the processing operation of the memory management system of this example will be described with reference to FIGS.
[0028]
FIG. 3 is a flowchart showing an example of a memory arrangement process by the memory management system in FIG. 1, FIG. 4 is an explanatory diagram showing a first processing operation example of the memory management system in FIG. 1, and FIG. FIG. 13 is an explanatory diagram illustrating a second processing operation example of the memory management system.
[0029]
As shown in FIG. 3, when there is a request to create a thread Aa in the process A (step 301), the
[0030]
Thereafter, when there is a request to generate an object by the thread Aa (step 304), the area Aa assigned to the thread Aa is specified with reference to the thread
[0031]
In the following processing in FIGS. 4 and 5, an example in “JAVA (registered trademark) VM” will be described.
[0032]
“JAVA (registered trademark) VM” uses “Garbage Collection” (GC) as a heap area management technique. In this example, a case where “Generation GC” is used as a GC technique will be described.
[0033]
As shown in FIG. 4, in the “Generation GC”, the heap area is largely divided into three areas “New Generation”, “Old Generation”, and “Permanent Generation”, and among them, “New Generation” is further referred to as “Eden”. It is divided into two areas called “Survivor”.
[0034]
Whenever a new object is created in the above structure, an object is created from the “Eden” area.
[0035]
In this example, a
[0036]
The
[0037]
Note that the heap area for each thread generated at this time is statically determined in advance, and an arbitrary area can be allocated according to a request from the user.
[0038]
For example, if a request to create a thread Aa occurs during the execution of the process ((1) in FIG. 4), the
[0039]
FIG. 5 shows an example of object generation at the time of thread execution. When an object generation request occurs, the generation request is notified to the
[0040]
For example, when the process is transferred to the thread Aa during the execution of the process ((1) in FIG. 5), a request to create an object is notified to the
[0041]
The
[0042]
As described above with reference to FIGS. 1 to 5, in the present example, the memory allocation destination of the objects generated by a plurality of threads when a process is executed in a computer (computer) is dynamically controlled, and objects frequently used are Is placed in the vicinity. That is, by allocating a unique area for each thread to a heap area of a logical memory space in a process, objects generated by one thread are continuously arranged on a memory or a storage device.
[0043]
As a result, objects generated in the heap area are grouped in units of threads, and frequently used objects are arranged close to each other, so that, for example, the same object is assigned to a plurality of objects in unit data taken into the data cache. The likelihood of thread objects entering is increased, resulting in an improved data cache hit rate.
[0044]
Furthermore, if the number of threads in one process is sufficiently large, the objects that are frequently used are arranged close to each other, so that the possibility that the objects are arranged in the same page increases. Rate can be improved.
[0045]
The present invention is not limited to the examples described with reference to FIGS. 1 to 5 and can be variously modified without departing from the gist thereof. For example, in this example, “JAVA (registered trademark) VM” has been described as an example, but the present invention is also applicable to a computer that operates in a program language other than “JAVA (registered trademark)”.
[0046]
Further, the size of the heap area (thread allocation heap) allocated to each thread may be the same for all threads or may be set differently.
[0047]
Further, in this example, the configuration example of FIG. 2 is shown as a configuration of a computer (computer), but a computer configuration without a keyboard or a drive device of an optical disk may be used. In this example, the optical disk is used as the recording medium, but an FD (Flexible Disk) or the like may be used as the recording medium. As for the installation of the program, the program may be downloaded and installed via a network via a communication device.
[0048]
【The invention's effect】
According to the present invention, frequently used objects are arranged close to each other, whereby, for example, a frequently used object from one thread is fetched when data is fetched from the data cache, and as a result, a hit in the data cache occurs. When the ratio can be improved and the number of threads in one process is sufficiently large, the objects that are frequently used are arranged close to each other, so that there is a high possibility that the objects are arranged in the same page. As a result, it is possible to improve the TLB hit rate.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a configuration example of a memory management system according to the present invention.
FIG. 2 is a block diagram illustrating a hardware configuration example of a computer on which the memory management system in FIG. 1 is mounted.
FIG. 3 is a flowchart illustrating an example of a memory allocation process by the memory management system in FIG. 1;
FIG. 4 is an explanatory diagram showing a first processing operation example of the memory management system in FIG. 1;
FIG. 5 is an explanatory diagram showing a second processing operation example of the memory management system in FIG. 1;
[Explanation of symbols]
1: memory management system, 2: process execution unit, 10: memory management unit, 11: area allocation unit, 12: map generation unit, 13: map information storage unit, 14 object arrangement unit, 15: thread heap area map, 15a : Thread ID, 15b: area information, 21: display device, 22: input device, 23: external storage device, 24: information processing device, 24a: CPU, 24b: main memory, 24c: input / output interface, 25: optical disk, 26: drive device, 27: communication device.
Claims (6)
スレッド単位でメモリ領域を割り当て、スレッドが生成したオブジェクトを、当該スレッドに割り当てたメモリ領域に配置するメモリ管理手段を有することを特徴とするメモリ管理システム。A memory management system for controlling memory allocation of objects generated by a plurality of threads when a process of a computer is executed,
A memory management system, comprising: a memory management unit that allocates a memory area in units of threads, and arranges an object generated by the thread in the memory area allocated to the thread.
上記プロセス用のヒープ領域をスレッド単位で割り当てる割当手段と、
スレッドに割り当てた領域と当該スレッドとの対応付け情報を記憶する記憶手段と、
スレッドが生成するオブジェクトを、上記記憶手段で記憶した対応付け情報を参照して、当該スレッドに割り当てた領域に配置する手段と
を有することを特徴とするメモリ管理システム。A memory management system for controlling memory allocation of objects generated by a plurality of threads when a process of a computer is executed,
Allocating means for allocating a heap area for the process in units of threads,
Storage means for storing information associated with an area allocated to a thread and the thread;
Means for arranging an object generated by a thread in an area allocated to the thread with reference to the association information stored in the storage means.
スレッド単位でメモリ領域を割り当てる手順と、
スレッドが生成したオブジェクトを、当該スレッドに割り当てたメモリ領域に配置する手順とを有することを特徴とするメモリ配置方法。A memory allocation method of an object generated by a plurality of threads when a process is executed in a computer,
A procedure for allocating a memory area for each thread;
Allocating an object generated by a thread to a memory area allocated to the thread.
上記プロセス用のヒープ領域をスレッド単位で割り当てる手順と、
スレッドに割り当てた領域と当該スレッドとの対応付け情報を記憶装置に記憶する手順と、
スレッドが生成するオブジェクトを、上記記憶装置で記憶した対応付け情報を参照して、当該スレッドに割り当てた領域に配置する手順と
を有することを特徴とするメモリ配置方法。A memory allocation method of an object generated by a plurality of threads when a process is executed in a computer,
A procedure for allocating a heap area for the above process in units of threads,
Storing in a storage device association information between an area allocated to a thread and the thread;
Allocating an object generated by a thread to an area allocated to the thread with reference to the association information stored in the storage device.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002238938A JP2004078636A (en) | 2002-08-20 | 2002-08-20 | Memory management system, memory arranging method and its program and recording medium |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002238938A JP2004078636A (en) | 2002-08-20 | 2002-08-20 | Memory management system, memory arranging method and its program and recording medium |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004078636A true JP2004078636A (en) | 2004-03-11 |
Family
ID=32022182
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002238938A Pending JP2004078636A (en) | 2002-08-20 | 2002-08-20 | Memory management system, memory arranging method and its program and recording medium |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004078636A (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2022540972A (en) * | 2019-05-31 | 2022-09-21 | インテル・コーポレーション | Avoiding Garbage Collection in High Performance Memory Management Systems |
CN117390057A (en) * | 2023-12-11 | 2024-01-12 | 成都智达万应科技有限公司 | Map data query method and system |
-
2002
- 2002-08-20 JP JP2002238938A patent/JP2004078636A/en active Pending
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2022540972A (en) * | 2019-05-31 | 2022-09-21 | インテル・コーポレーション | Avoiding Garbage Collection in High Performance Memory Management Systems |
CN117390057A (en) * | 2023-12-11 | 2024-01-12 | 成都智达万应科技有限公司 | Map data query method and system |
CN117390057B (en) * | 2023-12-11 | 2024-03-19 | 成都智达万应科技有限公司 | Map data query method and system |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5038907B2 (en) | Method and apparatus for supporting address translation in a virtual machine environment | |
KR100996753B1 (en) | Method for managing sequencer address, mapping manager and multi-sequencer multithreading system | |
US5899994A (en) | Flexible translation storage buffers for virtual address translation | |
US6467007B1 (en) | Processor reset generated via memory access interrupt | |
US4730249A (en) | Method to operate on large segments of data in a virtual memory data processing system | |
US5852738A (en) | Method and apparatus for dynamically controlling address space allocation | |
JP6764485B2 (en) | Page fault solution | |
US9280486B2 (en) | Managing memory pages based on free page hints | |
Kim et al. | XHive: Efficient cooperative caching for virtual machines | |
EP2581828B1 (en) | Method for creating virtual machine, virtual machine monitor and virtual machine system | |
US20070208954A1 (en) | Method and system for designating and handling confidential memory allocations | |
US8151076B2 (en) | Mapping memory segments in a translation lookaside buffer | |
JP2007122305A (en) | Virtual machine system | |
JP2007233615A (en) | Address conversion device | |
US8751724B2 (en) | Dynamic memory reconfiguration to delay performance overhead | |
JP5531476B2 (en) | Information processing apparatus and information processing program | |
CN112596913B (en) | Method and device for improving performance of transparent large page of memory, user equipment and storage medium | |
WO2023165308A1 (en) | Memory reclaim method and apparatus, and control device | |
US9081764B2 (en) | Iimplementing DMA migration of large system memory areas | |
JP7132491B2 (en) | MEMORY CONTROL DEVICE, MEMORY CONTROL PROGRAM AND MEMORY CONTROL METHOD | |
US7444636B2 (en) | Method and system of determining attributes of a functional unit in a multiple processor computer system | |
JP2004078636A (en) | Memory management system, memory arranging method and its program and recording medium | |
JP4664586B2 (en) | Cache control device, cache control method, and computer system | |
US6918023B2 (en) | Method, system, and computer program product for invalidating pretranslations for dynamic memory removal | |
JP4792065B2 (en) | Data storage method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040707 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060414 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060804 |