JP4511653B2 - マルチスレッド仮想マシン内におけるメモリ・アロケーションの方法及び装置 - Google Patents

マルチスレッド仮想マシン内におけるメモリ・アロケーションの方法及び装置 Download PDF

Info

Publication number
JP4511653B2
JP4511653B2 JP18601599A JP18601599A JP4511653B2 JP 4511653 B2 JP4511653 B2 JP 4511653B2 JP 18601599 A JP18601599 A JP 18601599A JP 18601599 A JP18601599 A JP 18601599A JP 4511653 B2 JP4511653 B2 JP 4511653B2
Authority
JP
Japan
Prior art keywords
block
thread
blocks
allocating
allocate
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 - Lifetime
Application number
JP18601599A
Other languages
English (en)
Other versions
JP2000222281A (ja
JP2000222281A5 (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.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
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 Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of JP2000222281A publication Critical patent/JP2000222281A/ja
Publication of JP2000222281A5 publication Critical patent/JP2000222281A5/ja
Application granted granted Critical
Publication of JP4511653B2 publication Critical patent/JP4511653B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • 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/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0842Multiuser, multiprocessor or multiprocessing cache systems for multiprocessing or multitasking
    • 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
    • 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • G06F9/4862Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration the task being a mobile agent, i.e. specifically designed to migrate

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Memory System (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Image Input (AREA)

Description

【0001】
【発明の属する技術分野】
一般的に、本発明はコンピュータ・システム内におけるメモリ・アロケーションに関する。より詳細には、本発明はオブジェクトベースのマルチスレッド・コンピュータ・システム内における効率的な低オーバーヘッド・メモリ・アロケーションに関する。
【0002】
【従来の技術】
コンピュータ技術分野での仮想マシンの利用が増大することにより、仮想マシンの全体効率の改善が更に重要になってきた。一般的に、仮想マシンを有するコンピュータ・システムに関連するメモリの量は限られている。この場合、メモリを節約し、かつリサイクルする必要が一般的にある。多くのコンピュータ・プログラミング言語は、ソフトウェア開発者がコンピュータ・システム内のメモリを動的にアロケートすることを可能にするが、他のプログラミング言語は、以前にアロケートしたメモリの明示的マニュアル・デアロケーションを必要とする。そして、このデアロケーションは複雑であって、エラーを起こし易い。明示的マニュアル・メモリ管理を必要とする言語はC及びC++プログラミング言語を含む。メモリをリクラメーション・システムからアロケートするコンピュータ・プログラムの適切なオペレーションを保証すべく、必要のないメモリをリクレームするために、他のプログラミング言語はオートマチック・ストレージ・リクラメーションを使用している。このようなオートマチック・ストレージ・リクラメーション・システムは、メモリを以前使用していたコンピュータ・プログラムからの明示的命令、即ち、呼び出しを受けることなく、そのメモリをリクレームする。
【0003】
オブジェクト指向システム、即ち、オブジェクト・ベースのシステムでは、当業者が理解するように、メモリ・アロケーションの一般的なユニットはオブジェクトまたはメモリ・オブジェクトと一般的に称される。使用中のオブジェクトは“ライブ”オブジェクトと一般的に称され、コンピュータ・プログラムを正しく実行するために必要なくなったオブジェクトは“ガーベッジ”オブジェクトと一般的に称される。ガーベッジ・オブジェクトをリクレームする行為はガーベッジ・コレクションと一般的に称される。そして、オートマチック・ストレージ・リクラメーション・システムはガーベッジ・コレクタと称されることが多い。ジャバ(Java、商標)プログラミング言語(サンマイクロシステムズ・インコーポレイテッドが開発)及びスモールトーク・プログラミング言語などの言語で書かれたコンピュータ・プログラムは、メモリを自動的に管理するためにガーベッジ・コレクションを使用する。
【0004】
一般的に、コンパクティング・ガーベッジ・コレクタの使用は、オブジェクトを比較的迅速にアロケートすることを可能にする。即ち、コンパクティング・ガーベッジ・コレクタを使用する1つの効果としては、オブジェクトの高速アロケーションが挙げられる。オブジェクトは連続メモリ領域(例:アロケーション領域)内でアロケートできる。この結果、アロケーション・ポインタを所望の記憶量だけインクリメントすることによって、オブジェクトのアロケーションを実行可能である。アロケーション領域の末端へ到達した際、ガーベッジ・コレクションを実施し得る。
【0005】
ガーベッジ・コレクションの1つの方法としては、世代別ガーベッジ・コレクションが挙げられる。世代別ガーベッジ・コレクションでは、オブジェクトを形成した時点からのオブジェクトの寿命に基づいて、オブジェクトを分離する。“若い方”のオブジェクトは“古い方”のオブジェクトよりガーベッジになりやすいことが確認されている。この場合、世代別ガーベッジ・コレクションはメモリ・リクラメーションの全体効率を高めるために使用される。
【0006】
世代別ガーベッジ・コレクションを使用するシステムでは、新たなオブジェクトのアロケーションを行うための特別なメモリ領域が指定されている。新たなオブジェクトをこのメモリ領域内でアロケートするため、一般的に、このメモリ領域は“育成場所(nursery)”と見なされている。当業者が理解するように、多くの場合、このメモリ領域は“エデン(Eden)”と称される。
【0007】
図1は単一のスレッドと、このスレッド専用のメモリ・アロケーション領域とを示す図である。このメモリ・アロケーション領域は、世代別ガーベッジ・コレクションを使用するシングル・スレッド・システム内でのインプリメンテーションに適する。図示するように、エデンとして知られるメモリ・アロケーション領域102は、アロケーション・ポインタ104によって索引付けされる。一般的に、エデン102は新たなオブジェクトをその中で形成できるメモリのブロックである。エデン102に関連付けられたスレッド106が新たなオブジェクトをアロケートすることを試みた際、一般的に、アロケーション・ポインタ104を新たなオブジェクトのサイズだけインクリメントする。次いで、アロケーション・ポインタ104がエデン102の末端へ到達したか否かを決定するためのチェックを行う。エデン102の末端に到達したことが確定した際、エデン102を事実上空にするために、世代別ガーベッジ・コレクションを実施し、これによって、スレッド106によるエデン102内での新たなオブジェクトの形成を可能にする。
【0008】
図1に基づいて詳述したメモリ及び新たなオブジェクトのアロケーションはシングル・スレッド・システム内では効果的である。しかし、一般的に、このメモリ及びオブジェクトのアロケーションは複数の中央処理装置(CPU)を有するマルチスレッド・システム内では使用できない。例えば、2つのスレッドが単一のエデン内のスペースをリクエストすることを並行して試みた際、並行性の問題が生じ得る。この場合、マルチスレッド・システムでは、エデンが共有リソースである際、任意の時点における複数のスレッドによるエデン内でのアロケーティングを防止するために、エデンへのアクセスは同期を一般的に必要とする。エデンへのアクセスの同期化は、エデンへのアロケーション・ロックの関連付けを含む。スレッドが新たなオブジェクトの形成を望む際、このスレッドはアロケーション・ロックを獲得する。そして、新たなオブジェクトを形成した後、このスレッドはアロケーション・ロックを解除する。
【0009】
図2は2つのスレッドと、これら2つのスレッドがマルチスレッド・システム内で共有するメモリ・アロケーション領域とを示す図である。エデン112の未使用部分115の開始位置を表示するために設けられた関連するアロケーション・ポインタ114をエデン112は有する。エデン112を共有する2つのスレッド116,118が新たなオブジェクトをエデン112内でアロケートすることを望む際、これらのスレッド116,118はエデン112に関連付けられたアロケーション・ロック(図示略)を獲得する必要がある。具体的には、スレッド116が未使用部分115へのアクセスを望む際、このスレッド116はアロケーション・ロックをエデン112上で獲得する必要がある。スレッド116がアロケーション・ロックを獲得し、かつアロケーション・ポインタ114がエデン112の末端へ到達していないことが確定した後、スレッド116はアロケーション・ポインタ114をインクリメントし、かつ新たなオブジェクトをアロケートし得る。アロケーション・ポインタ114がエデン112の末端まで達した場合、即ち、未使用部分115がヌルの際、エデン112を事実上空にし、これによってスレッド116,118による新たなオブジェクトの形成を可能にするために、ガーベッジ・コレクションを実施する。
【0010】
エデンへのアクセスを同期化した際、エデンに関連付けられたアロケーション・ロックの獲得及び解除に関連するオーバーヘッドに起因して、エデン内における新たなオブジェクトのアロケーションは一般的に大幅に遅くなる。スレッドが新たなオブジェクトをエデン内で形成することを望む毎に、このスレッドはエデンに対する独占権を獲得する必要がある(例えば、アロケーション・ロックの獲得によって)。一般的に、ハードウェアが直接インプリメントする“高速”ロッキング・プリミティブ(例:コンペア・アンド・スワップ・プリミティブ)と称されるプリミティブであっても、アロケーションに関連するベース・コストと比べた際、アロケーションの速度は相対的に遅い。例えば、マルチプロセッサ・システムでは、当業者が理解するように、ロッキング・プリミティブはリモート・キャッシュ・ミスを招来し得る。このシステムでは、多くの場合、同期機能の追加はアロケーションのコストを大幅(例:2倍または3倍)に増大する。したがって、アロケーション中における同期の追加は総合システムのパフォーマンスに大きく影響する。
【0011】
マルチスレッド・システム内におけるエデンへのアクセスに関連するパフォーマンスを同期を使用せずに改善するために、独自のエデンをマルチスレッド・システム内の各スレッドへ割り当てる。即ち、各スレッドが独自のエデンを有する際、複数のスレッドが共有エデンへのアクセスを試みた際に生じる並行性の問題を防止できる。図3は2つのスレッドと、これら2つのスレッドの独自のエデン、即ち、メモリ・アロケーション領域とを示す図である。マルチスレッド・システム200内において、アロケーション・ポインタ204が参照する第1エデン202は第1スレッド206に関連付けられている。マルチスレッド・システム200は第2エデン212を有する。第2エデン212はアロケーション・ポインタ204によって参照され、かつ第2スレッド216に関連付けられている。
【0012】
第1スレッド206が新たなオブジェクトのアロケーションを望む際、この第1スレッド206は第1エデン202へアクセスする。同様に、第2スレッド216が新たなオブジェクトのアロケーションを望む際、この第2スレッド216は第2エデン212へアクセスする。各スレッド206,216が独自の専用エデン、即ち、エデン202,212を有することにより、新たなオブジェクトを形成するために、2つのスレッドが単一エデンへのアクセスを任意の時点でそれぞれ試みることを防止するアロケーション・ロックは必要なくなる。
【0013】
独立したエデンをマルチスレッド・システム内の各スレッドへアロケートすることによって、アロケーション・ロックの必要性を排除できる。しかし、多くの場合、独立したエデンのアロケーティングは多くのメモリを必要とする。例えば、幾つかのアプリケーションは数百または数千のスレッドを含む。更に、幾つかのスレッドは他のスレッドより更に速くオブジェクトをアロケートし、これによって、更に多くのメモリを必要とし得る。更に多くのメモリの必要性は、ある種の同期を必要とするメモリ全体に対する頻繁なガーベッジ・コレクション(例:全てのエデン上で実施するグローバル・ガーベッジ・コレクション)を引き起こし得る。この場合、幾つかのエデンが依然かなり空いているのに対し、他のエデンはその能力一杯まで満たされているため、複数のエデン上でのガーベッジ・コレクションの実施に関連する全体的なオーバーヘッドは増大し、かつ総合システムのパフォーマンスに悪影響を及ぼし得る。
【0014】
マルチスレッド・システム内において、独立したエデンを複数のスレッドへそれぞれアロケートすることに関連する多くのメモリの使用と、ガーベッジ・コレクションに関連する全体的なオーバーヘッドの増大とは非効率的であり、かつ大きな費用を必要とする。使用するメモリの量と、ガーベッジ・コレクションの頻度とを低減することは、効率を高め、かつマルチスレッド・システムに関連するコストを一般的に低減する。一般的に、1つのエデンを複数のチャンク、即ち、ブロックへ分割することにより、アロケーション・ロックを要することなくエデンを共有できる。図4は2つのスレッドと、これら2つのスレッドが共有するメモリ・アロケーション領域とを示す図であり、このメモリ・アロケーション領域は複数のチャンクへ分割されている。マルチスレッド・システム230はエデン232を有し、エデン232は一定のサイズを有する複数のチャンク233へ分割されている。換言するならば、全てのチャンク233はほぼ同じサイズである。先頭チャンクをエデン232を共有する各スレッド236,238へアロケートする。例えば、チャンク233aをスレッド236へ最初にアロケートし、チャンク233bをスレッド238へ最初にアロケートする。
【0015】
スレッド(例:スレッド236)がチャンク233aを満たした際、別のチャンク233cをスレッド236へアロケートする。利用可能な全てのチャンク233が枯渇するまでチャンク233をスレッドへアロケートする。そして、利用可能な全てのチャンク233が無くなった際、ガーベッジ・コレクションを実施する。チャンク233に関するリクエストは同期しているが、この同期は前記のアロケーション同期ほど頻繁に行われないことを理解する必要がある。
【0016】
各チャンク233は大型オブジェクトを保持できるサイズに形成する必要がある。このため、スレッド236,238へのチャンク233のアロケーションは実質的な断片化を招来することが多い。したがって、チャンクが部分的に満たされ、スレッドが形成した大型オブジェクトが、この部分的に満たされたチャンクに収まらなくなった際、大型オブジェクトを収容するために、新たなチャンクをスレッドへアロケートする。部分的に満たされたチャンク内に残されたスペースは事実上無駄になる。更に、低速アロケーティング・スレッドが実質的に空のチャンクを占有し、これによって、不必要なメモリ・スペースをリザーブした際、チャンク内のスペースのアロケーションは非効率的になる。
【0017】
したがって、マルチスレッド・仮想マシンなどのマルチスレッド・システム内のメモリを効率的にアロケートするための方法及び装置が望まれる。具体的には、メモリ・スペースを最小限に抑制し、アロケーション・コストを最小限に抑制し、さらにはガーベッジ・コレクションの効率を改善する一方で、スレッドが新たなオブジェクトをメモリ・アロケーション領域(例:エデン)内で形成することを可能にする方法及び装置が必要である。
【0018】
【発明の概要】
本発明はマルチスレッド・コンピュータ・システムにおける共有メモリの効率的なアロケーションに関する。本発明の1つの実施形態に基づき、マルチスレッド・コンピューティング・システム内の複数のスレッドが共有しているメモリをアロケートすべく、コンピュータに実装する方法は、共有メモリを複数のブロックへ分割する工程と、複数のスレッドを少なくとも第1グループ及び第2グループへグループ分けする工程とを含む。選択したブロックを選択したスレッドへアロケートする。この選択したスレッドは、オブジェクトを選択したブロック内でアロケートすることを試み得る。選択したスレッドへの選択したブロックのアロケーションは、選択したスレッドが第1グループ及び第2グループのうちのいずれの一部であるかということに少なくとも部分的に基づいて実施される。1つの実施形態では、複数のスレッドを第1グループ及び第2グループへグループ分けする工程は、特定のスレッドを識別する工程と、この特定のスレッドが高速アロケーティング・スレッドであるか否かを決定する工程とを含む。
【0019】
本発明の別の態様に基づき、第1スレッド及び第2スレッドを少なくとも有するマルチスレッド・コンピューティング・システム内の共有メモリをアロケートすべく、コンピュータに実装する方法は、共有メモリを複数のブロックへ分割する工程と、新たなオブジェクトを形成するために、第1スレッド及び第2スレッドの両方がアクセスできる第1ブロックを割り当てる工程とを含む。システムの実行を許可した後、第1ブロックがオーバーフローしたか否かを事実上決定する。第1ブロックがオーバーフローしたことが確定した場合、第1オブジェクトを第1ブロック内でアロケートする第1スレッドの試みが、第1ブロックのオーバーフローを引き起こしたか否かを決定する工程を、この方法は含む。前記の第1スレッドの試みが第1ブロックのオーバーフローを引き起こしたことが確定した場合、第2ブロックを第1スレッドへ割り当てる。第1スレッドへの第2ブロックの割り当てにより、オブジェクトを第1ブロック内でアロケートする能力を第1スレッドは事実上放棄する。
【0020】
本発明の更に別の態様では、マルチスレッド・コンピューティング・システム内のメモリをアロケートすべくコンピュータに実装する方法は、メモリを複数のブロックへ分割する工程を含み、前記の複数のブロックは第1ブロックと、第1ブロックより実質的に大きい第2ブロックとを含む。第1ブロックは第1スレッドがアクセスできるように割り当てられており、第1スレッドは第1オブジェクトを第1ブロック内でアロケートすることを試みるべく設けられている。更に、第2スレッドが第2オブジェクトを第1ブロック内でアロケートすることを試みるために、第2ブロックは第2スレッドがアクセスできるように割り当てられている。
【0021】
以下の詳細な説明を読み、かつ複数の図面を研究することにより、本発明を更に容易に理解できる。
【0022】
【発明の実施の形態】
多くの場合、マルチスレッド・システム内の共有メモリ(例:“エデン”)のアロケーティングに関連するオーバーヘッドは大きい。独立したエデンをマルチスレッド・システム内の各スレッドへアロケートすることにより、同期に関連するアロケーション・ロックの必要は無くなる。しかし、多くの場合、独立したエデンのアロケーティングは多くのメモリを必要とし、かつ更に頻繁なガーベッジ・コレクションを引き起こし、これによって、総合システムのパフォーマンスに潜在的に悪影響を及ぼす。
【0023】
複数のスレッドが共有するエデンを均等な複数のチャンク、即ち、ブロックへ分割し、これによって、各スレッドは独自のブロックを持つことができる。各スレッドによる独自のブロックの保有を可能にすることにより、アロケーション・ロックを要することなく、エデンを共有できる。しかし、エデンを均等な複数のチャンクへ分割し、各スレッドによる独自のブロックの保有を可能にすることにより、大きな断片化を生じることが多い。例えば、チャンクが部分的に満たされていて、スレッドが形成した大型オブジェクトが、この部分的に満たされたチャンクに収まらない際、大型オブジェクトを収容するために、新たなチャンクをスレッドへアロケートする。そして、部分的に満たされたチャンク内に残されたスペースは事実上無駄になる。更に、オブジェクトを希にアロケートするスレッドが実質的に空のチャンクを占有し、これによって、不必要なメモリ・スペースをリザーブした際、チャンク内のスペースのアロケーションは非効率的になる。スレッドが不必要なメモリ・スペースをリザーブした際、このメモリ・スペースはメモリ・スペースを必要とするスレッドから事実上奪い去られる。更に、追加メモリ・スペースを必要とするスレッドによるメモリの使用を可能にすべくメモリを解放するために、大きなオーバーヘッドをともなう更に頻繁なガーベッジ・コレクションが生じる。
【0024】
オブジェクトを希にアロケートする複数のスレッドが、共有メモリ・アロケーション領域のチャンク、即ち、ブロックを共有することを可能にする。その一方で、“プライベート”メモリ・ブロック、即ち、非共有メモリ・ブロックを、オブジェクトを頻繁にアロケートするスレッドへ提供する。これにより、更に多くのメモリ・スペースを、より多くのメモリを必要とするスレッドにだけ効果的に提供する。この結果、ガーベッジ・コレクションの実施前に、更に多くのメモリ・スペースが満たされる。更に、ガーベッジ・コレクションの頻度も減少する。低速アロケーティング・スレッド(例:オブジェクトを希にアロケートするスレッド)が共有ブロックへアクセスする際、同期を使用する。しかし、多くの場合、低速アロケーティング・スレッドは共有メモリへ頻繁にアクセスする必要がない、即ち、共有メモリ内で頻繁にアロケートする必要がないため、同期コストは比較的低い。この場合、同期に関連するオーバーヘッドは比較的小さいと考えられる。
【0025】
共有メモリ領域内における新たなオブジェクトのアロケーションでの同期を省くために、複数の異なるサイズのブロックを共有メモリ領域内で形成し、これによって、プライベート・ブロックを全てのスレッドへそれぞれ割り当てる。具体的には、小さい方のプライベート・ブロックを潜在的な低速アロケーティング・スレッドへ割り当て、大きい方の非共有ブロックを潜在的な高速アロケーティング・スレッドへ割り当てる。小さい方のブロックを低速アロケーティング・スレッドへ割り当て、大きい方のブロックを高速アロケーティング・スレッドへ割り当てることにより、僅かなメモリを必要とするスレッドへ提供するメモリ・スペースより更に多くのメモリ・スペースを、多くのメモリを必要とするスレッドへ提供する。これは共有メモリ内の新たなオブジェクトのアロケーションに関連する同期オーバーヘッドをともなうことなく行われる。
【0026】
実質的に同じサイズの複数のブロックへの共有メモリ領域の分割と、これら同じサイズのブロックのアロケーションに使用する方法とを、図5〜図10に基づいて以下に詳述する。前記のように、本発明の1つの実施形態では、複数のスレッドがメモリのブロックを共有し、プライベート・メモリ・ブロックをこれら以外のスレッドへ割り当てる。図5は本発明の第1実施形態に基づく複数のスレッドと、これら複数のスレッドが共有するメモリ・アロケーション領域とを示す図である。総合システム300は共有メモリ・アロケーション領域302を有する。1つの実施形態では、メモリ・アロケーション領域302はエデンである。しかし、一般的に、メモリ・アロケーション領域302は、新たなオブジェクトをその中でアロケートできる任意の共有メモリであり得ることを理解する必要がある。
【0027】
メモリ・アロケーション領域302はほぼ同じサイズの複数のブロック304、即ち、チャンクへ分割されている。一般的に、ブロック304のサイズはシステム300の要件に基づいて広範に変化し得る。例えば、システム300が、関連するジャバ(商標)仮想マシン(サンマイクロシステムズ・インコーポレイテッドが開発)を有する場合、複数のブロック304はそれぞれ約2キロバイト(kB)から約32kBの間のサイズである。メモリ・アロケーション領域302の全体サイズは広範に変化し得ることを理解することが必要である一方、このシステムでは、メモリ・アロケーション領域302は約128kBから約512kBの範囲のサイズである。
【0028】
システム300内では、全ての高速アロケーティング・スレッド、即ち、大量のオブジェクトをメモリ・アロケーション領域302内でアロケートする全てのスレッド306は、独自の指定ブロック304を最終的に割り当てられる。本実施形態では、スレッド306a,306dは高速アロケーティング・スレッドの候補であり、したがって、各スレッド306a,306dはプライベート・ブロックへ関連付けられている。図6、図7、図9及び図10に関連して以下に詳述するように、高速アロケーティング・スレッドと考えられるスレッド306は、共有ブロックをオーバーフローさせる(例:メモリ・スペースを使い尽くす)スレッド306である。一般的に、スレッド306a,306dが自身の指定ブロック(例:プライベート・ブロック)304をオーバーフローさせた際、追加ブロック304の利用が可能な限り、この追加ブロック304をスレッド306a,306dへ割り当てる。図示するように、スレッド306aは3つのブロック304b,304d,304fを割り当てられており、このうちのブロック304b,304dは満杯である。スレッド306dは2つのブロック304e,304fを割り当てられており、このうちのブロック304eは満杯であり、ブロック304fは部分的に満たされている。スレッド306aは独自のプライベート・ブロック304b,340d,304fを有するため、スレッド306aが新たなオブジェクトを自分の複数のブロックのうちの1つへアロケートすることを試みる際、同期は必要ない。同様に、スレッド306dが新たなオブジェクトを自身の複数のブロックのうちの1つへアロケートすることを試みる際、スレッド306dはアロケーション・ロックまたはこれに類するデバイスを獲得する必要がない。
【0029】
高速アロケーティング・スレッドと考えられないスレッド306(例:スレッド306b,306c)は共有ブロック(例:ブロック304c)を割り当てられる。スレッド306b,306cは共有ブロック304cを割り当てられ、これによって、これら2つのスレッド306b,306cは新たなオブジェクトをブロック304c内でアロケートする。スレッド306b,306cがブロック304cへほぼ同時にアクセスする際、並行性の問題を防止するために、同期が一般的に使用される。しかし、スレッド306b,306cは低速アロケーティング・スレッドと考えられるため、同期に関連するオーバーヘッドは一般的に小さい。即ち、スレッド306b,306cは新たなオブジェクトをブロック304c内でアロケートすることを稀に試みることが予期される。
【0030】
共有可能な複数のブロックへ分割された共有メモリをアロケートする方法は様々であるが、このうちの幾つかの適切な方法を図6、図7、図8、図9及び図10に基づいて以下に詳述する。図6では、本発明の第1実施形態に基づいて、複数のスレッドによって共有されるメモリをアロケートする第1の方法に関連する複数のステップを示す。即ち、図6は図5に基づいて詳述したように共有メモリ・システム内のメモリをアロケートする1つの方法に関連している。この方法では、共有メモリ・ブロックのオーバーフローを引き起こすスレッドは、高速アロケーティング・スレッドである可能性が統計学的に高いため、共有メモリ・ブロックがオーバーフローした全ての時点で、独自のメモリ・ブロックを、共有メモリ・ブロックのオーバーフローを引き起こしたスレッドへアロケートする。
【0031】
メモリをアロケートする第1の方法はステップ402から始まる。ステップ402では、複数のメモリ・ブロックを共有メモリ・アロケーション領域(例:エデン)内でアロケートすることによって、共有メモリ・アロケーション領域を構築する。本実施形態では、アロケート、分割、または形成される複数のメモリ・ブロックは実質的に同じサイズである。このサイズは個々のシステムの要件に基づいて広範に変化し得る。しかし、一般的には、このサイズは約2kBから約32kBの範囲である。
【0032】
アロケーション領域内のメモリをアロケートした後、ステップ404では、新たなオブジェクトをアロケーション領域内でアロケートすることを試みる全てのスレッドのための共有ブロックとして、アロケーション領域内の第1ブロックを割り当てる。全てのスレッドのための共有ブロックを割り当てることにより、これらのスレッドのうちの1つが新たなオブジェクトをアロケートする毎に、この新たなオブジェクトを共有ブロック内でアロケートすることが試みられる。多くの場合、複数のスレッドがブロックを共有する際、アロケーション・ロックまたはこれに類するデバイスが、オブジェクト・アロケーション中における同期目的で使用されることを理解する必要がある。
【0033】
共有ブロックを割り当てた後、総合システムをステップ406で実行する。換言するならば、スレッドに関連するコンピューティング・システムの実行を許可する。一般的に、前記の複数のスレッドのうちの1つがアロケーション領域内のブロック(例:共有ブロック)のオーバーフローを発見するまで、総合システムの実行を許可する。この場合、ブロックがオーバーフローしたか否かはステップ408で決定される。
【0034】
共有ブロックなどのブロックがオーバーフローしたことがステップ408で確定するまで、ステップ406におけるシステムの実行の継続を許可する。ブロックがオーバーフローしたことが確定した際、プロセスの流れはステップ410へ移行する。ステップ410では、利用可能な次のブロックをアロケーション領域から獲得することが試みられる。ステップ412では、新たなブロックが利用可能であるか否かを決定する。即ち、利用可能な“フリー”メモリ・ブロックがアロケーション領域内にあるか否かを決定する。新たなブロックが利用可能である際、この新たなブロックを、システムの実行中にブロックのオーバーフローを引き起こしたスレッドへステップ414で割り当てる。当初は、即ち、プライベート・ブロックがスレッドへ割り当てられるまでは、前記の新たなブロックは共有ブロックのオーバーフローを引き起こしたスレッドへ割り当てられることを理解する必要がある。但し、プライベート・ブロックをスレッドへ割り当てた後では、このプライベート・ブロックまたは前記の共有ブロックがオーバーフローしていることになるため、新たなブロックはプライベート・ブロックを有するスレッドと、共有ブロックを共有している複数のスレッドとのいずれかへ割り当てられる。
【0035】
一般的に、スレッドがプライベート・アロケーション・ブロック及び共有アロケーション・ブロックのうちのいずれを有するかに基づいて、このスレッドは2つのアロケーション・ルーチンのうちの1つを使用する。当業者が理解するように、プライベート・ブロックを有するスレッドはロッキング・オーバーヘッドを減らすためにノンロッキング高速アロケーション・ルーチンを使用し、共有ブロックを有するスレッドはロッキング低速アロケーション・ルーチンを使用する。したがって、スレッドがプライベート・ブロックを割り当てられた際、そのアロケーション・ルーチンはノンロッキング・ルーチンに一般的に設定される。逆に、スレッドがプライベート・ブロックを割り当てられた際、そのアロケーション・ルーチンはロッキング・ルーチンに一般的に設定される。
【0036】
一般的に、共有ブロックのオーバーフローを引き起こすスレッドは、オブジェクトを比較的頻繁にアロケートする傾向にあるスレッドであることが予期される。この場合、プライベート・ブロックをこのスレッドへ割り当てることにより、共有ブロック上におけるアロケーション・ロックの獲得及び解除に関連するオーバーヘッドが減少する。新たなオブジェクトを頻繁にアロケートするスレッドは、アロケーション・ロックを使用しないプライベート・ブロックを一般的に割り当てられるため、このオーバーヘッドは一般的に減少する。多くの場合、共有ブロックを共有し続けるスレッドは新たなオブジェクトを希にアロケートするスレッドであるため、共有ブロックに関連するアロケーション・ロックの獲得及び解除に関連するオーバーヘッドは一般的に比較的小さい。
【0037】
新たなブロックを、ブロックのオーバーフローを引き起こしたスレッドへステップ414で割り当てた後、オーバーフローしたブロックが共有ブロックであるか否かをステップ417で決定する。一般的に、スレッドがプライベート・ブロックを獲得した後では、ステップ408でオーバーフローの確定したブロックは、プライベート・ブロックまたは共有ブロックである。しかし、あらゆるプライベート・ブロックの割り当て前の段階では、オーバーフローしたブロックは共有ブロックである。
【0038】
オーバーフローしたブロックが共有ブロックでないことが確定した際、これはオーバーフローしたブロックがプライベート・ブロックであることを意味する。オーバーフローしたブロックがプライベート・ブロックである場合、プロセスの流れはステップ417からステップ406へ移行し、スレッドがブロックのオーバーフローを発見するまで、総合システムの実行を許可する。これに代えて、オーバーフローしたブロックが共有ブロックであることがステップ417で確定した場合、利用可能な別の新たなブロックがアロケーション領域内に存在するか否かをステップ418で決定する。
【0039】
利用可能な別のブロックがアロケーション領域内に存在することがステップ418で確定した場合、ステップ420において、満杯の共有ブロックを新たなブロックと置換する。満杯の共有ブロックを置換した後、ステップ406における総合システムの実行を許可する。しかし、利用可能なブロックがアロケーション領域内に事実上存在しないことが確定した場合、プロセスの流れはステップ406へ移行し、システムの実行を許可する。ブロック(例:共有ブロックまたはプライベート・ブロック)がオーバーフローするまで、満杯またはほぼ満杯の共有ブロックを有するシステムの実行を継続させることを理解する必要がある。
【0040】
再びステップ412へ戻り、利用可能な新たなブロックが存在しないことが確定した際、ガーベッジ・コレクションをステップ416で実施する。実質的に任意のガーベッジ・コレクション・アルゴリズムを使用し得る。しかし、1つの実施形態では、世代別ガーベッジ・コレクション・アルゴリズムを使用する。一般的に、アロケーション領域のブロックに格納されたライブ・オブジェクトをコピーし、これによって、少なくとも幾つかのブロックを新たなアロケーションのために空にするために、世代別ガーベッジ・コレクション・アルゴリズム、即ち、世代別ガーベッジ・コレクタは設けられている。ガーベッジ・コレクションをステップ416で実施した後、プロセスの流れはステップ404へ戻り、アロケーション領域内の第1ブロックを全てのスレッドのための共有ブロックとして割り当てる。
【0041】
図7は本発明の第1実施形態に基づくメモリをアロケートする第2のプロセスに関連する複数のステップを示すフローチャートであり、この第2のプロセスは特定のスレッドが高速アロケーティング・スレッドであるか否かの決定を可能にする。このメモリをアロケートする第2の方法はステップ432から始まる。ステップ432では、複数のメモリ・ブロックを共有メモリ・アロケーション領域(例:エデン)内でアロケートすることによって、共有メモリ・アロケーション領域を構築する。アロケーション領域内のメモリを複数のブロックへ実質的に分割した後、ステップ434では、新たなオブジェクトをアロケーション領域内でアロケートすることを試みる全てのスレッドのための共有ブロックとして、アロケーション領域内の第1ブロックを割り当てる。全てのスレッドのための共有ブロックを割り当てることにより、これらのスレッドのうちの1つが新たなオブジェクトをアロケートする毎に、この新たなオブジェクトを共有ブロック内でアロケートすることが試みられる。
【0042】
共有ブロックを割り当てた後、総合システムをステップ436で実行する。一般的に、前記の複数のスレッドのうちの1つがアロケーション領域内のブロックのオーバーフローを発見するまで、総合システムの実行を許可する。事実上、この発見はブロックがオーバーフローしたことの確定である。したがって、ブロックがオーバーフローしたか否かをステップ438で決定する。
【0043】
共有ブロックなどのブロックがオーバーフローしていないことがステップ438で確定した場合、ステップ436におけるシステムの実行の継続を許可する。これに代えて、ブロックがオーバーフローしていることが確定した場合、プロセスの流れはステップ440へ移行する。ステップ440では、利用可能な次のブロックをアロケーション領域から獲得することが試みられる。利用可能な次のブロックの獲得を試みた後、ステップ442において、新たなブロックが利用可能であるか否かを決定する。即ち、事実上未使用の利用可能なメモリ・ブロックがアロケーション領域内に存在するか否かを決定する。
【0044】
利用可能な新たなブロックが存在しないことが確定した際、ステップ456において、ガーベッジ・コレクションを実施する。1つの実施形態では、ガーベッジ・コレクションは世代別ガーベッジ・コレクション・アルゴリズムを含む。図6に関連して詳述したように、アロケーション領域のブロックに格納されたライブ・オブジェクトをメモリの他の領域へコピーし、これによって、アロケーション領域の少なくとも幾つかのブロックを新たなアロケーションのために空にするために、世代別ガーベッジ・コレクション・アルゴリズムは設けられていることが多い。
【0045】
ガーベッジ・コレクションをステップ456で実施した後、ステップ458において、高速アロケーティング・スレッドと考えられるスレッドを決定する。一般的に、高速アロケーティング・スレッドと考えられるスレッドの決定は、多くの新たなオブジェクトをアロケートするスレッドの決定である。高速アロケーティング・スレッドと考えられるスレッドを決定する1つの方法を図8に基づいて以下に詳述する。
【0046】
高速アロケーティング・スレッドを識別した後、ステップ460において、新たなブロックを、高速アロケーティング・スレッドと考えられる各スレッドへ割り当てる。即ち、各高速アロケーティング・スレッドはプライベート・ブロックを割り当てられる。新たなブロック、即ち、新たなプライベート・ブロックを実質的に高速アロケーティング・スレッドに対してだけ割り当てることにより、プライベート・ブロックを以前保持していたスレッドであって、現在は高速アロケーティング・スレッドと考えられないスレッドは、不必要なメモリ・スペースのリザーブを阻止される。更に、高速アロケーティング・スレッドは高速非同期アロケーションの使用を継続する。
【0047】
新たなブロックを高速アロケーティング・スレッドへ割り当てた後、ステップ462において、共有ブロックを他の全てのスレッドへ割り当てる。即ち、共有ブロックを高速アロケーティング・スレッドと考えられない全てのスレッドへ割り当てる。高速アロケーティング・スレッドと考えられないスレッド、即ち、低速アロケーティング・スレッドと考えられるスレッドは、共有ブロックを割り当てられる。そして、プロセスの流れはステップ436へ戻り、総合システムの実行を許可する。
【0048】
再びステップ442へ戻り、新たなブロックが利用可能である際、ステップ444において、この新たなブロックを、システムの実行中にブロックのオーバーフローを引き起こしたスレッドへ割り当てる。プライベート・ブロックがスレッドへ割り当てられるまでは、新たなブロックは共有ブロックのオーバーフローを引き起こしたスレッドへ割り当てられることを理解する必要がある。このプライベート・ブロックまたは前記の共有ブロックがオーバーフローしていることにより、新たなブロックはプライベート・ブロックを有するスレッド(いずれかのスレッドがプライベート・ブロックを既に割り当てられている場合)と、共有ブロックを共有している複数のスレッドとのいずれかへ割り当てられる。
【0049】
新たなブロックを、ブロックのオーバーフローを引き起こしたスレッドへ割り当てた後、ステップ447において、オーバーフローしたブロックが共有ブロックであるか否かを決定する。一般的に、少なくとも1つのスレッドがプライベート・ブロックを獲得した後では、ステップ438でオーバーフローの確定したブロックは、プライベート・ブロックまたは共有ブロックである。しかし、共有ブロックは全てのスレッドに割り当てられた唯一のブロックであるため、あらゆるプライベート・ブロックの割り当て前の段階では、オーバーフローしたブロックは共有ブロックである。
【0050】
オーバーフローしたブロックが共有ブロックでないことが確定した際、これはオーバーフローしたブロックがプライベート・ブロックであることを意味する。オーバーフローしたブロックがプライベート・ブロックである場合、プロセスの流れはステップ447からステップ436へ戻り、別のブロックがオーバーフローするまで、総合システムの実行を許可する。これに代えて、オーバーフローしたブロックが共有ブロックであることがステップ447で確定した場合、共有するために利用可能な別の新たなブロックがアロケーション領域内に存在するか否かをステップ448で決定する。
【0051】
利用可能な別のブロックがアロケーション領域内に存在することがステップ448で確定した場合、ステップ450において、満杯の共有ブロックを新たなブロックと置換する。満杯の共有ブロックを置換した後、ステップ436における総合システムの実行を許可する。しかし、利用可能なブロックがアロケーション領域内に事実上存在しないことが確定した場合、プロセスの流れはステップ436へ直接移行し、システムの実行を許可する。スレッドが新たなオブジェクトの形成を試み、この新たなオブジェクトの形成を試みたことによって、関連するブロック(例:共有ブロックまたはプライベート・ブロック)がオーバーフローしたことまたはオーバーフローしそうなことを、このスレッドが発見するまで、満杯またはほぼ満杯の共有ブロックを有するシステムが実行を継続することを理解する必要がある。最終的には、プロセスの流れは新たなブロックが利用可能であるか否かの決定(即ち、ステップ442における決定)へ逆戻りする。新たなブロックが利用可能でない場合、前記のように、ガーベッジ・コレクションが一般的に実施される。
【0052】
図8では、本発明の第1実施形態に基づいて、高速アロケーティング・スレッドと考えられるスレッドを決定する1つの方法(即ち、図7のステップ458)を示す。高速アロケーティング・スレッドを決定する方法はステップ504から始まる。ステップ504では、高速アロケーティング・スレッドであるか否かを識別するための“テスト”を受けるスレッドが存在するか否かを事実上決定する。テストを受けるスレッドが存在しない際、スレッドが高速アロケーティング・スレッド及び低速アロケーティング・スレッドのうちのいずれであるかを決定するプロセスは完了する。これに代えて、テストを受けるスレッドが存在する際、ステップ506において、スレッドが共有プール、即ち、共有ブロックを使用しているか否かを決定する。換言するならば、ステップ506では、そのスレッドが共有ブロックに関連付けられたスレッドであるか否かを決定する。
【0053】
スレッドが共有プールを使用していることが確定した場合、これはそのスレッドが低速アロケーティング・スレッドであることを示す。したがって、プロセスの流れはステップ506からステップ512へ移行し、スレッドのアロケーション・ルーチンはロッキングに設定される。即ち、スレッドが新たなオブジェクトをアロケートすることを試みた際、そのスレッドが共有ブロックに関連付けられたロックを獲得するように、そのスレッドのアロケーション・ルーチンは設定される。前記のように、1つのスレッドが共有ブロック内でアロケートしている最中に、別のスレッドがこの共有ブロック内でアロケートすることを、ロックの使用によって防止する。スレッドのアロケーション・ルーチンをステップ512でロッキングに設定した後、プロセスの流れはステップ504へ戻り、処理する別のスレッドが存在するか否かを決定する。
【0054】
これに代えて、ステップ506において、スレッドが共有ブロックを使用していないことが確定した場合、これはそのスレッドが少なくとも1つのプライベート・ブロックを有することを意味する。したがって、そのスレッドは高速アロケーティング・スレッドと考えられる。スレッドが高速アロケーティング・スレッドと考えられる際、プロセスの流れはステップ506からステップ508へ移行する。ステップ508では、スレッドが最後のガーベッジ・コレクション・インターバルでアロケートしたメモリが閾値を越えているか否かを決定する。換言するならば、スレッドが直近のガーベッジ・コレクション以降にアロケートしたメモリの総量が閾値を越えているか否かを決定する。一般的に、閾値の量は総合システムの要件に基づいて広範に変化し得る。例えば、閾値の量は約2メモリ・ブロックから約5メモリ・ブロックの範囲である。
【0055】
スレッドが最後のガーベッジ・コレクション・インターバル内でアロケートしたメモリの総量が閾値を越えていることがステップ508で確定した場合、そのスレッドは高速アロケーティング・スレッドと考えられる。したがって、ステップ510では、ロックを獲得することなく、スレッドが自身に関連するブロック、即ち、プライベート・ブロック内で任意の時点でアロケートできる(これは、他のスレッドがこのブロックへアクセスすることがないことに起因する)ことを示すために、そのスレッドのアロケーション・ルーチンをノンロッキングに設定する。スレッドのアロケーション・ルーチンをノンロッキングに設定した後、プロセスの流れはステップ504へ戻り、他のスレッドを処理するか否かを決定する。
【0056】
スレッドが最後のガーベッジ・コレクション・インターバルでアロケートしたメモリの総量が閾値を越えていないことがステップ508で確定した場合、これはそのスレッドが高速アロケーティング・スレッドでないことを意味する。この場合、スレッドはプライベート・ブロックを保持する必要はなく、ステップ512において、このスレッドのアロケーション・ルーチンをロッキングに設定する。スレッドのアロケーション・ルーチンをロッキングに設定した後、プロセスの流れはステップ504へ戻り、処理する別のスレッドが存在するか否かを決定する。
【0057】
プライベート・ブロックを、共有ブロックのオーバーフローを引き起こしたスレッドへ割り当てることは、低速アロケーティング・スレッドのための共有ブロックを維持し、かつ高速アロケーティング・スレッドがプライベート・ブロックを所有することを可能にする点で一般的に効果的である。しかし、その一方で、プライベート・ブロックを低速アロケーティング・スレッドへアロケートする可能性は依然存在する。例えば、オブジェクトを希にアロケートするスレッドが、共有ブロックのオーバーフローを引き起こすオブジェクトを偶然アロケートした場合、プライベート・ブロックがこのスレッドへアロケートされる。そして、このスレッドはこのプライベート・ブロックを満杯に近づけることは決してない。したがって、メモリのブロックをアロケートする幾つかの方法は、スレッドが高速アロケーティング・スレッド及び低速アロケーティング・スレッドのいずれであるかの“明示的”決定を含み得る。
【0058】
幾つかの実施形態では、アロケーション領域から得たプライベート・ブロックを、共有ブロックのオーバーフローを引き起こしたスレッドへアロケートすることは、実質的に自動的に起こらない。例えば、スレッドが共有ブロックのオーバーフローを引き起こした回数と、プライベート・ブロックをスレッドへアロケートする時とを示すために、“統計学的インジケータ”を使用し得る。図9は本発明の第1実施形態に基づくメモリをアロケートするプロセスに関連する複数のステップを示すフローチャートであり、このプロセスにおけるプライベート・ブロックの割り当ては統計学的データに基づいて行われる。このメモリをアロケートする方法はステップ602から始まる。ステップ602では、複数のメモリ・ブロックを共有メモリ・アロケーション領域内でアロケートすることによって、共有メモリ・アロケーション領域を構築する。アロケーション領域内のメモリを複数のブロックへ分割した後、ステップ604では、新たなオブジェクトのアロケーションをアロケーション領域内で試みる全てのスレッドのための共有ブロックとして、アロケーション領域内の第1ブロックを割り当てる。全てのスレッドのための共有ブロックを割り当てることにより、各スレッドは新たなオブジェクトを共有ブロック内でアロケートできる。
【0059】
共有ブロックを割り当てた後、総合システムをステップ606で実行する。一般的に、総合システムの実行中のある時点において、新たなオブジェクトの形成を試みるスレッドはアロケーション領域をオーバーフローし得る。前記のように、ブロックがオーバーフローしたことの発見、即ち、スレッドによる発見は、ブロックがオーバーフローしたことの事実上の確定といえる。したがって、ブロックがオーバーフローしたか否かをステップ608で決定する。
【0060】
共有ブロックなどのブロックがオーバーフローしていないことがステップ608で確定した際、ステップ606におけるシステムの実行の継続を許可する。これに代えて、ブロックがオーバーフローしたことが確定した際、プロセスの流れはステップ610へ移行する。ステップ610では、利用可能な次のブロックをアロケーション領域から獲得することが試みられる。利用可能な次のブロックを獲得することを試みた後、ステップ612において、新たなブロックが利用可能であるか否かを決定する。換言するならば、利用可能な未使用のメモリ・ブロックがアロケーション領域内に存在するか否かを決定する。
【0061】
新たなブロックが利用可能であることが確定した際、ステップ618では、ブロックのオーバーフローを引き起こしたスレッド、即ち、“オーバーフローイング・スレッド”に関連付けられたオーバーフロー・カウンタをインクリメントする。自身に関連付けられたスレッドがブロックのオーバーフローを引き起こした回数の表示(例:統計学的表示)を提供するために、オーバーフロー・カウンタは設けられている。プライベート・ブロックがスレッドへアロケートされるまで、このスレッドのオーバーフロー・カウンタは、このスレッドがブロックのオーバーフローを引き起こした回数を事実上表示する。しかし、プライベート・ブロックをスレッドへアロケートした後、このスレッドのオーバーフロー・カウンタは、このスレッドが共有ブロックまたはプライベート・ブロックのオーバーフローを引き起こした回数の表示を提供する。
【0062】
オーバーフローイング・スレッドのオーバーフロー・カウンタをステップ618でインクリメントした後、オーバーフロー・カウンタが閾値を越えたか否かをステップ620で決定する。換言するならば、このスレッドが引き起こしたブロックのオーバーフローの回数が特定の限度を超えたか否かを決定する。この限度、即ち、閾値は総合システムの要件に基づいて広範に変化し得ることを理解する必要がある。オーバーフロー・カウンタが閾値を越えていないことがステップ620で確定した場合、プロセスの流れはステップ622へ移行する。ステップ622では、満杯のブロックを新たな共有ブロックと置換する。新たなブロックを適切に割り当てた後、プロセスの流れはステップ606へ戻り、総合システムの実行を許可する。
【0063】
オーバーフロー・カウンタが閾値を越えていることがステップ620で確定した際、ステップ624において、新たなブロックを、ブロックのオーバーフローをステップ608で引き起こしたスレッドへ割り当てる。次いで、ステップ626において、オーバーフローしたブロックが共有ブロックであるか否かを決定する。オーバーフローしたブロックが共有ブロックでないことが確定した場合、ステップ606における総合システムの実行を許可する。しかし、オーバーフローしたブロックが共有ブロックであることが確定した場合、これは新たな共有ブロックが必要なことを意味する。したがって、ステップ627において、共有ブロックとして割り当てる別の新たなブロックが利用可能であるか否かを決定する。
【0064】
新たなブロックが利用可能でない際、プロセスの流れはステップ606へ戻り、システムの実行を許可する。新たな共有ブロックがない場合、新たなオブジェクトをそれまでの共有ブロック内でアロケートするスレッドのその後の全ての試みは、以下に詳述するように、使用済みのブロックを事実上解放するガーベッジ・コレクションを引き起こす。これに代えて、別の新たなブロックをステップ627で利用可能な際、ステップ622において、満杯の共有ブロックを新たな共有ブロックと置換する。
【0065】
再びステップ612へ戻り、新たなブロックが利用可能でないことが確定した際、ガーベッジ・コレクションをステップ616で実施する。1つの実施形態では、ガーベッジ・コレクションは、世代別ガーベッジ・コレクション・アルゴリズムを含む。前記のように、アロケーション領域のブロックに格納されたライブ・オブジェクトをメモリの他の領域へコピーし、これによって、アロケーション領域の少なくとも幾つかのブロックを新たなアロケーションのために空にするために、世代別ガーベッジ・コレクション・アルゴリズムは設けられている。ブロックの解放後、これらのブロックは特定の1つのスレッドまたはスレッド群へ割り当てるために利用可能である。
【0066】
ガーベッジ・コレクションをステップ616で実施した後、ステップ617において、総合システムに関連する実質的に全てのスレッドのオーバーフロー・カウンタをそれぞれリセットする。一般的に、オーバーフロー・カウンタは初期値へリセットされ、この初期値はスレッドがあらゆるブロックをオーバーフローさせていないことを示す。プロセスの流れはステップ617からステップ604へ戻り、共有ブロックを総合システム内の全てのスレッドへ割り当てる。
【0067】
一般的に、図9に基づいて詳述したように、プライベート・ブロックをスレッドへ割り当てる時を決定するために、統計学的インジケータを使用し得る。しかし、一般的に、統計学的インジケータを使用する方法は様々である。メモリのアロケーションにおけるオーバーフロー・カウンタなどの統計学的インジケータの使用の別の例を図10に基づいて詳述する。図10はガーベッジ・コレクション・プロセス後に、幾つかのスレッドがプライベート・ブロックを維持することを可能にするための、オーバーフロー・カウンタの使用を示す。
【0068】
図10は本発明の第1実施形態に基づく統計学的インジケータを使用してメモリをアロケートする別のプロセスに関連する複数のステップを示すフローチャートである。このメモリをアロケートする方法はステップ702から始まる。ステップ702では、複数のメモリ・ブロックを共有メモリ・アロケーション領域内でアロケートすることによって、共有メモリ・アロケーション領域を構築する。アロケーション領域内のメモリを複数のブロックへ分割した後、ステップ704では、新たなオブジェクトのアロケーションをアロケーション領域内で試みる全てのスレッドのための共有ブロックとして、アロケーション領域内の第1ブロックを割り当てる。
【0069】
共有ブロックを割り当てた後、ステップ706において、総合システムを実行する。即ち、スレッドが新たなオブジェクトのアロケーションを試みることを許可する。総合システムの実行中のある時点において、新たなオブジェクトの形成を試みるスレッドはアロケーション領域をオーバーフローさせる。ブロックがオーバーフローしたことの発見、即ち、スレッドによる発見は、ブロックがオーバーフローしたことの事実上の確定であるため、ブロックがオーバーフローしたか否かをステップ708で決定する。
【0070】
事実上、ブロック(例:共有ブロック)がオーバーフローしたことがステップ708で確定するまで、ステップ706におけるシステムの実行の継続を許可する。ブロックがオーバーフローしたことが確定した際、プロセスの流れはステップ708からステップ710へ移行する。ステップ710では、利用可能な次のブロックをアロケーション領域から獲得することが試みられる。利用可能な次のブロックを獲得することを試みた後、ステップ712において、ブロックが利用可能であるか否かを決定する。
【0071】
新たなブロックが利用可能であることが確定した際、ステップ713では、ブロックのオーバーフローを引き起こしたスレッド、即ち、オーバーフローイング・スレッドに関連付けられたオーバーフロー・カウンタをインクリメントする。図9に基づいて詳述したように、自身に関連付けられたスレッドがブロックのオーバーフローを引き起こした回数を確認するために、オーバーフロー・カウンタは一般的に設けられている。
【0072】
オーバーフローイング・スレッドのオーバーフロー・カウンタをステップ713でインクリメントした後、オーバーフロー・カウンタの値が所定の閾値より大きいか否かをステップ714で決定する。プライベート・ブロックをスレッドへ割り当てるか否かを決定するために、所定の閾値は一般的に使用される。オーバーフロー・カウンタの値が閾値未満であることが確定した際、プロセスの流れはステップ720へ移行する。ステップ720では、満杯の共有ブロックを新たなブロック、即ち、新たな共有ブロックと置換する。満杯の共有ブロックを置換した後、ステップ706における総合システムの実行の継続を許可する。
【0073】
オーバーフロー・カウンタの値が閾値を越えていることがステップ714で確定した場合、ステップ715において、新たなブロックを、ステップ708でブロックをオーバーフローさせたことが確定したスレッドへ割り当てる。新たなブロックをスレッド、より詳細には、オーバーフローイング・スレッドへ割り当て、これによって、この新たなブロックがプライベート・ブロックとなった後、オーバーフローしたブロックが共有ブロックであるか否かをステップ717で決定する。オーバーフローしたブロックが共有ブロックでないことが確定した場合、プロセスの流れはステップ706へ戻り、総合システムの実行を許可する。プライベート・ブロックをオーバーフローしたシステムへ割り当てた後、総合システムの実行を許可するまでは、このオーバーフローしたブロックが共有ブロックであることを理解する必要がある。プライベート・ブロックをオーバーフローしたシステムへ割り当てた後、このオーバーフローしたブロックは、共有ブロックまたはプライベート・ブロックである。
【0074】
これに代えて、オーバーフローしたブロックが共有ブロックであることがステップ717で確定した場合、これはオーバーフロした共有ブロックを置換することが好ましいことを意味している。したがって、別の新たなブロックが利用可能であるか否かをステップ718で決定する。別の新たなブロックが利用可能であることが確定した場合、ステップ720では、オーバーフローした共有ブロックを別の新たなブロックと置換する。次いで、プロセスの流れはステップ706へ移行し、総合システムの実行を許可する。その一方、別の新たなブロックが利用可能でないことがステップ718で確定した際、プロセスの流れはステップ706へ直接戻り、総合システムの実行を許可する。
【0075】
再びステップ712へ戻り、ブロックがオーバーフローした後、新たなブロックが利用可能でないことが確定した際、ガーベッジ・コレクションをステップ726で実施する。ガーベッジ・コレクションをステップ726で実施した後、高速アロケーティング・スレッドと考えられるスレッドをステップ728で決定する。1つの実施形態では、高速アロケーティング・スレッドと考えられるスレッドの決定は、特定の限度を越えたオーバーフロー・カウンタを有するスレッドを識別するために、スレッドのオーバーフロー・カウンタを比較することを含む。これに代えて、別の実施形態では、高速アロケーティング・スレッドと考えられるスレッドは、全てのスレッドの中で最も高い数値を示すオーバーフロー・カウンタを有する所定の数のスレッドであり得る。
【0076】
高速アロケーティング・スレッドと考えられるスレッドをステップ728で識別した後、ステップ729では、低速アロケーティング・スレッド、即ち、高速アロケーティング・スレッドと考えられないスレッドのオーバーフロー・カウンタをリセットする。低速アロケーティング・スレッドのオーバーフロー・カウンタのリセットは、プライベート・ブロックを必要としないスレッドに対するプライベート・ブロックのアロケーションを防止する。一般的に、オーバーフロー・カウンタは、スレッドがあらゆるブロックをオーバーフローさせていないことを示す初期値へリセットされる。ステップ730では、新たなブロックを各高速アロケーティング・スレッドへ割り当てる。即ち、プライベート・ブロックを各高速アロケーティング・スレッドへ割り当てる。新たなブロックを各高速アロケーティング・スレッドへ割り当てた後、ステップ732では、共有ブロックを他の全てのスレッド、即ち、低速アロケーティング・スレッドへ割り当てる。プライベート・ブロックまたは共有ブロックを全てのスレッドへ割り当てた後、プロセスの流れはステップ706へ戻り、総合システムの実行を許可する。
【0077】
高速アロケーティング・スレッドがプライベート・メモリ・ブロックへアクセスすることを許可する一方で、複数の低速アロケーティング・スレッドによるメモリ・ブロックの共有を可能にすることによって、ガーベッジコレクションの時に無駄になるメモリの量、即ち、リザーブされていながらも満たされていないメモリの量が減少する。メモリ・ブロックの共有によって更に多くのメモリがガーベッジ・コレクションの実施前に満たされるため、メモリ・ブロックの共有は実施されるガーベッジ・コレクションの頻度を減少させる。無駄になるメモリを減少し、かつガーベッジ・コレクションの頻度を低減するメモリ・ブロックをアロケートする別の方法は、異なる複数のサイズのメモリ・ブロックを形成し、これらのメモリ・ブロックをスレッドの要件に基づいてスレッドへアロケートすることを含む。この方法を使用することにより、オブジェクトを共有ブロック内でアロケートする試みに関連する同期コストを事実上無くし得る。
【0078】
異なる複数のサイズのメモリ・ブロックに分割された共有メモリ領域と、ブロックを異なる複数のスレッドへアロケートする幾つかの方法とを図11、図12、図13、図14及び図15に基づいて以下に詳述する。図11は本発明の第2実施形態に基づく複数のスレッドと、これらのスレッドによって共有され、かつ複数の異なるサイズのブロックへ分割されたメモリ・アロケーション領域とを示す図である。マルチスレッド・コンピューティング環境750は共有メモリ・アロケーション領域752及び複数のスレッド756を含む。メモリ・アロケーション領域752は複数の異なるサイズのブロック754,755へ分割されている。本実施形態では、複数のブロック754は実質的に同じ1つのサイズであり、別の複数のブロック755はブロック754より大きい実質的に同じ別のサイズである。しかし、メモリ・アロケーション領域752は異なるサイズの2つを越す数のブロック群を一般的に含むことを理解する必要がある。
【0079】
メモリ・アロケーション領域752のサイズは環境750の要件(但し、これに限定されない)を含むファクタに基づいて変化し得る。例えば、環境750が関連するジャバ(商標)仮想マシンを有する場合、メモリ・アロケーション領域752は約128kBから約512kBの範囲のサイズを有し得る。同様に、ブロック754,755のサイズは広範に変化し得る。1つの実施形態では、ブロック754はブロック755よりかなり小さくできる。例えば、ブロック754を約1kBから4kBの範囲のサイズとし、ブロック755を約16kBから約32kBの範囲のサイズとし得る。前記のように、環境750では、全てのブロック754をほぼ同じサイズとし、全てのブロック755をほぼ同じサイズとする。これによって、メモリ・アロケーション領域752は2つの異なるサイズのブロックを事実上有する。
【0080】
環境750内では、ブロック755はブロック754より大きいため、プライベート・ブロック755が各高速アロケーティング・スレッド756(例:スレッド756a,756d)へ最終的にアロケートされる。その一方、プライベート・ブロック754が各低速アロケーティング・スレッド756b,756cへアロケートされる。一般的に、小さい方のブロック754はガーベッジ・コレクションの時に満たされている可能性が更に高いため、この小さい方のブロック754を低速アロケーティング・スレッド756b,756cへ割り当てることによって、無駄になるメモリ・スペースが減少する。更に、大きい方のブロック755を高速アロケーティング・スレッド756a,756d、即ち、比較的多くのバイトをアロケートするスレッドへ割り当てることにより、高速アロケーティング・スレッド756a,756dはメモリ・スペースへの更に多くのアクセスが可能になる。これによって、ガーベッジ・コレクションの頻度が潜在的に減少する。
【0081】
小さい方のブロック754を低速アロケーティング・スレッド、即ち、少量アロケーティング・スレッド756b,756cへ割り当てることにより、環境750、即ち、マルチスレッド方式のマルチプロセッサ環境などの環境において起こり得る偽の共有に関連する問題を減少し得る。当業者が理解するように、2つのオブジェクトを1つのキャッシュ・ライン内でアロケートし、これら2つのオブジェクトがそれぞれ単一スレッドによる頻繁な書き込みを受ける際、即ち、1つのスレッドが一方のオブジェクトを書き込み、別のスレッドが他方のオブジェクトを書き込む際、偽の共有が一般的に起こる。この状況は比較的高い費用を要するリモート・キャッシュ・ミスを引き起こし得る。各スレッド756が独自のブロック754,755を有する場合、オブジェクトをアロケートするこのスレッドが、特定のオブジェクトを最も頻繁に書き込むスレッドである限り、偽の共有は減少する。
【0082】
1つの実施形態では、プライベート大型ブロックを潜在的な高速アロケーティング・スレッドへ割り当てる前、潜在的な高速アロケーティング・スレッドを識別する。図12は本発明の第2実施形態に基づくメモリをアロケートする第1のプロセスに関連する複数のステップを示すフローチャートである。このプロセスはステップ802から始まる。ステップ802では、小型メモリ・ブロック及び大型メモリ・ブロックをアロケートすることによって、アロケーション領域を事実上構築する。小型ブロックの数量及び大型ブロックの数量は広範に変化可能であり、かつ総合システムの予想される要件(但し、これに限定されない)を含むファクタに基づき得る。一般的に、総合システムに関連する全てのスレッドのための少なくとも1つの小型ブロックを設けるように、小型ブロックの数量は決められている。
【0083】
図11に関連して詳述したように、メモリ・ブロックのサイズは広範に変化し得る一方、1つの実施形態では、大型メモリ・ブロックは小型メモリ・ブロックのサイズの少なくとも10倍のサイズである。例えば、小型メモリ・ブロックを約2kBのサイズにし、大型メモリ・ブロックを約32kBのサイズにし得る。一般的に、大型メモリ・ブロックを小型メモリ・ブロックへ必要に応じて簡単に分割できるようにするために、小型メモリ・ブロックは大型メモリ・ブロックより2の累乗だけ小さいサイズとし得る。
【0084】
小型メモリ・ブロック及び大型メモリ・ブロックをステップ802でアロケートした後、ステップ804において、小型メモリ・ブロックを全てのスレッドへ割り当てる、即ち、アロケートする。即ち、小型メモリ・ブロックを全てのスレッドへプライベート・ブロックとして割り当てる。小型メモリ・ブロックを各スレッドへ割り当てた後、ステップ806における総合システムの実行を許可する。総合システムの実行中、スレッドは新たなオブジェクトを自身に関連するプライベート・ブロック内でアロケートすることを試みる。一般的に、システムの実行中、新たなオブジェクトをアロケートすることを試みるスレッドは自身のプライベート・ブロックをオーバーフローさせる。
【0085】
一般的に、スレッドが自身のプライベート・ブロックのオーバーフローを発見することは、ブロックがオーバーフローしたことの確定を事実上意味する。したがって、ブロックがオーバーフローしたことがステップ808で確定するまで、総合システムはステップ806における実行を継続する。ブロックがオーバーフローしたことがステップ808で確定した際、これはブロックのオーバーフローを引き起こしたスレッドが潜在的に高速アロケーティング・スレッドであることを意味する。したがって、ステップ810では、利用可能な次の大型ブロックをアロケーション領域から獲得することを試みる。
【0086】
ステップ812では、新たな大型ブロックをステップ810で獲得できたか否か、即ち、利用可能であるか否かを決定する。新たな大型ブロックが利用可能であることが確定した場合、ステップ814において、新たな大型ブロックを、自身のブロックのオーバーフローを引き起こしたスレッドへ割り当てる。新たな大型ブロックを割り当てた後、プロセスの流れはステップ806へ戻り、総合システムの実行を許可する。
【0087】
これに代えて、新たな大型ブロックが利用可能でないことがステップ812で確定した際、本実施形態では、ガーベッジ・コレクションをステップ816で実施する。前記のように、ガーベッジ・コレクション(例:世代別ガーベッジ・コレクション)はメモリ・ブロックを解放するために実施する。一般的に、ガーベッジ・コレクションはスレッド及びプライベート・ブロックの間の関連付けを削除する。換言するならば、ガーベッジ・コレクションを完了した際、総合システム内の各スレッドは自身に割り当てられたブロックを持たないことになる。したがって、ガーベッジ・コレクションを実施した後、プロセスの流れはステップ804へ移行し、小型メモリ・ブロックを各スレッドへ割り当てる。
【0088】
ガーベッジ・コレクション・プロセス後、小型ブロックを各スレッドへ割り当てることは効果的であるが、ガーベッジ・コレクション・プロセス後に各スレッドへ割り当てるブロックのサイズを決定するために、他のプロセスを使用し得る。例えば、小型ブロックをガーベッジ・コレクション・プロセス後に各スレッドへ割り当てる代わりに、ブロックを各スレッドの考えられる要件に基づいて割り当て得る。スレッドが大型ブロックであるプライベート・ブロックをガーベッジ・コレクション・プロセスの実施前に持っていたか否かを憶えておくことにより、スレッドが高速アロケーティング・スレッドであり、かつ大型ブロックを必要としていることが確定した場合、新たな大型ブロックをそのスレッドへ割り当て得る。比較的大量の新たなオブジェクトをアロケートすることが期待されるスレッドに対して、プライベート大型ブロックを割り当てることにより、総合システム内のブロックがオーバーフローする回数が減少し、これによって、システムの効率が高くなる。
【0089】
図13は本発明の第2実施形態に基づくメモリをアロケートするプロセスに関連する複数のステップを示すフローチャートであり、このプロセスはブロックをスレッドのアロケーション速度に基づいてスレッドへ割り当てることを含む。プロセスはステップ902から始まる。ステップ902では、小型メモリ・ブロック及び大型メモリ・ブロックをアロケートすることによって、アロケーション領域を構築する。小型ブロックの数量及び大型ブロックの数量は広範に変化し、かつ総合システムの予想される要件(但し、これに限定されない)を含むファクタに基づき得る。一般的に、総合システムに関連する全てのスレッドのための少なくとも1つの小型ブロックを設けるように、小型ブロックの数量は決められている。
【0090】
小型メモリ・ブロック及び大型メモリ・ブロックをアロケーション領域内でアロケートした後、ステップ904では、小型メモリ・ブロックを全てのスレッドへ割り当てる、即ち、アロケートする。プライベート小型メモリ・ブロックを各スレッドへ割り当てた後、ステップ906において、総合システムの実行を許可する。総合システムの実行中、スレッドは新たなオブジェクトを自身に関連するプライベート・ブロック内でアロケートすることを試みる。システム実行中のある時点において、新たなオブジェクトをアロケートすることを試みるスレッドは自身のプライベート・ブロックをオーバーフローさせる。
【0091】
スレッドが自身のプライベート・ブロックのオーバーフローを発見することは、ブロックがオーバーフローしたことの確定を事実上意味する。したがって、ブロックがオーバーフローしたことがステップ908で確定するまで、総合システムはステップ906における実行を継続する。ブロックがオーバーフローしていることがステップ908で確定した際、ステップ910において、利用可能な次の大型ブロックをアロケーション領域から獲得することを試みる。
【0092】
利用可能な次の大型ブロックをアロケーション領域から獲得することを試みた後、新たな大型ブロックが利用可能であるか否かをステップ912で決定する。新たな大型ブロックが利用可能であることが確定した場合、ステップ914において、新たな大型ブロックを自身のブロックのオーバーフローを引き起こしたスレッドへ割り当てる。そして、プロセスの流れはステップ906へ移行し、総合システムの実行を許可する。
【0093】
これに代えて、新たな大型ブロックが利用可能でないことがステップ912で確定した場合、本実施形態では、ステップ916において、ガーベッジ・コレクションを実施する。ガーベッジ・コレクション(世代別ガーベッジ・コレクションであり得る)はメモリ・ブロックを解放するために実施し、かつスレッド及びプライベート・ブロックの間の関連付けを削除する。本実施形態では、ガーベッジ・コレクション中、そのスレッドが大型ブロック及び小型ブロックのいずれに関連付けられていたかを示す情報を維持する。
【0094】
ガーベッジ・コレクションを実施した後、ステップ918において、高速アロケーティング・スレッドと考えられるスレッドを識別する。高速アロケーティング・スレッドの識別に関連するステップは一般的に様々であり、かつ個々のシステムの要件(但し、これに限定されない)を含むファクタに基づき得る。高速アロケーティング・スレッドと考えられるスレッドを決定する1つの方法を、図14に基づいて以下に詳述する。
【0095】
ステップ920では、新たな大型ブロックを、識別された各高速アロケーティング・スレッドへ割り当てる。換言するならば、プライベート大型ブロックを各高速アロケーティング・スレッドへアロケートする。次いで、ステップ922において、小型ブロックを残りの各スレッド(例:低速アロケーティング・スレッド)へ割り当てる。プライベート・ブロックを全てのスレッドへ割り当てた後、プロセスの流れはステップ906へ戻り、総合システムの実行を許可する。
【0096】
次いで、高速アロケーティング・スレッドと考えられるスレッドを識別する1つの方法を図14に基づいて詳述する。図14は本発明の第2実施形態に基づく高速アロケーティング・スレッドと考えられるスレッドを決定することに関連する複数のステップ、即ち、図13のステップ918に関連する複数のステップを示すフローチャートである。高速アロケーティング・スレッドと考えられるスレッドを決定するプロセスはステップ934から始まる。ステップ934では、高速アロケーティング・スレッドと考えられるか否かを識別するための“テスト”を受けるスレッドが存在するか否かを事実上決定する。テストを受けるスレッドが存在しない場合、スレッドが高速アロケーティング・スレッド及び低速アロケーティング・スレッドのいずれであるか否かを決定するプロセスは完了する。これに代えて、テストを受けるスレッドが存在する場合、ステップ936において、プライベート小型ブロックがそのスレッドへ割り当てられているか否かを決定する。
【0097】
プライベート小型ブロックがスレッドへ割り当てられていることが確定した場合、このスレッドはプライベート大型ブロックを以前に必要としていなかったことになる。このため、これはそのスレッドが低速アロケーティング・スレッドであることを意味する。スレッドが低速アロケーティング・スレッドであると考えられる際、ステップ942において、このスレッドを低速アロケーティング・スレッドとしてマークする。スレッドを低速アロケーティング・スレッドとして識別した後、プロセスの流れはステップ934へ戻り、処理する別のスレッドが存在するか否かを決定する。
【0098】
これに代えて、プライベート小型ブロックがスレッドへ割り当てられていないことがステップ936で確定した場合、これはプライベート大型ブロックがそのスレッドへ割り当てられたことを意味する。したがって、そのスレッドは高速アロケーティング・スレッドと考えられる。スレッドが高速アロケーティング・スレッドと考えられる場合、ステップ938において、このスレッドが最後のガーベッジ・コレクション・インターバルでアロケートしたメモリの総量が閾値を越えているか否かを決定する。1つの実施形態では、ガーベッジ・コレクション・インターバルは、直近のガーベッジ・コレクションと、この直近のガーベッジ・コレクションの直前に行われたガーベッジ・コレクションとの間の経過時間である。一般的に、ガーベッジ・コレクション・インターバルに関連する情報は必要に応じて総合システム・メモリ内に蓄積され、かつ格納される。この場合、スレッドが直近のガーベッジ・コレクション以降にアロケートしたメモリの総量が、閾値を超えていないか否かを決定することをステップ938は基本的に含む。そして、閾値は総合システムの要件に基づいて広範に変化し得る。
【0099】
スレッドが最後のガーベッジ・コレクション・インターバル内でアロケートしたメモリの総量が閾値を超えていることがステップ938で確定した場合、スレッドは高速アロケーティング・スレッドと考えられる。スレッドが高速アロケーティング・スレッドと考えられる際、ステップ940において、そのスレッドを高速アロケーティング・スレッドとしてマークする。スレッドを高速アロケーティング・スレッドとしてマークした後、即ち、識別した後、プロセスの流れはステップ904へ戻り、処理する別のスレッドが存在するか否かを決定する。
【0100】
その一方、スレッドが最後のガーベッジ・コレクション・インターバル内でアロケートしたメモリの総量が閾値未満であることがステップ938で確定した場合、これはそのスレッドが高速アロケーティング・スレッドでないことを意味する。この結果、ステップ942において、そのスレッドを低速アロケーティング・スレッドとしてマークする。スレッドを低速アロケーティング・スレッドとしてマークした後、プロセスの流れはステップ934へ戻り、処理する別のスレッドが存在するか否かを決定する。
【0101】
大型メモリ・ブロック及び小型メモリ・ブロックのいずれを、自身のブロックをオーバーフローさせたスレッドへアロケートするかを決定するために、このスレッドが任意の時間内でアロケートしたメモリの総量などの診断を使用することに代えて、スレッドへアロケートするブロックのサイズの決定は、他のファクタに基づいて行い得る。例えば、この決定は、スレッドがプライベート・ブロックをオーバーフローさせた回数に基づき得る。次いで、本発明の第2実施形態に基づき、メモリをオーバーフロー・カウンタを使用してアロケートする第3のプロセスに関連する複数のステップを図15に基づいて詳述する。このプロセスはステップ952から始まる。ステップ952では、異なる複数のサイズ(例:小型及び大型)のメモリ・ブロックをアロケートすることによって、メモリ・アロケーション領域を事実上構築する。小型メモリ・ブロック及び大型メモリ・ブロックをアロケートした後、ステップ954において、小型ブロックを総合システム内の各スレッドへ割り当てる。即ち、プライベート小型ブロックをシステム内の各スレッドへ割り当てる。
【0102】
プライベート小型ブロックを各スレッドへ割り当てた後、ステップ956における総合システムの実行を許可する。総合システムの実行中、スレッドは新たなオブジェクトを自身のプライベート・ブロック内でアロケートすることを試みる。システムの実行中、新たなオブジェクトを自身のプライベート・ブロック内でアロケートすることを試みるスレッドは、自身のプライベート・ブロックをオーバーフローさせる。一般的に、スレッドが自身のプライベート・ブロックのオーバーフローを発見することは、総合システム内のブロックがオーバーフローしたことの確定に事実上等しい。したがって、ブロックがオーバーフローしたことがステップ958で確定するまで、総合システムはステップ956における実行を継続する。ブロックがオーバーフローしたことがステップ958で確定した際、ステップ959において、ブロックのオーバーフローを引き起こしたスレッドのオーバーフロー・カウンタをインクリメントする。
【0103】
本実施形態では、スレッドが関連するプライベート・ブロックのオーバーフローを引き起こした回数を表示するために、スレッドのオーバーフロー・カウンタは設けられている。オーバーフローイング・スレッドのオーバーフロー・カウンタをインクリメントした後、ステップ960において、オーバーフローイング・スレッドのオーバーフロー・カウンタが閾値、即ち、特定の限度を超えたか否かを決定するための比較を実施する。閾値は総合システムの要件に基づいて広範に変化し得ることを理解する必要がある。しかし、一般的に、閾値を越すオーバーフローカウンタを有するスレッドが、多くのオブジェクトをアロケートする傾向を示すように、閾値を設定する。
【0104】
オーバーフローイング・スレッドのオーバーフロー・カウンタが閾値を超えていないことがステップ960で確定した際、これはオーバーフローイング・スレッドがおそらく高速アロケーティング・スレッドではなく、したがって、大型ブロックをおそらく必要としないことを意味している。この結果、ステップ962において、新たな小型ブロックをアロケーション領域から獲得することを試みる。ステップ964では、新たな小型ブロックをアロケーション領域から獲得する試みが成功したか否かを決定する。新たな小型ブロックの獲得に成功した場合、ステップ966において、この新たな小型ブロックを、自身のブロックをオーバーフローさせたスレッドへ割り当てる。次いで、プロセスの流れはステップ956へ戻り、総合システムの実行の継続を許可する。
【0105】
これに代えて、新たな小型ブロックが利用可能でないことがステップ964で確定した場合、世代別ガーベッジ・コレクションなどのガーベッジ・コレクションをステップ968で実施する。小型ブロック及び大型ブロックに関連するメモリを解放するために、ガーベッジ・コレクションを実施した後、ステップ970において、全てのスレッドのオーバーフロー・カウンタを初期値へリセットする。一般的に、スレッドがブロックのオーバーフローを引き起こしていないことを表示するために、初期値は設けられている。オーバーフロー・カウンタをリセットした後、プロセスの流れはステップ954へ戻り、プライベート小型ブロックを各スレッドへアロケートする。
【0106】
再びステップ960へ戻り、オーバーフローイング・スレッドのオーバーフロー・カウンタが閾値を超えていることが確定した際、これはオーバーフローイング・スレッドがおそらく高速アロケーティング・スレッドと考えられることを意味する。したがって、ステップ972では、利用可能な次の大型ブロックをメモリ・アロケーション領域から獲得することを試みる。新たな大型ブロックの獲得を試みた後、ステップ974において、新たな大型ブロックが利用可能であるか否かを決定する。新たな大型ブロックが利用可能であることが確定した場合、ステップ976において、この新たな大型ブロックをオーバーフローイング・スレッドへ割り当て、ステップ956における総合システムの実行を許可する。これに代えて、大型ブロックが利用可能でないことがステップ974で確定した場合、プロセスの流れはステップ968へ移行し、メモリを解放するためのガーベッジ・コレクションを実施する。
【0107】
本発明は任意の適切なコンピュータ・システム上で実現できる。図16は本発明の実現に適した一般的な汎用コンピュータ・システムを示す。コンピュータ・システム1030は任意の数のプロセッサ1032(中央処理装置、即ち、CPUとも称される)を有する。プロセッサ1032は一次記憶装置1034(一般的には、リード・オンリ・メモリ、即ち、ROM)及び別の一次記憶装置1036(一般的には、ランダム・アクセス・メモリ、即ち、RAM)を含むメモリ装置へ接続されている。
【0108】
当業者が理解するように、コンピュータ・システム1030、より詳細には、CPU1032は仮想マシンをサポートすべく設け得る。コンピュータ・システム1030上でサポートされている仮想マシンの1つの例を図17に基づいて詳述する。当該技術分野で知られているように、ROMはデータ及び命令をCPU1032へ単方向に転送すべく機能する。その一方、RAMはデータ及び命令を双方向に転送すべく一般的に使用される。一般的に、CPU1032は任意の数のプロセッサを含み得る。前記の2つの一次記憶装置1034,1036は任意の適切なコンピュータ読み取り可能媒体をそれぞれ含み得る。一般的には大容量メモリ装置である二次記憶媒体1038はCPU1032に双方向接続され、かつ別のデータ記憶能力を提供する。大容量メモリ装置1038はコンピュータ・コード及びデータ等を含むプログラムを格納するために使用可能なコンピュータ読み取り可能媒体である。一般的に、大容量メモリ装置1038は一次記憶装置1034,1036より一般的に遅いハード・ディスクまたはテープ等の記憶媒体である。大容量メモリ装置1038は磁気テープ・リーダー、ペーパー・テープ・リーダーまたは他の周知の装置の形態をなし得る。適切なケースでは、大容量メモリ装置1038内に保持されている情報は、RAM1036の一部に標準的な形式で仮想メモリとして組み込み得る。CD−ROM等の特定の一次記憶装置1034はデータをCPU1032へ単方向に送信可能である。
【0109】
CPU1032は1つ以上の入出力装置(I/O)1040へ接続されている。入出力装置1040は、ビデオ・モニタ、トラック・ボール、マウス、キーボード、マイクロホン、タッチ・ディスプレイ、トランスデューサ・カード・リーダー、磁気テープ・リーダー、ペーパー・テープ・リーダー、タブレット、スタイラス、音声認識装置、手書き文字認識装置または他の周知の入力装置(例:他のコンピュータ)などの装置を含み得る(但し、これらに限定されない)。符号1012で示すネットワーク接続を使用することにより、CPU1032をコンピュータまたはテレコミュニケーション・ネットワーク(例:インターネット・ネットワークまたはイントラネット・ネットワーク)へ任意で接続し得る。このネットワーク接続により、前記の方法のステップを実施する過程で、CPU1032は情報をネットワークから受信し、かつ情報をネットワークへ出力し得る。多くの場合、この情報はCPU1032を用いて実行する命令の順番列を表す。更に、この情報は例えば搬送波に組み込まれたコンピュータ・データ信号の形態でネットワークに対して送受信可能である。前記の複数のデバイス及び資材は、コンピュータ・ハードウェア及びソフトウェアの技術分野の当業者には公知である。
【0110】
前記のように、仮想マシンはコンピュータ・システム1030上で実行可能である。図17は図16のコンピュータ・システム1030によってサポートされ、かつ本発明の実現に適する仮想マシンを示す図である。ジャバ(商標)プログラミング言語(サンマイクロシスムズ・インコーポレイテッドが開発)によって書かれたコンピュータ・プログラムなどのコンピュータ・プログラムを実行する際、ソース・コード1110をコンパイラ1120へコンパイルタイム環境1105内で提供する。コンパイラ1120はソース・コード1110をバイトコード1130へ翻訳する。一般的に、ソフトウェア開発者がソース・コード1110を形成した時点で、このソース・コード1110はバイトコード1130へ翻訳される。
【0111】
バイトコード1130は図16のネットワーク1012などのネットワークを通じて複製、ダウンロード若しくは配布するか、または図16の一次記憶装置1034などの記憶装置へ格納し得る。本実施形態では、バイトコード1130はプラットフォームから独立している。即ち、バイトコード1130は適切な仮想マシン1140上で動作する実質的に任意のコンピュータ・システム上で実行可能である。
【0112】
バイトコード1130は仮想マシン1140を含むランタイム環境1135へ提供される。一般的に、ランタイム環境1135は図16のCPU1032などのプロセッサを使用して実行できる。仮想マシン1140はコンパイラ1142、インタプリタ1144及びランタイム・システム1146を含む。バイトコード1130はコンパイラ1142またはインタプリタ1144へ提供可能である。
【0113】
バイトコード1130をコンパイラ1142へ提供する際、バイトコード1130に含まれるメソッドはマシン命令にコンパイルされる。1つの実施形態では、コンパイラ1142はジャスト・イン・タイム・コンパイラであり、このジャスト・イン・タイム・コンパイラはバイトコード1130に含まれるメソッドのコンパイレーションをそのメソッドをまさに実行する直前まで遅延させる。バイトコード1130をインタプリタ1144へ提供した際、バイトコード1130はインタプリタ1144内へ1バイトづつ読み込まれる。次いで、各バイトコードがインタプリタ1144内へ読み込まれるのにしたがって、インタプリタ1144は各バイトコードが定義するオペレーションを実行する。即ち、当業者が理解するように、インタプリタ1144はバイトコード1130を“通訳”する。一般的に、インタプリタ1144はバイトコード1130を処理し、かつバイトコード1130に関連するオペレーションをほぼ連続的に実行する。
【0114】
1つのメソッドが別のメソッドによって呼び出された際、即ち、ランタイム環境1135から呼び出された際、この呼び出されたメソッドを通訳する場合、ランタイム・システム1146はこのメソッドをランタイム環境1135からバイトコード1130の列の形態で獲得し、このバイトコード1130の列はインタプリタ1144によって直接実行される。その一方、呼び出されたメソッドがまだコンパイルされていないコンパイル・メソッド(compiled method)である場合、ランタイム・システム1146は、このメソッドをランタイム環境1135からバイトコード1130の列の形態で獲得し、次いで、コンパイラ1142を起動する。次いで、コンパイラ1142はマシン命令をバイトコード1130から形成し、形成されたマシン言語命令をCPU1032で直接実行する。一般的に、仮想マシン1140を終了した際、マシン言語命令は捨てられる。
【0115】
以上、本発明の僅かな数の実施形態のみを詳述したが、本発明の趣旨または範囲から逸脱することなく、本発明を他の多くの形態で実施し得ることを理解する必要がある。例えば、メモリ・スペースを実質的に同じ複数のブロックへ分割したシステムと、メモリ・スペースを異なる複数のサイズのブロックへ分割したシステムとの両方において、メモリ・スペースをアロケートすることに関連する複数のステップの順序を変更し得る。更に、必要に応じて、ステップの変更、削除または追加が可能である。
【0116】
プライベート小型ブロック及びプライベート大型ブロックの両方を含むシステム内において、プライベート・ブロック、即ち、プライベート大型ブロックをスレッドへ割り当てるか否かの決定は、そのスレッドがアロケートしたバイト数に事実上基づくが、この決定を様々なファクタに基づいて実施し得ることを理解する必要がある。例えば、スレッドが単一の大型オブジェクトを比較的低い頻度でアロケートすべく設けられている際、共有ブロック内における大型オブジェクトの低い頻度でのアロケーションに関連する同期オーバーヘッドは大きくないと考えられるため、プライベート・ブロックをこのスレッドへアロケートすることはない。これに代えて、スレッドが実施するオブジェクト・アロケーションの総数は、プライベート・ブロックを割り当てるスレッドを決定するために使用できる。
【0117】
ガーベッジ・コレクション後に実施される高速アロケーティング・スレッドと考えられるスレッドへのプライベート・メモリ・ブロックの割り当てを、各高速アロケーティング・スレッドへの新たなブロックの割り当てに関して説明した。しかし、高速アロケーティング・スレッドへのプライベート・ブロックの割り当てが“グローバル”である必要がないことを理解する必要がある。換言するならば、プライベート・ブロックを、高速アロケーティング・スレッドと考えられる全てのスレッドへ割り当てなくても良い。例えば、独自のブロックを各高速アロケーティング・スレッドへ関連付けることを可能にする十分な数のメモリ・ブロックが存在しない場合、本発明の趣旨または範囲から逸脱することなく、プライベート・ブロックを“最速”の高速アロケーティング・スレッドにのみ割り当て得る。
【0118】
共有ブロックの使用を、マルチスレッド・システムに関連する全てのスレッドへ最初に割り当てられる共有ブロックに関して一般的に説明した。しかし、1つの実施形態では、単一の共有ブロックを全てのスレッドへ最初に割り当てるより、寧ろ、複数のスレッド群を特定の共有ブロックへ割り当てる。即ち、1つを越す数の共有ブロックが特定のシステム内に存在し得る。使用する共有ブロックの数の決定は、ガーベッジ・コレクションの相対的コストと比較した同期の相対コスト(但し、これに限定されない)を含むファクタに基づき得る。
【0119】
共有ブロック、即ち、多数のスレッドが共有するブロックの使用を、その全てのブロックが実質的に同じサイズであるメモリ・アロケーション領域に関して説明したが、本発明の趣旨または範囲から逸脱することなく、共有ブロックを、異なるサイズの複数のブロックを含むシステム内でも使用できることを理解する必要がある。例えば、メモリ・アロケーション領域を複数の小型ブロック及び大型ブロックへ分割した際、共有ブロックは小型ブロックまたは大型ブロックであり得る。共有ブロックを小型ブロック及び大型ブロックのいずれにするかの決定は、個々のコンピュータ・システムの予想される要件(但し、これに限定されない)を含むファクタに基づき得る。共有ブロックがオーバーフローした際、幾つかの実施形態では、プライベート小型ブロックをオーバーフローイング・スレッドへ最初に割り当て得る。次いで、オーバーフローイング・スレッドが高速アロケーティング・スレッドであることが最終的に確定した場合、プライベート大型ブロックをオーバーフローイング・スレッドへ割り当て得る。
【0120】
図12、図13及び図15に基づいて詳述したように、メモリ・アロケーション領域を複数の小型ブロック及び大型ブロックへ分割した際、大型ブロックを獲得する試みの失敗はガーベッジ・コレクションを引き起こす。しかし、1つの実施形態では、大型ブロックが利用可能でない際、小型ブロックの獲得を試み得る。小型ブロックが利用可能である場合、小型ブロックをオーバーフローイング・スレッドへ割り当て得る。しかし、小型ブロックが利用可能でない場合、ガーベッジ・コレクションを実施し得る。小型ブロックの獲得をガーベッジ・コレクションの実施前に最初に試みることにより、ガーベッジ・コレクションの頻度を減少し、これによって、システムの効率を潜在的に増大させる。
【0121】
同様に、複数の小型メモリ・ブロック及び大型メモリ・ブロックを有するシステム内における小型ブロック獲得の試みが失敗した際、大型ブロックの獲得をガーベッジ・コレクションに頼る前に試み得る。大型ブロックが利用可能である際、大型ブロックをオーバーフローイング・スレッドへ割り当て得る。小型ブロックが利用可能でない際に、大型ブロックをオーバーフローイング・スレッドへ割り当てることにより、利用可能なブロックが枯渇するまで、ガーベッジ・コレクションを遅延できる。これに代えて、小型ブロックが利用可能でない際、新たな小型ブロックを形成するために、大型ブロックを分割し、次いで、形成された小型ブロックを割り当て得る。一般的に、ガーベッジ・コレクションは比較的大きなオーバーヘッドを有するため、ガーベッジ・コレクションの遅延により、必要とされるガーベッジ・コレクションの数を少なくできる。したがって、総合システムの効率を改善することができる。
【0122】
小型ブロック及び大型ブロックの両方を含むシステム内において、スレッドへ割り当てるブロックのサイズを決定するためのオーバーフロー・カウンタの使用を、単一のスレッドへ関連付けられた単一のオーバーフロー・カウンタの比較に関して説明したが、一般的に、スレッドは任意の数のオーバーフロー・カウンタを有し得る。例えば、スレッドが小型ブロックをオーバーフローさせた回数を確認するためのオーバーフロー・カウンタと、スレッドが大型ブロックをオーバーフローさせた回数を確認するためのオーバーフロー・カウンタとを、スレッドは有し得る。2つのオーバーフロー・カウンタを有するスレッドの場合、スレッドへ割り当てる任意の新たなブロックのサイズを決定する際に、異なる複数の閾値を設けることができる。
【0123】
アロケーション領域内における異なるサイズのブロックのアロケーションを、小型ブロック及び大型ブロックのアロケーションに関して一般的に説明した。具体的には、異なるサイズのブロックのアロケーションを2つのサイズのブロックを有するアロケーション領域に関して説明した。しかし、幾つかの実施形態では、本発明の趣旨または範囲から逸脱することなく、2つを越すサイズのブロックをアロケーション領域内でアロケートし得ることを理解する必要がある。例えば、各スレッドの要件に基づいて異なるスレッドへそれぞれ割り当て得る小型メモリ・ブロック、大型メモリ・ブロック及び中型メモリ・ブロックを、アロケーション領域は含むことができる。
【0124】
本発明をジャバ(商標)仮想マシンなどのマルチスレッド・仮想マシンの一部としての利用に関して説明した。しかし、一般的に、本発明は実質的に任意の適切な仮想マシンに対して実現可能である。したがって、本明細書に開示した複数の実施形態は例示目的であって、限定目的ではない。更に、本発明は本明細書に開示する詳細部分に限定されることなく、請求の範囲内で変更し得る。
【図面の簡単な説明】
【図1】スレッド及びメモリ・アロケーション領域を示す図である。
【図2】2つのスレッドと、これら2つのスレッドが共有するメモリ・アロケーション領域とを示す図である。
【図3】2つのスレッドと、これらのスレッドに関連するメモリ・アロケーション領域とを示す図である。
【図4】2つのスレッドと、これら2つのスレッドが共有する複数のチャンクに分割されたメモリ・アロケーション領域とを示す図である。
【図5】本発明の第1実施形態に基づく複数のスレッドと、これらのスレッドが共有するメモリ・アロケーション領域とを示す図である。
【図6】本発明の第1実施形態に基づくメモリをアロケートする第1のプロセスに関連する複数のステップを示すフローチャートである。
【図7】本発明の第1実施形態に基づくメモリをアロケートする第2のプロセスに関連する複数のステップを示すフローチャートである。
【図8】本発明の第1実施形態に基づく高速アロケーティング・スレッドと考えられるスレッドの決定、即ち、図7のステップ458に関連する複数のステップを示すフローチャートである。
【図9】本発明の第1実施形態に基づくメモリをアロケートする第3のプロセスに関連する複数のステップを示すフローチャートである。
【図10】本発明の第1実施形態に基づくメモリをアロケートする第4のプロセスに関連する複数のステップを示すフローチャートである。
【図11】本発明の第2実施形態に基づく複数のスレッドと、これらのスレッドが共有するメモリ・アロケーション領域とを示す図である。
【図12】本発明の第2実施形態に基づくメモリをアロケートする第1のプロセスに関連する複数のステップを示すフローチャートである。
【図13】本発明の第2実施形態に基づくメモリをアロケートする第2のプロセスに関連する複数のステップを示すフローチャートである。
【図14】本発明の第2実施形態に基づく高速アロケーティング・スレッドと考えられるスレッドの決定、即ち、図13のステップ918に関連する複数のステップを示すフローチャートである。
【図15】本発明の第2実施形態に基づくメモリをアロケートする第3のプロセスに関連する複数のステップを示すフローチャートである。
【図16】本発明の実現に適する一般的な汎用コンピュータ・システムを示す図である。
【図17】図16のコンピュータ・システム1030によってサポートされ、かつ本発明の実現に適する仮想マシンを示す図である。

Claims (32)

  1. マルチスレッド・コンピューティング・システム内の複数のスレッドが共有しているメモリをアロケートする方法であって、
    前記共有メモリを複数のブロックへ分割する工程と、
    特定のスレッドが引き起こした、前記複数のブロックに含まれる選択されたブロックのオーバーフローの回数を決定することにより前記特定のスレッドが高速アロケーティング・スレッドであるか否かを決定する工程と、
    前記複数のスレッドを少なくとも第1グループのスレッド及び第2グループのスレッドへグループ分けする工程と、前記第1グループは複数の高速アロケーティング・スレッドを含むように構成され、
    前記複数のブロックから選択した第1ブロックを、前記複数のスレッドから選択したスレッドへアロケートする工程と
    を含み、前記選択したスレッドは、オブジェクトを前記選択した第1ブロック内でアロケートすることを試みるために設けられ、前記選択したスレッドへの前記選択した第1ブロックのアロケーションは、前記選択したスレッドが前記第1グループ及び第2グループのうちのいずれの一部であるかということに少なくとも部分的に基づいて実施される方法。
  2. 請求項に記載の複数のスレッドが共有しているメモリをアロケートする方法において、前記特定のスレッドが高速アロケーティング・スレッドであることが確定した際、前記特定のスレッドはオブジェクトを比較的頻繁にアロケートすることを試み、前記特定のスレッドが高速アロケーティング・スレッドでないことが確定した際、前記特定のスレッドはオブジェクトを比較的頻繁にアロケートすることを試みることはなく、かつ前記第2グループへグループ分けされる方法。
  3. 請求項に記載の複数のスレッドが共有しているメモリをアロケートする方法において、前記特定のスレッドが高速アロケーティング・スレッドであることが確定した際、前記特定のスレッドは所定数を越す数のバイトを所定時間内でアロケートし、前記特定のスレッドが高速アロケーティング・スレッドでないことが確定した際、前記特定のスレッドは所定数未満の数のバイトを所定時間内でアロケートし、かつ前記第2グループへグループ分けされる方法。
  4. 請求項1ないし請求項のいずれか一項に記載の複数のスレッドが共有しているメモリをアロケートする方法において、前記共有メモリを複数のブロックへ分割する工程は、前記共有メモリを少なくとも2つのサイズの複数のブロックへ分割する工程を含む方法。
  5. マルチスレッド・コンピューティング・システム内の共有メモリをアロケートする方法であって、前記マルチスレッド・コンピューティング・システムが第1スレッド及び第2スレッドを少なくとも有する方法において、
    前記共有メモリを複数のブロックへ分割する工程と、
    前記複数のブロックから選択した第1ブロックを前記第1スレッド及び第2スレッドの両方がアクセスできるブロックとして割り当てる工程と、第1オブジェクトを前記第1ブロック内でアロケートすることを試みるべく前記第1スレッドは設けられ、第2オブジェクトを前記第1ブロック内でアロケートすることを試みるべく前記第2スレッドは設けられていることと、
    前記第1ブロックがオーバーフローした時を決定する工程と、
    前記第1ブロックがオーバーフローしたことが確定した際、前記第1オブジェクトを第1ブロック内でアロケートする前記第1スレッドの試みが、前記第1ブロックのオーバーフローを引き起こしたか否かを決定する工程と、
    前記第1オブジェクトを第1ブロック内でアロケートする前記第1スレッドの試みが、前記第1ブロックのオーバーフローを引き起こしたことが確定した際、前記複数のブロックから選択した第2ブロックを、前記第1スレッドへ割り当てる工程と、前記第2ブロックを第1スレッドへ割り当てる工程は、前記第1スレッドがオブジェクトを前記第1ブロック内でアロケートすることをそれ以降試みないようにすべく設けられていること
    を含む方法。
  6. 請求項5に記載の方法において、オブジェクトを前記第2ブロック内でアロケートすることを試みるべく前記第2スレッドは設けられていない方法。
  7. 請求項5または請求項6に記載の方法において、前記第1ブロック及び第2ブロックの一方がオーバーフローした時を決定する工程と、
    前記第2ブロックがオーバーフローしたことが確定した際、前記複数のブロックから選択した第3ブロックを前記第1スレッドへ割り当てる工程と、
    前記第1ブロックがオーバーフローしたことが確定した際、前記第3ブロックを第2スレッドへ割り当てる工程とをさらに含む方法。
  8. 請求項7に記載の方法において、前記第1ブロックがオーバーフローしたことが確定した際、前記第1ブロックと置換するために、前記複数のブロックから選択した第4ブロックを割り当てる工程をさらに含む方法。
  9. 請求項8に記載の方法において、前記複数のブロックが第4ブロックを含むか否かを決定する工程を含む方法。
  10. 請求項5ないし請求項9のいずれか一項に記載の方法において、前記複数のブロックが第2ブロックを含むか否かを決定する工程を含む方法。
  11. 請求項10に記載の方法において、前記複数のブロックが前記第2ブロックを含まないことが確定した際、
    前記第1ブロックに関連するメモリ・スペースを解放するために、ガーベッジ・コレクションを前記共有メモリ領域で実施する工程と、
    前記複数のブロックから選択した新たな第1ブロックを、前記第1スレッド及び第2スレッドの両方からアクセスできるように割り当てる工程と
    を含む方法。
  12. 請求項10に記載の方法において、前記複数のブロックが前記第2ブロックを含まないことが確定した際、
    前記複数のブロックに関連するメモリ・スペースを解放するために、ガーベッジ・コレクションを前記共有メモリ領域で実施する工程と、
    前記第1スレッドが高速アロケーティング・スレッドであるか否かを決定する工程と、
    前記第1スレッドが高速アロケーティング・スレッドであることが確定した際、前記複数のブロックから選択した第3ブロックを前記第1スレッドへ割り当てる工程と
    を含む方法。
  13. 請求項12に記載の方法において、前記複数のブロックから選択した新たな第1ブロックを前記第2スレッドがアクセスできるように割り当てる工程をさらに含む方法。
  14. 請求項13に記載の方法において、前記第1スレッドが高速アロケーティング・スレッドであるか否かを決定する工程は、
    オブジェクトを前記第1ブロック内でアロケートすることを試みるべく前記第1スレッドが設けられているか否かを決定する工程と、
    オブジェクトを前記第1ブロック内でアロケートすることを試みるべく前記第1スレッドが設けられていることが確定した際、前記第1スレッドのアロケーション・ルーチンをロッキングへ設定する工程と、
    オブジェクトを前記第1ブロック内でアロケートすることを試みるべく前記第1スレッドが設けられていないことが確定した際、前記第1スレッドがアロケートしたメモリが閾値を越えたか否かを決定する工程と、
    前記第1スレッドがアロケートしたメモリが前記閾値を越えたと判定した際、前記第1スレッドのアロケーション・ルーチンをノンロッキングへ設定する工程と
    を含む方法。
  15. 請求項5または請求項6に記載の方法において、前記第1ブロックがオーバーフローしたことが確定した際、前記第1ブロックを置換するために、前記複数のブロックから選択した第3ブロックを割り当てる工程をさらに含む方法。
  16. 請求項5ないし請求項15のいずれか一項に記載の方法において、前記第1スレッドが前記第1ブロックのオーバーフローを引き起こしたことが確定した際、前記第1スレッドに関連するカウンタをインクリメントする工程をさらに含み、前記カウンタは前記第2ブロックを前記第1スレッドへ割り当てる時を示すために設けられている方法。
  17. 請求項16に記載の方法において、前記カウンタが閾値を越えた時を決定する工程をさらに含み、前記カウンタが閾値を越えていることが確定するまで、前記第2ブロックを第1スレッドへ割り当てない方法。
  18. 請求項5ないし請求項17のいずれか一項に記載の方法において、前記複数のブロックに含まれる各ブロックは実質的に全て同じサイズである方法。
  19. 請求項18に記載の方法において、前記複数のブロックに含まれる各ブロックのサイズは約2キロバイトから約32キロバイトの範囲内である方法。
  20. マルチスレッド・コンピューティング・システム内の共有メモリをアロケートする方法であって、前記マルチスレッド・コンピューティング・システムが第1スレッド及び第2スレッドを少なくとも有する方法において、
    前記共有メモリを、第1サイズの複数のブロックと、第2サイズの少なくとも1つのブロックとを含む複数のブロックへ分割する工程と、
    前記第1サイズの複数のブロックから選択した第1ブロックを、第1オブジェクトを前記第1ブロック内でアロケートすることを試みるべく設けられた第1スレッドへ割り当てる工程と、
    前記第1サイズの複数のブロックから選択した第2ブロックを、第2オブジェクトを前記第2ブロック内でアロケートすることを試みるべく設けられた第2スレッドへ割り当てる工程と、
    前記第1ブロック及び第2ブロックの一方がオーバーフローした時を決定する工程と、
    前記第2サイズの第3ブロックが利用可能であるか否かを決定する工程と、
    前記第3ブロックが利用可能であることが確定し、かつ前記第1ブロックがオーバーフローしたことが確定した際、前記第3ブロックを第1スレッドへ割り当てる工程と、
    前記第3ブロックが利用可能であることが確定し、かつ前記第2ブロックがオーバーフローしたことが確定した際、前記第3ブロックを第2スレッドへ割り当てる工程と
    を含む方法。
  21. 請求項20に記載の方法において、オブジェクトを前記第2ブロック内でアロケートすることを試みるべく前記第1スレッドは設けられておらず、オブジェクトを前記第1ブロック内でアロケートすることを試みるべく前記第2スレッドは設けられておらず、前記第3ブロックが前記第1スレッドへ割り当てられた際、オブジェクトを前記第3ブロック内でアロケートすることを試みるべく前記第2スレッドは設けられておらず、前記第3ブロックが前記第2スレッドへ割り当てられた際、オブジェクトを前記第3ブロック内でアロケートすることを試みるべく前記第1スレッドは設けられていない方法。
  22. 請求項20または請求項21に記載の方法において、前記第1サイズの複数のブロックは、前記第2サイズの少なくとも1つのブロックより大きいサイズを有する方法。
  23. 請求項20ないし請求項22のいずれか一項に記載の方法において、前記第3ブロックが利用可能でないことが確定した際、前記複数のブロックをクリアすべくガーベッジ・コレクションを実施する工程をさらに含む方法。
  24. メモリ、第1スレッド及び第2スレッドを有し、かつメモリをアロケートすべく設けられているマルチスレッド・コンピュータ・システムであって、前記メモリは前記第1スレッド及び第2スレッドの両方からのアクセスが可能なマルチスレッド・コンピュータ・システムにおいて、
    前記第1スレッドに関連する第1プロセッサと、
    前記第2スレッドに関連する第2プロセッサと、
    前記メモリを複数のブロックへ分割すべく設けられたメモリ・パーティショナと、
    前記複数のブロックから選択した第1ブロックを、前記第1スレッド及び第2スレッドの両方からアクセスできるブロックとして割り当てるべく設けられたブロック・アサイナと、第1オブジェクトを前記第1ブロック内でアロケートすることを試みるべく前記第1スレッドは設けられ、第2オブジェクトを前記第1ブロック内でアロケートすることを試みるべく前記第2スレッドは設けられていることと、
    前記第1ブロックがオーバーフローした時を決定するために設けられた第1決定機構と、
    前記第1ブロックがオーバーフローしたことが確定した際、前記第1オブジェクトを第1ブロック内でアロケートする前記第1スレッドの試みが、前記第1ブロックのオーバーフローを引き起こしたか否かを決定するために設けられた第2決定機構と、
    前記第1オブジェクトを前記第1ブロック内でアロケートする前記第1スレッドの試みが、前記第1ブロックのオーバーフローを引き起こしたことが確定した際、前記複数のブロックから選択した第2ブロックを前記第1スレッドへ割り当てるべく設けられた第2ブロック・アサイナと、前記第2ブロックを前記第1スレッドへ割り当てることは、前記第1スレッドがオブジェクトを前記第1ブロック内でアロケートすることをそれ以降試みないようにすべく行われること
    を含むマルチスレッド・コンピュータ・システム。
  25. 請求項24に記載のマルチスレッド・コンピュータ・システムにおいて、
    前記第1ブロック及び第2ブロックの一方がオーバーフローした時を決定すべく設けられた第3決定機構と、
    前記第2ブロックがオーバーフローしたことが確定した際、前記複数のブロックから選択した第3ブロックを前記第1スレッドへ割り当てるために設けられ、かつ前記第1ブロックがオーバーフローしたことが確定した際、前記第3ブロックを前記第2スレッドへ割り当てるためにも設けられている第3ブロック・アサイナと
    をさらに含むマルチスレッド・コンピュータ・システム。
  26. 自身に関連する共有メモリをアロケートすべく設けられたマルチスレッド・コンピュータ・システムであって、第1スレッド及び第2スレッドを少なくとも有するマルチスレッド・コンピュータ・システムにおいて、
    前記第1スレッドに関連する第1プロセッサと、
    前記第2スレッドに関連する第2プロセッサと、
    前記共有メモリを、第1サイズの複数のブロックと、第2サイズの少なくとも1つのブロックとを含む複数のブロックへ分割すべく設けられたメモリ・アロケータと、
    前記第1サイズの複数のブロックから選択した第1ブロックを、第1オブジェクトを前記第1ブロック内でアロケートすることを試みるべく設けられた第1スレッドへ割り当てるために設けられた第1割り当て機構と、
    前記第1サイズの複数のブロックから選択した第2ブロックを、第2オブジェクトを前記第2ブロック内でアロケートすることを試みるべく設けられた第2スレッドへ割り当てるために設けられた第2割り当て機構と、
    前記第1ブロック及び第2ブロックの一方がオーバーフローした時を決定するために設けられた第1決定機構と、
    前記第2サイズの第3ブロックが利用可能であるか否かを決定するために設けられた第2決定機構と、
    前記第3ブロックが利用可能であることが確定し、かつ前記第1ブロックがオーバーフローしたことが確定した際、前記第3ブロックを第1スレッドへ割り当てるために設けられるとともに、前記第3ブロックが利用可能であることが確定し、かつ前記第2ブロックがオーバーフローしたことが確定した際、前記第3ブロックを第2スレッドへ割り当てるためにも設けられている第3割り当て機構と
    を有するマルチスレッド・コンピュータ・システム。
  27. 請求項26に記載のマルチスレッド・コンピュータ・システムにおいて、前記第1サイズの複数のブロックは前記第2サイズの少なくとも1つのブロックより大きいサイズを有するマルチスレッド・コンピュータ・システム。
  28. マルチスレッド・コンピューティング・システム内の共有メモリをアロケートするためのコンピュータ・プログラムであって、前記マルチスレッド・コンピューティング・システムが第1スレッド及び第2スレッドを少なくとも有するコンピュータ・プログラムを格納するコンピュータ読み取り可能媒体であって、前記コンピュータ・プログラムは、
    前記共有メモリを複数のブロックへ分割する機能と、
    前記複数のブロックから選択した第1ブロックを前記第1スレッド及び第2スレッドの両方がアクセスできるブロックとして割り当てる機能と、第1オブジェクトを前記第1ブロック内でアロケートすることを試みるべく前記第1スレッドは設けられ、第2オブジェクトを前記第1ブロック内でアロケートすることを試みるべく前記第2スレッドは設けられていることと、
    前記第1ブロックがオーバーフローした時を決定する機能と、
    前記第1ブロックがオーバーフローしたことが確定した際、前記第1オブジェクトを第1ブロック内でアロケートする前記第1スレッドの試みが、第1ブロックのオーバーフローを引き起こしたか否かを決定する機能と、
    前記第1オブジェクトを第1ブロック内でアロケートする前記第1スレッドの試みが、前記第1ブロックのオーバーフローを引き起こしたことが確定した際、前記複数のブロックから選択した第2ブロックを前記第1スレッドへ割り当てる機能と、前記第2ブロックを前記第1スレッドへ割り当てることは、前記第1スレッドがオブジェクトを前記第1ブロック内でアロケートすることをそれ以降試みないようにすべく行われることと、
    をコンピュータによって実現させる、コンピュータ読み取り可能媒体。
  29. 請求項28に記載のコンピュータ読み取り可能媒体において、前記コンピュータ読み取り可能媒体は、CD−ROM、コンピュータ・ディスク、コンピュータ・テープ及びコンピュータ・ディスク・ドライブのうちのいずれか1つであるコンピュータ読み取り可能媒体。
  30. マルチスレッド・コンピューティング・システム内の共有メモリをアロケートするためのコンピュータ・プログラムであって、前記マルチスレッド・コンピューティング・システムが第1スレッド及び第2スレッドを少なくとも有するコンピュータ・プログラムを格納するコンピュータ読み取り可能媒体であって、前記コンピュータ・プログラムは、
    前記共有メモリを、第1サイズの複数のブロックと、第2サイズの少なくとも1つのブロックとを含む複数のブロックへ分割する機能と、
    前記第1サイズの複数のブロックから選択した第1ブロックを、第1オブジェクトを前記第1ブロック内でアロケートすることを試みるべく設けられた第1スレッドへ割り当てる機能と、
    前記第1サイズの複数のブロックから選択した第2ブロックを、第2オブジェクトを前記第2ブロック内でアロケートすることを試みるべく設けられた第2スレッドへ割り当てる機能と、
    前記第1ブロック及び第2ブロックの一方がオーバーフローした時を決定する機能と、
    前記第2サイズの第3ブロックが利用可能であるか否かを決定する機能と、
    前記第3ブロックが利用可能であることが確定し、かつ前記第1ブロックがオーバーフローしたことが確定した際、前記第3ブロックを第1スレッドへ割り当てる機能と、
    前記第3ブロックが利用可能であることが確定し、かつ前記第2ブロックがオーバーフローしたことが確定した際、前記第3ブロックを第2スレッドへ割り当てる機能と
    をコンピュータによって実現させる、コンピュータ読み取り可能媒体。
  31. 請求項30に記載のコンピュータ読み取り可能媒体において、前記コンピュータ読み取り可能媒体は、CD−ROM、コンピュータ・ディスク、コンピュータ・テープ及びコンピュータ・ディスク・ドライブからなるグループから選択した1つであるコンピュータ読み取り可能媒体。
  32. マルチスレッド・コンピューティング・システム内の共有メモリをアロケートすべくコンピュータに実装する方法であって、前記マルチスレッド・コンピューティング・システムが第1スレッド及び第2スレッドを少なくとも有する方法において、
    前記メモリを複数のブロックへ分割する工程と、前記複数のブロックは第1ブロック及び第2ブロックを含み、前記第1ブロックは前記第2ブロックよりサイズが実質的に小さく、前記第1ブロックが1KBから4KBの範囲のサイズを有し、前記第2ブロックが16KBから32KBの範囲のサイズを有することと、
    前記第1ブロックを前記第1スレッドがアクセスできるように割り当てる工程と、前記第1スレッドは低速アロケーティングスレッドであり、第1オブジェクトを前記第1ブロック内でアロケートすることを試みるべく設けられており、複数のスレッドを含むように構成されている第1グループと関連付けられていることと、
    前記第2ブロックを前記第2スレッドがアクセスできるように割り当てる工程と、前記第2スレッドは高速アロケーティングスレッドであり、第2オブジェクトを前記第2ブロック内でアロケートすることを試みるべく設けられ、前記第1オブジェクトを前記第2ブロック内でアロケートすることを試みるべく前記第1スレッドは設けられておらず、前記第2オブジェクトを前記第1ブロック内でアロケートすることを試みるべく前記第2スレッドは設けられていないこと
    を含む方法。
JP18601599A 1998-06-30 1999-06-30 マルチスレッド仮想マシン内におけるメモリ・アロケーションの方法及び装置 Expired - Lifetime JP4511653B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/108047 1998-06-30
US09/108,047 US6209066B1 (en) 1998-06-30 1998-06-30 Method and apparatus for memory allocation in a multi-threaded virtual machine

Publications (3)

Publication Number Publication Date
JP2000222281A JP2000222281A (ja) 2000-08-11
JP2000222281A5 JP2000222281A5 (ja) 2006-08-10
JP4511653B2 true JP4511653B2 (ja) 2010-07-28

Family

ID=22319971

Family Applications (1)

Application Number Title Priority Date Filing Date
JP18601599A Expired - Lifetime JP4511653B2 (ja) 1998-06-30 1999-06-30 マルチスレッド仮想マシン内におけるメモリ・アロケーションの方法及び装置

Country Status (5)

Country Link
US (2) US6209066B1 (ja)
EP (1) EP0969379A3 (ja)
JP (1) JP4511653B2 (ja)
KR (1) KR100686418B1 (ja)
CN (1) CN1205549C (ja)

Families Citing this family (75)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7146479B2 (en) * 2001-07-18 2006-12-05 City U Research Limited Method and apparatus of storage allocation/de-allocation in object-oriented programming environment
GB9825102D0 (en) * 1998-11-16 1999-01-13 Insignia Solutions Plc Computer system
US6173442B1 (en) * 1999-02-05 2001-01-09 Sun Microsystems, Inc. Busy-wait-free synchronization
GB9921719D0 (en) * 1999-09-14 1999-11-17 Tao Group Ltd Thread locking
JP3608993B2 (ja) * 1999-11-10 2005-01-12 富士通株式会社 コンパイラ装置及びコンパイラプログラムを記録した記録媒体
US6681306B1 (en) * 1999-11-29 2004-01-20 Sun Microsystems, Inc. Method and apparatus for increasing scavenging garbage collection effectiveness
US6594678B1 (en) * 2000-01-05 2003-07-15 Sun Microsystems, Inc. Methods and apparatus for improving locality of reference through memory management
US6807620B1 (en) * 2000-02-11 2004-10-19 Sony Computer Entertainment Inc. Game system with graphics processor
JP3611295B2 (ja) * 2000-03-09 2005-01-19 インターナショナル・ビジネス・マシーンズ・コーポレーション コンピュータシステム、メモリ管理方法及び記憶媒体
US6427195B1 (en) * 2000-06-13 2002-07-30 Hewlett-Packard Company Thread local cache memory allocator in a multitasking operating system
US6507903B1 (en) * 2000-06-20 2003-01-14 International Business Machines Corporation High performance non-blocking parallel storage manager for parallel software executing on coordinates
US6832378B1 (en) * 2000-06-20 2004-12-14 International Business Machines Corporation Parallel software processing system
US6505275B1 (en) * 2000-07-24 2003-01-07 Sun Microsystems, Inc. Method for scalable memory efficient thread-local object allocation
US7051056B2 (en) 2000-09-13 2006-05-23 Veritas Operating Corporation Conservative garbage collectors that can be used with general memory allocators
US6824064B2 (en) * 2000-12-06 2004-11-30 Mobile-Mind, Inc. Concurrent communication with multiple applications on a smart card
US7231500B2 (en) * 2001-03-22 2007-06-12 Sony Computer Entertainment Inc. External data interface in a computer architecture for broadband networks
US7093104B2 (en) * 2001-03-22 2006-08-15 Sony Computer Entertainment Inc. Processing modules for computer architecture for broadband networks
US7516334B2 (en) * 2001-03-22 2009-04-07 Sony Computer Entertainment Inc. Power management for processing modules
US7233998B2 (en) 2001-03-22 2007-06-19 Sony Computer Entertainment Inc. Computer architecture and software cells for broadband networks
US6526491B2 (en) * 2001-03-22 2003-02-25 Sony Corporation Entertainment Inc. Memory protection system and method for computer architecture for broadband networks
US7350200B2 (en) * 2001-03-29 2008-03-25 Intel Corporation Method and system of controlling dynamically compiled native code size
US7228366B2 (en) * 2001-06-29 2007-06-05 Intel Corporation Method and apparatus for deterministic removal and reclamation of work items from an expansion bus schedule
US7334228B2 (en) 2001-07-27 2008-02-19 International Business Machines Corporation Runtime-resource management
US7487505B2 (en) * 2001-08-27 2009-02-03 Intel Corporation Multithreaded microprocessor with register allocation based on number of active threads
US7243229B2 (en) * 2001-10-02 2007-07-10 Hitachi, Ltd. Exclusive access control apparatus and method
US8028132B2 (en) 2001-12-12 2011-09-27 Telefonaktiebolaget Lm Ericsson (Publ) Collision handling apparatus and method
US7143413B2 (en) * 2002-05-15 2006-11-28 Hewlett-Packard Development Company, L.P. Method and system for allocating system resources among applications using weights
US7322034B2 (en) 2002-06-14 2008-01-22 Hewlett-Packard Development Company, L.P. Method and system for dynamically allocating computer system resources
US6883081B2 (en) * 2002-07-30 2005-04-19 Veritas Operating Corporation Storage management software bridges
US6904511B2 (en) * 2002-10-11 2005-06-07 Sandbridge Technologies, Inc. Method and apparatus for register file port reduction in a multithreaded processor
US7363626B2 (en) * 2003-03-24 2008-04-22 Sun Microsystems, Inc. Thread level application partitioning
US7444547B2 (en) * 2003-06-19 2008-10-28 International Business Machines Corproation Method, system, and product for programming in a simultaneous multi-threaded processor environment
US6912482B2 (en) * 2003-09-11 2005-06-28 Veritas Operating Corporation Data storage analysis mechanism
US7325118B2 (en) * 2003-09-30 2008-01-29 Samsung Electronics, Co., Ltd. Method and apparatus for executing dynamic memory management with object-oriented program
WO2005081647A2 (en) * 2004-03-02 2005-09-09 Hismartech Co., Ltd. Method, system and a computer-readable recording medium for controlling storage of data in memory and system therefor
US8224639B2 (en) 2004-03-29 2012-07-17 Sony Computer Entertainment Inc. Methods and apparatus for achieving thermal management using processing task scheduling
US7257811B2 (en) 2004-05-11 2007-08-14 International Business Machines Corporation System, method and program to migrate a virtual machine
US7546588B2 (en) * 2004-09-09 2009-06-09 International Business Machines Corporation Self-optimizable code with code path selection and efficient memory allocation
JP4144609B2 (ja) * 2004-09-29 2008-09-03 ソニー株式会社 情報処理装置、メモリ領域管理方法、並びにコンピュータ・プログラム
US7350047B2 (en) * 2004-10-07 2008-03-25 International Business Machines Corporation Memory overflow management
JP4641176B2 (ja) * 2004-11-08 2011-03-02 三菱電機株式会社 アプリケーション処理装置及びアプリケーション処理プログラム
US7743233B2 (en) * 2005-04-05 2010-06-22 Intel Corporation Sequencer address management
US10026140B2 (en) 2005-06-10 2018-07-17 Nvidia Corporation Using a scalable graphics system to enable a general-purpose multi-user computer system
US20070033240A1 (en) * 2005-08-04 2007-02-08 International Business Machines Corporation Scheduling garbage collection
US20070091088A1 (en) * 2005-10-14 2007-04-26 Via Technologies, Inc. System and method for managing the computation of graphics shading operations
US8144149B2 (en) 2005-10-14 2012-03-27 Via Technologies, Inc. System and method for dynamically load balancing multiple shader stages in a shared pool of processing units
US20070271560A1 (en) * 2006-05-18 2007-11-22 Microsoft Corporation Deploying virtual machine to host based on workload characterizations
US8688920B2 (en) 2007-05-14 2014-04-01 International Business Machines Corporation Computing system with guest code support of transactional memory
US8117403B2 (en) * 2007-05-14 2012-02-14 International Business Machines Corporation Transactional memory system which employs thread assists using address history tables
US9009452B2 (en) 2007-05-14 2015-04-14 International Business Machines Corporation Computing system with transactional memory using millicode assists
US8095741B2 (en) * 2007-05-14 2012-01-10 International Business Machines Corporation Transactional memory computing system with support for chained transactions
US8095750B2 (en) * 2007-05-14 2012-01-10 International Business Machines Corporation Transactional memory system with fast processing of common conflicts
US8321637B2 (en) * 2007-05-14 2012-11-27 International Business Machines Corporation Computing system with optimized support for transactional memory
JP4935626B2 (ja) * 2007-10-30 2012-05-23 富士通株式会社 制御プログラム及び方法並びにコンピュータ
US20090189896A1 (en) * 2008-01-25 2009-07-30 Via Technologies, Inc. Graphics Processor having Unified Shader Unit
US20090217280A1 (en) * 2008-02-21 2009-08-27 Honeywell International Inc. Shared-Resource Time Partitioning in a Multi-Core System
US20090228537A1 (en) * 2008-03-07 2009-09-10 Branda Steven J Object Allocation System and Method
US8566524B2 (en) 2009-08-31 2013-10-22 International Business Machines Corporation Transactional memory system with efficient cache support
KR101109009B1 (ko) * 2009-11-17 2012-01-31 선문대학교 산학협력단 비정규 리덕션의 병렬화 방법
EP2513810B1 (en) * 2009-12-14 2016-02-17 Citrix Systems, Inc. Methods and systems for communicating between trusted and non-trusted virtual machines
KR101748441B1 (ko) * 2010-10-08 2017-06-19 삼성전자주식회사 거짓 공유 검출 장치 및 방법
US8601193B2 (en) 2010-10-08 2013-12-03 International Business Machines Corporation Performance monitor design for instruction profiling using shared counters
US8589922B2 (en) 2010-10-08 2013-11-19 International Business Machines Corporation Performance monitor design for counting events generated by thread groups
US8489787B2 (en) 2010-10-12 2013-07-16 International Business Machines Corporation Sharing sampled instruction address registers for efficient instruction sampling in massively multithreaded processors
US9329988B2 (en) * 2011-08-19 2016-05-03 Nvidia Corporation Parallel dynamic memory allocation using a nested hierarchical heap
JP2013191202A (ja) * 2012-02-14 2013-09-26 Ricoh Co Ltd マルチコアプロセッサ
US9223699B2 (en) * 2013-03-15 2015-12-29 Intel Corporation Cache management in managed runtime environments
CN103440203B (zh) * 2013-08-26 2017-07-25 上海斐讯数据通信技术有限公司 一种共享内存分配方法
WO2016046911A1 (ja) * 2014-09-24 2016-03-31 株式会社日立製作所 ストレージシステム及びストレージシステムの管理方法
US9720819B2 (en) * 2015-06-12 2017-08-01 Intel Corporation Concurrent, moving, garbage collector
EP3113026B1 (en) * 2015-06-29 2019-07-24 aicas GmbH Automatic memory management using a memory management unit
US10353747B2 (en) * 2015-07-13 2019-07-16 Futurewei Technologies, Inc. Shared memory controller and method of using same
CN107239406B (zh) * 2016-03-29 2021-03-09 斑马智行网络(香港)有限公司 用于垃圾回收的并行标记处理方法及装置
US10838656B2 (en) * 2016-12-20 2020-11-17 Mediatek Inc. Parallel memory access to on-chip memory containing regions of different addressing schemes by threads executed on parallel processing units
US11436033B2 (en) * 2019-10-11 2022-09-06 International Business Machines Corporation Scalable virtual memory metadata management

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5088036A (en) * 1989-01-17 1992-02-11 Digital Equipment Corporation Real time, concurrent garbage collection system and method
US5247634A (en) * 1990-03-20 1993-09-21 Hewlett-Packard Company Method of managing memory allocation by association of memory blocks with a tree structure
JP3309425B2 (ja) * 1992-05-22 2002-07-29 松下電器産業株式会社 キャッシュ制御装置
JPH0635747A (ja) * 1992-07-17 1994-02-10 Mitsubishi Electric Corp デバッグ支援装置
JPH07200390A (ja) * 1993-12-28 1995-08-04 Toshiba Corp データアクセス方法
KR970006412B1 (ko) * 1993-12-30 1997-04-28 엘지전자 주식회사 멀티 프로세서 시스템의 메모리 공유 액세스 제어 장치
US5940869A (en) * 1995-06-07 1999-08-17 International Business Machines Corporation System and method for providing shared memory using shared virtual segment identification in a computer system
KR100429699B1 (ko) * 1995-07-18 2005-08-31 시바 스페셜티 케미칼스 홀딩 인크. 염료혼합물,이의제조방법및이를사용한염색또는날염방법
US5727178A (en) * 1995-08-23 1998-03-10 Microsoft Corporation System and method for reducing stack physical memory requirements in a multitasking operating system
US5706515A (en) * 1996-03-25 1998-01-06 Sun Microsystems, Inc. System and method for implementing an atomic wait for notification operation
US5893159A (en) * 1997-10-22 1999-04-06 International Business Machines Corporation Methods and apparatus for managing scratchpad memory in a multiprocessor data processing system

Also Published As

Publication number Publication date
KR100686418B1 (ko) 2007-02-23
JP2000222281A (ja) 2000-08-11
US6209066B1 (en) 2001-03-27
CN1205549C (zh) 2005-06-08
KR20000006565A (ko) 2000-01-25
CN1248742A (zh) 2000-03-29
EP0969379A3 (en) 2005-08-03
US6510498B1 (en) 2003-01-21
EP0969379A2 (en) 2000-01-05

Similar Documents

Publication Publication Date Title
JP4511653B2 (ja) マルチスレッド仮想マシン内におけるメモリ・アロケーションの方法及び装置
US6874074B1 (en) System and method for memory reclamation
US7092978B2 (en) Space-efficient, depth-first parallel copying collection technique making use of work—stealing on the same structures that maintain the stack of items to be scanned
US7165255B2 (en) Method and apparatus for managing surplus memory in multitasking system
US6253215B1 (en) Method, apparatus, and article of manufacture for facilitating resource management for applications having two types of program code
US5809554A (en) User control of multiple memory heaps
US6460126B1 (en) Computer resource management system
US7882505B2 (en) Method and apparatus for switching between per-thread and per-processor resource pools in multi-threaded programs
US7945911B1 (en) Barrier synchronization method and apparatus for work-stealing threads
US5899994A (en) Flexible translation storage buffers for virtual address translation
US7136887B2 (en) Method and mechanism for finding references in a card in time linear in the size of the card in a garbage-collected heap
US9852054B2 (en) Elastic caching for Java virtual machines
US7587566B2 (en) Realtime memory management via locking realtime threads and related data structures
EP1234238B1 (en) Method and apparatus for increasing scavenging garbage collection effectiveness
US7412580B1 (en) Concurrent incremental garbage collector with a card table summarizing modified reference locations
US7043509B2 (en) Parallel non-contiguous allocation and card parsing
JPH10254756A (ja) リファレンスされたオブジェクトを管理するための3状態リファレンスの使用
JP2006172494A (ja) プログラム制御装置、プログラム制御方法、およびプログラム記録媒体
US7870171B2 (en) Method and system for garbage collection in a multitasking environment
CN114051610A (zh) 基于arena的存储器管理
US6965905B2 (en) Lock-free, parallel remembered sets
JP2006172495A (ja) プログラム制御装置、プログラム制御方法、およびプログラム記録媒体
US7523284B1 (en) Method and apparatus for providing memory management within a system management mode
US7058781B2 (en) Parallel card table scanning and updating
JP2004503869A (ja) モジュール式ガーベッジコレクタを実現するための方法および装置

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060622

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060622

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090918

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20091006

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20091211

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20091216

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100401

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: 20100420

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100507

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130514

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4511653

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130514

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term