DESCRIPTION
INFORMATION PROCESSING APPARATUS, MEMORY AREA MANAGEMENT
METHOD, AND COMPUTER PROGRAM
Technical Field
[0001]
The present invention relates to an information
processing apparatus, a memory area management method, and a
computer program. More specifically, the present invention
relates to an information processing apparatus, a memory
area management method, and a computer program for
allocating an appropriate memory area and performing a
memory management process in an arrangement where a
plurality of threads reference and update the memory area in
parallel.
Background Art
[0002]
When a plurality of data processing programs are
executed on a single operation system (OS) or a plurality of
operating systems, hardware common to the systems, namely,
such as a CPU or a memory, is successively switched in time
sequence.
[0003]
Scheduling of processes (tasks) of a plurality of
operating systems is executed by a partition management
software program, for example. If an OS(α) and an OS(ß)
coexist in a single system with the process of OS(a) being a
partition A and the process of OS(P) being a partition B,
the partition management software program determines the
scheduling of the partition A and the partition B, and
executes the process of the operating systems with the
hardware resources allocated based on the determined
scheduling.
[0004]
Patent Document I discloses a task management technique
of a multi OS system. According to the disclosure, tasks to
be executed by a plurality of OS's are scheduled with a
priority placed on a process having urgency.
[0005]
When a plurality of programs are executed on at least
one operating system (OS), a plurality of threads, each
defined as a program execution unit, are present, and each
thread uses a memory as a common resource. If an attempt is
made to release, to another thread, a particular memory area
currently being accessed by a given thread, an access error
can be triggered. In known arts, error triggering is
prevented by setting an interrupt disabled duration. The
setting of the interrupt disabled duration leads to another
problem such as a process delay.
[Patent Document 1] Japanese Unexamined Patent Application
Publication No. 2003-345612
Disclosure of the Invention
Problems to Be Solved by the Invention
[0006]
The present invention has been developed in view of the
above-mentioned problem, and it is an object of the present
invention to provide an information processing apparatus, a
memory area management method, and a computer program for
allocating an appropriate memory area and performing a
memory management process in an access-error free manner in
an arrangement where a plurality of threads reference and
update the memory area in parallel.
Means for Solving the Problems
[0007]
In accordance with a first aspect of the present
invention, an information processing apparatus includes a
thread manager for managing thread information on a per data
processing unit basis, and a memory area manager for
managing a memory area. The thread manager stores, as
thread management information, a thread list containing
entry time information that is recorded on a per thread
basis as function call time of an operating system from a
data processing program. The memory area manager stores, as
memory area management information, a release queue
containing release request time that is recorded on an area
unit basis concerning a release-requested but not yet
released memory area, compares the release request time set
in each queue component contained in the release queue with
the oldest entry time of each queue component in the thread
list during a memory area allocation process, and allocates
the memory area corresponding to the queue component having
the release request time set prior to the oldest entry time.
[0008]
In the information processing apparatus of one
embodiment of the present invention, the thread manager
generates a thread list corresponding to each of a plurality
of processors, records the oldest entry time contained in
entry time information set in thread information contained
in the thread list, onto a header of each thread list, and
manages the recorded information set as being referenced by
another processor.
[0009]
In the information processing apparatus of one
embodiment of the present invention, the memory area manager
references all the oldest entry time information set in the
header of the thread list corresponding to the processor
managed by the thread manager, selects the oldest of the
oldest entry time from the oldest entry time information set
in the headers of the thread list corresponding to all
processors, compares the selected oldest entry time with the
release request time set in each queue component contained
in the release queue, and allocates a memory area
corresponding to the queue component having the release
request time set prior to the selected oldest entry time.
[0010]
In the information processing apparatus of one
embodiment of the present invention, the thread manager
records, on the header of the thread list and a list
component, identification information of another list
component, organizes the thread list as a list that permits
each component to be successively acquired from the header,
and updates the identification information set in one of the
header and the list component during one of the entry of the
thread and the retirement of the thread.
[0011]
In the information processing apparatus of one
embodiment of the present invention, the memory area manager
records, on the header of the release queue and a queue
component, identification information of another queue
component, organizes the release queue as a list that
permits each queue component to be successively acquired
from the header, and updates the identification information
set in one of the header and the queue component during one
of the setting of a new queue and the deleting of a queue. [0012]
In the information processing apparatus of one
embodiment of the present invention, the memory area manager
performs a memory area management process on a per heap unit
basis, the heap unit as a memory area having a finite size
set corresponding to each processor, stores, as the memory
area management information, a release queue containing
release request time that is recorded on a heap unit basis
concerning a release-requested but not yet released heap,
and allocates, during a memory area allocation process, the
memory area that is recorded on a per heap unit basis in the
queue component contained in the release queue.
[0013]
In the information processing apparatus of one
embodiment of the present invention, the memory area manager
examines a weak pointer chain, composed of a weak pointer
referencing the memory area corresponding to the queue
component contained in the release queue, and if no weak
pointer is present in the weak pointer chain, discards the
queue component from the release queue, and releases the
memory area corresponding to the queue component.
[0014]
In the information processing apparatus of one
embodiment of the present invention, the memory area manager
examines a retirement flag of the memory area contained in a
weak pointer chain, composed of a weak pointer referencing
the memory area corresponding to the queue component
contained in the release queue and the memory area
containing a reference area of the weak pointer, and if the
retirement flag indicates a retired status, discards the
queue component from the release queue, and releases the
memory area corresponding to the queue component.
[0015]
In accordance with a second aspect of the present
invention, a memory area management method includes a thread
management step of generating and updating a thread list
composed of thread information containing entry time
information that is recorded on a per thread basis as
function call time of an operating system from a data
processing program, a memory area management step of
generating and updating, as memory area management
information, a release queue containing release request time
that is recorded on a per area basis concerning a releaserequested
but not yet released memory area, and a memory
area allocation step of allocating the memory area
corresponding to the queue component having the entry
request time set prior to the oldest entry time, by
comparing the release request time set in each queue
component contained in the release queue with the oldest
entry time of each queue component in the thread list during
a memory area allocation process.
[0016]
In the memory area management method of one embodiment
of the present invention, the thread management step
includes generating the thread list corresponding to each of
a plurality of processors, recording the oldest entry time
contained in entry time information set in thread
information contained in the thread list, onto a header of
each thread list, and managing the recorded information set
as being referenced by another processor.
[0017]
In the memory area management method of one embodiment
of the present invention, the memory area allocation step
includes referencing all the oldest entry time information
set in the header of the thread list corresponding to a
processor, selecting the oldest of the oldest entry time
from the oldest entry time information set in the headers of
the thread list corresponding to all processors, comparing
the selected oldest entry time with the release request time
set in each queue component contained in the release queue,
and allocating a memory area corresponding to the queue
component having the release request time set prior to the
selected oldest entry time.
[0018]
In the memory area management method of one embodiment
of the present invention, the thread management step
includes recording, on the header of the thread list and a
list component, identification information of another list
component, organizing the thread list as a list that permits
each component to be successively acquired from the header,
and updating the identification information set in one of
the header and the list component during one of the entry of
the thread and the retirement of the thread.
[0019]
In the memory area management method of one embodiment
of the present invention, the memory area management step
includes recording, on the header of the release queue and a
queue component, identification information of another queue
component, organizing the release queue as a list that
permits each queue component to be successively acquired
from the header, and updating the identification information
set in one of the header and the queue component during one
of the setting of a new queue and the deleting of a queue.
[0020]
In the memory area management method of one embodiment
of the present invention, the memory area management step
includes performing a memory area management process on a
per heap unit basis, the heap unit as a memory area having a
finite size set corresponding to each processor, and storing,
as the memory area management information, a release queue
containing release request time that is recorded on a heap
unit basis concerning a release-requested but not yet
released heap, and the memory area allocation step includes
allocating the memory area that is recorded on a per heap
unit basis in the queue component contained in the release
queue.
[0021]
In the memory area management method of one embodiment
of the present invention, the memory area management step
includes examining a weak pointer chain, composed of a weak
pointer referencing the memory area corresponding to the
queue component contained in the release queue, and if no
weak pointer is present in the weak pointer chain,
discarding the queue component from the release queue, and
releasing the memory area corresponding to the queue
component.
[0022]
In the memory area management method of one embodiment
of the present invention, the memory area management step
includes examining a retirement flag of the memory area
contained in a weak pointer chain, composed of a weak
pointer referencing the memory area corresponding to the
queue component contained in the release queue and the
memory area containing a reference area of the weak pointer,
and if the retirement flag indicates a retired status,
discarding the queue component from the release queue, and
releasing the memory area corresponding to the queue
component.
[0023]
In accordance with a third aspect of the present
invention, a computer program for performing a memory area
management process, includes a thread management step of
generating and updating a thread list composed of thread
information containing entry time information that is
recorded on a per thread basis as function call time of an
operating system from a data processing program, an memory
area management step of generating and updating, as memory
area management information, a release queue containing
release request time that is recorded on a per area basis
concerning a release-requested but not yet released memory
area, and a memory area allocation step of allocating the
memory area corresponding to the queue component having the
entry request time set prior to the oldest entry time, by
comparing the release request time set in each queue
component contained in the release queue with the oldest
entry time of each queue component in the thread list during
a memory area allocation process.
[0024]
The computer program of the present invention is
provided, to a general-purpose computer system executing a
variety of program code, in a computer-readable storage
medium, such as a CD, a FD, or an MO, or via a communication
medium such as network. By providing the computer program
in a computer readable manner, the computer system performs
process responsive to the computer program.
[0025]
These and other features, and advantages of the present
invention will become obvious from the following description
of the present invention and the accompanying drawings. In
the context of the description of the present invention, the
system refers to a logical set of a plurality of apparatuses,
and is not limited to an apparatus that houses elements
within the same casing.
Advantages
[0026]
In accordance with embodiments of the present invention,
the thread list of the thread information containing the
entry time information that is recorded on a per thread
basis with a thread being as a data processing unit is
stored as the thread management information, and the release
queue containing the release request time that is recorded
on an area unit basis concerning a release-requested but not
yet released memory area is stored as the memory area
management information. The release request time set in
each queue component contained in the release queue is
compared with the oldest entry time of each queue component
in the thread list during the memory area allocation process
The memory allocation process is performed on only the
memory area corresponding to the queue component with the
release request time set prior to the oldest entry time.
Only a memory area that is not an access target in all
threads is reliably selected and subjected to the allocation
process. The memory area allocation process is safely
preformed in a manner free from the generation of access
error in each thread.
Brief Description of the Drawings
[0027]
[Fig. 1] Fig. 1 is a block diagram of an information
processing apparatus of the present invention.
[Fig. 2] Fig. 2 illustrates a processor module.
[Fig. 3] Fig. 3 illustrates the software structure of the
information processing apparatus of the present invention.
[Fig. 4] Fig. 4 illustrates an access process to a typical
memory area.
[Fig. 5] Fig. 5 illustrates an access process to a typical
memory area.
[Fig. 6] Fig. 6 illustrates information managed by a
thread manager in the information processing apparatus of
the present invention.
[Fig. 7] Fig. 7 illustrates in detail information managed
by the thread manager in the information processing
apparatus of the present invention.
[Fig. 8] Fig. 8 illustrates information managed by a
memory area manager in the information processing apparatus
of the present invention.
[Fig. 9] Fig. 9 is a flowchart illustrating the sequence
of a thread information entry process executed by the thread
manager in the information processing apparatus of the
present invention.
[Fig. 10] Fig. 10 illustrates in detail the thread
information entry process executed by the thread manager in
the information processing apparatus of the present
invention.
[Fig. 11] Fig. 11 is a flowchart illustrating the sequence
of a thread information retirement process executed by the
thread manager in the information processing apparatus of
the present invention.
[Fig. 12] Fig. 12 illustrates in detail the sequence of a
thread information retirement process executed by the thread
manager in the information processing apparatus of the
present invention.
[Fig. 13] Fig. 13 is a flowchart illustrating the sequence
of a memory area release request registration process
executed by the memory area manager in the information
processing apparatus of the present invention.
[Fig. 14] Fig. 14 is a flowchart illustrating in detail a
memory area allocation process executed by the memory area
manager in the information processing apparatus of the
present invention.
[Fig. 15] Fig. 15 illustrates the structure of a weak
pointer and a weak pointer chain.
[Fig. 16] Fig. 16 is a flowchart illustrating a pointer
value acquisition process of acquiring a value from the weak
pointer.
[Fig. 17] Fig. 17 is a flowchart illustrating a release
queue process (flush process) sequence in the structure
containing the weak pointer.
Best Mode for Carrying Out the Invention
[0028]
An information processing apparatus, a memory area
management method, and a computer program of the present
invention are described below with reference to the drawings,
[0029]
The hardware structure of the information processing
apparatus of the present invention is described below with
reference to Fig. 1. A processor module 101 includes a
plurality of processors (Processing Units), and processes
data in accordance with a variety of programs stored in a
ROM (Read-Only Memory) 104 and HDD 123, including operating
systems (OS's) and application programs running on the OS.
The processor module 101 will be described later with
reference to Fig. 2.
[0030]
In response to a command input via the processor module
101, a graphic engine 102 generates data to be displayed on
a screen of a display forming an output unit 122, for
example, performs a three-dimensional graphic drawing
process. A main memory (DRAM) 103 stores the program
executed by the processor module 101 and parameters that
vary in the course of execution of the program. These
elements are interconnected via a host bus 111 including a
CPU bus.
[0031]
The host bus 111 is connected to an external bus 112,
such as a PCI (Peripheral Component Interconnect/Interface)
bus via a bridge 105. The bridge 105 controls data
inputting and outputting between the host bus 111, the
external bus 112, a controller 106, a memory card 107, and
other devices.
[0032]
An input unit 121 inputs information to an input device,
such as a keyboard and a pointing device, operated by a user.
An output unit 122 includes an image output unit, such as
one of a liquid-crystal display and a CRT (cathode ray tube),
and an audio output device such as a loudspeaker.
[0033]
The HDD (Hard Disk Drive) 123 drives a hard disk loaded
therewithin, thereby recording or playing back a program to
be executed by the processor module 101 and information.
[0034]
A drive 124 reads data and programs stored in a loaded
removable recording medium 127, such as a magnetic disk, an
optical disk, a magneto-optic disk, a semiconductor memory,
or the like, and supplies the data and the programs to a
main memory (DRAM) 103 via an interface 113, the external
bus 112, the bridge 105, and the host bus 111.
[0035]
A connection port 125 connects to an external device
128, and may include a USB, an IEEE 1394 bus, or the like.
The connection port 125 is connected to the processor module
101 via the interface 113, the external bus 112, the bridge
105, and the host bus 111. A communication unit 126,
connected to a network, transmits data supplied from the HDD
123 or the like, and receives data from the outside.
[0036]
The structure of the processor module is described
below with reference to Fig. 2. As shown, a processor
module 200 includes a main processor group 201 including a
plurality of main processor units, and a plurality of subprocessor
groups 202 thorough 20n, each including a
plurality of sub-processor units. Each group further
includes a memory controller and a secondary cache. The
processor groups 201 through 20n, each including eight
processor units, for example, are connected via one of a
cross-bar architecture and a packet exchange network. In
response to a command of the main processor of the main
processor group 201, at least one sub-processor in the
plurality of sub-processor groups 202 through 20n is
selected to perform a predetermined program.
[0037]
The memory flow controller in each processor group
controls data inputting and data outputting to the main
memory 103 of Fig. I. The secondary cache serves as a
memory area for process data in each processor group.
[0038]
As previously discussed, when a plurality of programs
run on one or a plurality of operating systems (OS's), a
plurality of threads defined by a program execution unit are
present, and a memory as a resource common to the threads,
for example, the main memory (DRAM) of Fig. 1 is used. If
one thread attempts to perform a release process to a memory
area while the memory area is being accessed by another
thread, an access error is triggered. In known arts, the
triggering of the access error is prevented by setting an
interrupt disabled period, but the setting of the interrupt
disabled period leads to a secondary problem such as a
process delay.
[0039]
In accordance with the present invention, efficient
data processing is performed by executing an appropriate
memory management responsive to a thread. Referring to Fig.
3, a memory allocation and release process appropriate for
the thread is discussed in detail below.
[0040]
Fig. 3 illustrates a software stack in the information
processing apparatus of the present invention. The software
stack is composed of an operating system (OS) 310, and an
application program 320 executed on the operating system
(OS) 310. The operating system (OS) 310 includes a kernel
311 for executing multi-task control, file system management,
memory management, and an input and output process.
[0041]
The kernel 311 includes a thread manager (system call
dispatcher) 312, a memory area manager (heap management
module) 313 for executing management of a memory area, and
the other kernel module 314.
[0042]
In an object-oriented memory management process, a
resource is handled as an object, and the memory management
is performed based on the memory area having a finite size
called a heap. The memory area manager (heap management
module) 313 manages allocation of the object to the heap.
The memory area manager (heap management module) 313
releases a finite heap while efficiently allocating the
memory area (the heap) to each thread requesting the heap.
[0043]
A typical memory allocation process for allocating the
memory area to the thread is described below with reference
to Figs. 4 and 5. As shown in Fig. 4, a memory area x 351,
a memory area y 352, and a memory area z 353 set as objects
in Fig. 4 are accessible via an identification (ID) table
350 set as pointer information to the objects, by a thread
executing program.
[0044]
The kernel of the OS locks the ID table 350 to prevent
a second thread from accessing the memory area that is
currently being accessed by a first thread in order to avoid
accessing from the second thread. The second thread thus
cannot access memory until the ID table 350 is unlocked, and
processing must wait.
[0045]
Fig. 5 illustrates the ID table having a two-layered
structure. An ID table a 371 is used to access to a memory
area x 361 and a memory area z 362, etc., as objects. The
memory area z 362 in turn contain a second ID table b 372,
and permits accessing to a memory area a 363 and a memory
area b 364 by applying the second ID table b 372. In this
way, the kernel of the OS locks the ID table to prevent the
other thread from accessing the memory area. The other
thread thus cannot perform memory accessing until the lock
is released, and processing is thus delayed.
[0046]
Even if an individual area, such as one of the memory
area a 363 and the memory area b 364 of Fig. 5, is not used,
the kernel locks the ID table a 371 in the memory management
process during the use of the memory area x 361. As a
result, an available memory area cannot be effectively used.
[0047]
The present invention overcomes such an inefficient use
of memory, thereby permitting efficient memory allocation to
each thread. Such a process is carried out by the thread
manager (system call dispatcher) 312 and the memory area
manager (heap management module) 313 in the kernel 311 as
shown in Fig. 3. The process is described in detail below.
[0048]
The process of the thread manager (system call
dispatcher) 312 is described below with reference to Figs. 6
and 7 .
[0049]
The thread manager (system call dispatcher) 312
executes the threads for each of processors, provided in the
information processing apparatus for executing the thread.
The thread manager (system call dispatcher) 312 holds thread
management information on a per processor basis.
[0050]
The thread management information is described below
with reference to Fig. 6 and Fig. 7. Fig. 6 illustrates a
thread list forming the thread management information on a
per processor basis. Thread lists corresponding to only a
processor 1 and a processor 2 are shown. The thread manager
(system call dispatcher) 312 generates and holds the thread
list as management information corresponding to the
processor executing the thread.
[0051]
Fig. 6(a) illustrates the thread list as the thread
management information of the processor 1. The thread list
is composed of concatenation data of entry time information
of individual threads running in the hypervisor in the
processor 1, and the oldest entry time information. Fig.
6(b) illustrates the thread list as the thread management
information of the processor 2. The thread list is composed
of concatenation data of entry time information of
individual threads running in the hypervisor in the
processor 2, and the oldest entry time information. The
entry time information of the thread refers to function call
time of an operating system from an application program as a
variety of data processing programs. In any of the lists,
the oldest entry time information can be referenced by
another processor. As previously discussed, the thread is a
data processing execution unit corresponding to the logical
partition. To execute the thread, a variety of resources,
such as processors and memory areas, are reserved.
[0052]
When a processor for executing the thread is determined,
the available memory area is allocated to the thread of the
processor. The thread manager (system call dispatcher) 312
distributes threads among processors, generates a thread
list as thread information concerning memory area allocation,
and manages the threads.
[0053]
The hypervisor is a privileged layer arranged between
the logical partition and hardware, and manages the logical
partition. The thread is a process executed by the logical
partition. The thread, discussed as being executed by the
processor module with reference to Figs. 1 and 2, is
executed by the logical partition. Hardware resources
(resources: computing resources, a main processor, a subprocessor,
a memory, devices, etc. are allocated to each
logical partition, and the logical partition executes
processes using the resources allocated thereto. [0054]
The thread manager (system call dispatcher) 312 records
and holds the entry time information related to the thread
identified by the hypervisor arranged as the privileged
layer between the logical partition and the hardware.
[0055]
The thread list information held by the thread manager
(system call dispatcher) 312 is described in detail with
reference to Fig. 7. As described with reference to Fig. 6,
the thread list as the thread management information for
each processor includes the concatenation data of the entry
time information of each thread, and the oldest entry time
information. The management information includes a variable
400 set on a per processor basis and a variable 410 set on a
per thread basis as shown in Fig. 7. As previously
discussed, the entry time information of the thread
corresponds to the function call time of the operating
system from the application program functioning as a variety
of data processing programs.
[0056]
The variable 400 set on a per processor basis includes
a header (head) 401, and the oldest entry time (oldest_time)
402. The header (head) 401 contains pointer information to
a front element of the list. The oldest entry time
(oldest_time) 402 holds the oldest of the entry time
information in elements set in the list. The list is
appropriately updated in response to the entry of the thread,
and the retirement of the thread. If the oldest entry time
from among the elements forming the list is updated in the
update process, the oldest entry time (oldest_time) 402 is
also updated together. In view of the efficiency of access
process, the header (head) 401 and the oldest entry time
(oldest_time) 402 are stored in different cache lines. The
cache line storing the header (head) 401 store only
variables that require no referencing from another processor.
The cache line holding the oldest entry time (oldest_time)
402 can be referenced by another processor.
[0057]
The variable 410 set on a per thread basis includes
predecessor thread identification information (predecessor)
411 and entry time information (time) 412. The predecessor
thread identification information (predecessor) 411 is an
identifier (for example, a pointer) of preceding thread
information. As shown, the list contains thread information
in the order from the thread having the latest entry time to
the thread having the oldest entry time. Each of the thread
information is identified by the predecessor thread
identification information (predecessor) 411, and is then
acquired. The thread information of the front of the list
is identified by the header (head) 401 of the oldest entry
information. Since the end thread information has no
preceding thread, the [predecessor thread identification
information (predecessor)=NULL] is set. The entry time
(time) 412 indicates entry time of each thread.
[0058]
Referring to Fig. 8, information managed by the memory
area manager (heap management module) 313 is described below
As previously discussed, in the object-oriented memory
management process, the resource is handled as an object,
and the memory management is performed based on the memory
area having a finite size called heap. The element managing
the allocation of the object to the heap is the memory area
manager (heap management module) 313. The memory area
manager (heap management module) 313 releases the finite
heap while efficiently allocating the memory area (heap) to
each thread requesting heap.
[0059]
The memory area manager (heap management module) 313
holds heap management information set on a per processor
basis. In other words, the number of heap management
information units equals the number of processors. The heap
management information contains a release queue of Fig. 8.
The release queue is information of a memory area (heap),
which is not yet released although the release thereof has
been requested.
[0060]
As shown in Fig. 8, the structure of the release queue
held by the memory area manager (heap management module) 313
is discussed. The release queue of Fig. 8 is set as the
heap management information set on a per processor basis.
The release queues of Fig. 8 are individually arranged for
respective processors.
[0061]
The release queue is set as a concatenation list of
header information (release_queue_head) 451 and a queue
component 460. The queue component 460 contains a heap
identifier (heap_id) 461, release request time
(release_time) 462, successor queue information (successor)
463, and memory area information 464.
[0062]
The heap identifier (heap_id) 461 is heap
identification information set as a memory area on a per
processor basis. The release request time 462 indicates
request time of heap, namely, time at which the thread
issues a use request of heap. The successor queue
information (successor) 463 is a pointer to a subsequent
queue in the release queue. The memory area information 464
is access information to the memory area available to the
processor corresponding to the heap identifier (heap_id) 461.
[0063]
The header information (release_queue_head) 451
contains the heap identifier (heap_id), and is set as
information containing the pointer information of the front
queue. As shown, all queue components are acquired by
tracing the successor queue information (successor) 463 of
each queue component from the header information
(release_queue_head) 451.
[0064]
Available processors are allocated to each thread in a
resource allocation process, a heap area corresponding to
each processor is identified, and the thread is ready to be
executed. At this point of time, a queue component is set
in the release queue corresponding to the allocated
processor.
[0065]
In accordance with the present invention, the efficient
memory allocation to the thread is performed under the
control of the thread manager (system call dispatcher) 312
and the memory area manager (heap management module) 313 in
the kernel 311. The process of the thread manager (system
call dispatcher) 312 and the memory area manager (heap
management module) 313 in the kernel 311 is discussed with
reference to Fig. 9.
[0066]
The process of the thread manager (system call
dispatcher) 312 is described below with reference to Figs. 9
through 12. The thread manager (system call dispatcher) 312
executes the entry process of the thread information to and
the retirement process of the thread information from the
thread list described with reference to Figs. 6, and 7.
[0067]
The entry process of the thread information is
performed immediately after the application program calls a
function of the OS. More specifically, the thread for data
processing using the processor is generated when the
application program calls the function of the OS. The
thread is set on a standby state waiting for the release of
the memory area. The thread information corresponding to
the thread is newly set as the management information of the
thread manager (system call dispatcher) 312.
[0068]
The retirement process of the thread information is
performed immediately before control is handed over to the
application program with a system call process completed by
the OS. More specifically, the memory allocation process is
completed by the OS, and control is handed over to the
application program. The thread can be executed using the
processor and memory area allocated by the OS. When the
control is returned to the application program with the
system call completed by the OS, the memory area (heap) is
allocated to the thread. The thread manager (system call
dispatcher) 312 managing the thread information in the
memory area (heap) on the standby state deletes the thread
information from the thread list. This process is the
retirement process.
[0069]
The thread entry process sequence is described below
with reference to a flowchart of Fig. 9 and diagrams of Fig.
10. The thread entry process is carried out to add new
thread information 510 to the thread list as shown in Fig.
10. An addition location of the new thread information 510
of Fig. 10(a) is indicated by header information 501
contained in processor related data 500. In this addition
process, a thread list of Fig. 10 (b) is constructed. When
the new thread information 510 is added, a variety of
information in the existing thread list needs to be updated.
Fig. 9 is a flowchart of the update process.
[0070]
Each step of the flowchart of Fig. 9 is described below.
A series of steps of Fig. 9 is carried out in an interrupt
disabled state. In step S101, a variable [p] is set as an
identifier of the processor performing the entry process.
As previously discussed, the thread manager (system call
dispatcher) 312 manages the thread list on a per processor
basis. To identify the thread list for executing the thread
entry process, the variable [p] is set as an identifier of a
processor executing the entry process. In step S102, a
variable [thread] is set as an identifier of a processor
executing the retirement process. More specifically, the
variable thread is set as the identifier of the thread 510
of Fig. 10.
[0071]
In step S103, a variable [old_head] = the predecessor
thread identification information (predecessor_thread_id
[thread]=head[p]) is set.
This process step means that a value [headfp]] set for
the header 501 of Fig. 10 (a) is set for the predecessor
thread information 511 of the new thread information 510 and
that the value [head[p]] is set for a variable [old_head].
[0072]
In step S104, the variable [head[p]]=thread is set.
This process step means that the value set for the header
501 of Fig. 10 (a) is set as an identifier of the new thread
information 510 of the entering thread.
[0073]
In step S105, present time is set for a variable time
[thread]. This process step means that the present time is
set for entry time information 512 of the entry thread
information 510 of Fig. 10(a).
[0074]
It is determined in step S106 whether the variable
[old_head] set in step S103 is NULL. The variable
[old_head] set in step S103 is information that is set for
the header 501 of Fig. 10 (a) prior to the entry process. If
[NULL} is set for the header 501 of Fig. 10 (a) prior to the
entry process, no thread information was present in the
thread list, and the new thread information 510 of Fig. 10
is only thread information set for the thread list. The
oldest entry time 502 contained in the processor-related
data 500 of Fig. 10 (a) is set for the information set for
the entry time information 512 in step S105, namely, for
time [thread].
[0075]
If the variable [old_head] is not NULL, thread
information having entry time older than the new thread
information 510 is present in the thread list. Processing
is thus completed without updating the oldest entry time 502
contained in the processor-related data 500 shown in Fig.
10(a) .
[0076]
This entry process results in the thread list in which
the new thread information 510 of Fig. 10 (b) is set at a
location accessible by the header 501 of the processorrelated
data 500.
[0077]
Referring to Figs. 11 and 12, the thread retirement
process executed by the thread manager (system call
dispatcher) 312 is described in detail. The thread
retirement process is carried out immediately before control
is returned to the application program subsequent to the
completion of the system call process of the OS. When
control is returned to the application program after the
memory allocation process completed by the OS, the thread
can be executed using the processor and the memory area
allocated by the OS. When control is returned to the
application program after the memory allocation process
completed by the OS, the memory area (heap) is allocated to
the thread. The thread manager (system call dispatcher) 312
on the standby state managing the thread information deletes
the thread information from the thread list. The thread
retirement process has been discussed.
[0078]
The process sequence of the retirement process is
described below with reference to Fig. 11. A series of
steps of Fig. 11 is carried out in an interrupt disabled
state. Steps S201 and 202 of Fig. 11 are performed to
determine the processor and the thread executing the
retirement process. In step S201, a variable [p] is set for
an identifier executing the retirement process. In step
S202, a variable [thread] is set for an identifier of a
current thread executing the retirement process .
[0079]
In step S203, the location of the thread to be
processed in the retirement process is determined. More
specifically, whether to perform, steps S211 through S213 or
steps S221 through S224 is determined depending on the
location of the thread information for the retirement
process in the thread list. In other words, the process
becomes different depending on whether the thread
information to be retired is located as in Fig. 12(a) or Fig.
12(b) .
[0080]
As shown in Fig. 12(a), thread information 550 to be
processed in the retirement process is located at the front
end of the thread list, namely, at the location specified by
a header 541 of processor-related data 540. Header
information [head[p]] of the header 541 of the processorrelated
data 540 is set as identification information
[thread] of thread information 550 to be retired. The
answer to the determination in step S203 is yes, and steps
S211 through S213 are thus executed.
[0081]
As shown in Fig. 12(b), the thread information 550 to
be processed in the retirement process is at & location
other than the front of the thread list. In this case, the
header information [head[p]] of the header 541 of the
processor-related data 540 is not set as the identification
information [thread] of the thread information 550 to be
processed in the retirement process. The answer to the
determination in step S203 is no. Processing proceeds to
steps S221 through S224.
[0082]
As shown in Fig. 12(a), the thread information 550 is
now at the front of the thread list. In step 5211, header
information [head[p]] of the header 541 of the processorrelated
data 540 is set for predecessor thread
identification information [predecessor [thread]] 551 set
for the thread information 550 to be processed in the
retirement process. As shown in Fig. 12 (a), this process
step corresponds to the setting of information specifying
thread information 560 to the header 541 of the processorrelated
data 540. If no preceding thread is contained in
the thread information 550 to be processed in the retirement
process, [NULL] is set for the predecessor thread
identification information [predecessor [thread]] 551.
Likewise, [NULL] is set for the header information [head
[p]] of the header 541.
[0083]
It is determined in step S212 whether NULL is set for
the header information [head [p]] of the header 541 of the
processor-related data 540. If it is determined that NULL
is set, no thread information is present in the thread list
with the thread information 550 retired. In this case, 0 is
set for the oldest entry time [oldest_time] of the
processor-related data 540.
[0084]
If it is determined in step S212 that NULL is not set
for the header information [head [p]] of the header 541 of
the processor-related data 540, thread information is
present in the thread information even after the thread
information 550 is retired. In this case, processing ends
without rewriting the oldest entry time [oldest_time] of the
processor-related data 540.
[0085]
As shown in Fig. 12(b), the thread information 550 to
be processed in the retirement process is at a location
other than the front of the thread list. In step S221, a
variable [succ] is assumed to be a thread in immediate front
of the retirement thread within the thread list. It is
assumed herein that the front end of the list is a forward
end herein. In other words, the immediately front thread
corresponds to thread information 570 of Fig. 12 (b) .
[0086]
In step S222, predecessor thread identification
information [predecessor [succ]] of the thread immediately
preceding the retirement thread is updated as being
predecessor thread identification information [predecessor
[thread]] of the retirement thread. This process step
corresponds to the setting of information specifying thread
information 580 to the predecessor thread identification
information of the thread information 570 as shown in Fig.
12(b). If no preceding thread to the thread information 550
to be processed in the retirement process is present, [NULL]
is set for predecessor thread identification information
[predecessor [thread]] 551, and thus [NULL] is set for the
predecessor thread identification information of the thread
information 570.
[0087]
It is determined in step S223 whether NULL is set for
the predecessor thread identification information
[predecessor [thread]] of the retirement thread. If it is
determined that NULL is set, the retirement of the thread
information 550 means the retirement of the thread having
the oldest entry time. In this case, time [succ] is set for
the oldest entry time [oldest_time] of the processor-related
data 540, and processing ends. In other words, this process
is performed when the thread information 580 of Fig. 12(b)
is not present. Entry time 572 of the thread information
570 is set for the oldest entry time [oldest_time] of the
processor-related data 540.
[0088]
If it is determined in step S223 that NULL is not set
for the predecessor thread identification information
[predecessor [thread]] of the retirement thread, a thread
having the entry time older than the thread information 550
to be processed in the retirement process, namely, the
thread information 580 of Fig. 12(b), is present.
Processing ends without rewriting the oldest entry time
[oldest_time] of the processor-related data 540.
[0089]
The process of the memory area manager (heap management
module) 313 is described below with reference to Fig. 13.
The memory area manager (heap management module) 313 holds
the release queue of Fig. 8 as the heap management
information set on a per processor basis. The release queue
is information of a memory area (heap), which is not yet
released although the release thereof has been requested.
[0090]
The memory area manager (heap management module) 313
executes a release request registration process and a memory
area allocation process of the memory area (heap). The
release request registration process of the memory area
(heap) is executed to add a new queue to the release queue
described with reference to Fig. 8. The memory area
allocation process is executed to allocate the memory area
(heap) to the thread, and a queue is deleted from the
release queue as required.
[0091]
The release request registration process of the memory
area is described below with reference to a flowchart of Fig,
13. In step S301, a heap ID [hid] of a queue component set
as a new queue to the release queue is set as a heap
identifier of the release-requested memory area. As
previously discussed, the release queue as the management
information of the memory area is set for each heap
corresponding to a processor. The memory area manager (heap
management module) 313 releases and allocates the memory
area on a per heap basis. The memory area manager (heap
management module) 313 sets a release-requested heap ID as a
heap ID of the queue to be added to the release queue.
[0092]
In step S302, a release queue header
(release_queue_head [hid]) is set for subsequent queue
information (successor) of the new queue component. If it
is determined in step S303 that the value of the release
queue header (release_queue_head [hid]) is set to be equal
to the subsequent queue information (successor) of the
release area, pointer information of the new queue component
is input to the release queue header (release_queue__head
[hid]), and a variety of information, such as memory area
information, is set in the queue. Processing thus ends.
[0093]
If it is determined in step S303 that the value of the
release queue header (release_queue_head [hid]) is not equal
to the subsequent queue information (successor) of the
release area, processing returns to step S302 to repeat
steps S302 and S303. After checking that the value of the
release queue header (release_queue_head [hid]) is equal to
the subsequent queue information (successor) of the release
area, a variety of information, such as the memory area
information, is set to the queue. Processing thus ends.
[0094]
The determination in step S303 that the value of the
release queue header (release_queue_head [hid]) is not equal
to the subsequent queue information (successor) of the
release area is reached when another queue setting process
is concurrently performed by another processor with the
subsequent queue information (successor) of the release area
rewritten.
[0095]
A new queue is set in the release queue in response to
the determination in step S303 that the value of the release
queue header (release_queue_head [hid]) is equal to the
subsequent queue information (successor) of the release area,
The memory area corresponding to the process is reliably
reserved (assured).
[0096]
The sequence of the memory area (heap) allocation
process of the memory area manager (heap management module)
313 is described below with reference to Fig. 14. In step
S401, a variable [hid] is set to be equal to the identifier
of the processor executing the memory area allocation. The
memory area allocation process is performed on a per
processor basis. A processor to be memory-area allocated is
identified first.
[0097]
It is determined in step S402 whether an unused memory
area equal to the same size as the allocation-requested
memory area is present in the memory. More specifically,
the memory area manager (heap management module) 313 checks
whether the unused area having the same size as the memory
area size required by the thread is present in the memory.
If it is determined that the memory area is available,
processing proceeds to step S405. The memory area manager
(heap management module) 313 allocates the memory area as a
data processing memory area of the thread corresponding to
the processor having the identifier set in step S401.
[0098]
If it is determined in step S402 that the unused memory
of the same size as the allocation-requested memory area
size is not available from the memory, processing proceeds
to step S403. The memory area manager (heap management
module) 313 determines in step S403 whether the allocationrequested
memory area size is smaller than a predetermined
threshold. If it is determined that the allocationrequested
memory area size is smaller than the predetermined
threshold, processing proceeds to step S404. The memory
area manager (heap management module) 313 determines in step
S404 whether an unused memory area satisfying the
allocation-requested memory area size is present in a heap
area. If it is determined that the unused memory area
satisfying the allocation-requested memory area size is
present in the heap area, the memory area manager (heap
management module) 313 performs an allocation process of the
memory area set as an unused heap area in step S405. This
process step is carried out if the requested memory size is
smaller than the predetermined threshold and satisfied with
the allocation of only the unused heap area.
[0099]
If it is determined in step S403 that the allocationrequested
memory area size is not smaller than the
predetermined threshold, or if it is determined in step S404
that the unused area satisfying the allocation-requested
memory area size is not present in the heap area, subsequent
to the determination in step S403 that the allocation-
requested memory area size is smaller than the predetermined
threshold, steps S406 and subsequent steps are performed to
allocate the memory area. The process step in step S406 is
performed by referencing the release queue and the thread
list.
[0100]
In step S406, a variable [head] is set as the release
queue header (release_queue_head [hid]) and 0 is set for the
release queue header (release_queue_head [hid]).
[0101]
In step S407, a variable [time] is set to a minimum of
the oldest entry times, namely, the oldest of the oldest
entry times set in the thread list corresponding to all
processors.
[0102]
In step S408, the memory area manager (heap management
module) 313 compares the release request time (release_time)
set in each component traced from each header with a minimum
of the oldest entry times set in the thread list
corresponding to all processors having the time [time] set
in step S407, and selects only the request release time
(release_time) smaller than the value [time]. The memory
area manager (heap management module) 313 deletes the
selected request release time [release_time] from the
release queue, releases the memory areas corresponding to
these queues, and allocates the released memory areas to the
memory requesting thread.
[0103]
It is guaranteed that the memory area release-requested
prior to the minimum of the oldest entry times of all
processors is not an access target from all threads. By
selecting, releasing and then allocating the memory area,
the memory area allocation process is safely performed.
[0104]
In step S409, the subsequent queue information
(successor) of the end of the remaining queues other than
the queues deleted from the release queues in step S408 is
set for the release queue header (release_queue_head [hid]).
If it is determined in step S410 that the value of the
release queue header (release_queue_head [hid]) is set to be
equal to the subsequent queue information (successor) of the
end queue, a pointer for a front queue of the remaining
queues other than the queues deleted from the release queues
is set for the release queue header (release_queue_head
[hid]) in step S408.
[0105]
If it is determined in step S410 that the value of the
release queue header (release_queue_head [hid]) is not set
to be equal to the subsequent queue information (successor)
of the end queue, processing returns to step S409 to repeat
steps S409 and S410. After checking that the value of the
release queue header (release_queue_head [hid]) is set to be
equal to the subsequent queue information (successor) of the
end queue, the memory area manager (heap management module)
313 sets a variety of information, such as the memory area
information, to the queue. Processing thus ends.
[0106]
The determination in step S410 that the value of the
release queue header (release_queue_head [hid]) is not set
to be equal to the subsequent queue information (successor)
of the end queue may result when another queue setting and
deletion process is performed by another processor with the
subsequent queue information (successor) rewritten.
[0107]
The memory area manager (heap management module) 313
selects only a queue having the request release time
(release_time) set in the release queue smaller than a
minimum of the oldest entry times set in the thread list
corresponding to all processors. The memory area manager
(heap management module) 313 deletes the selected queues
from the release queues, releases the memory areas
corresponding to the queues, and allocates the memory areas
to the memory requesting thread. Only the memory area that
is not set as an access target for all threads is reliably
selected in the memory allocation process. The memory area
allocation process is thus performed to each thread in a
manner free from access error.
[0108]
A memory management process for supporting the
application of a weak pointer is described below. The
structure of the release queue held by the memory area
manager (heap management module) 313 has been discussed with
reference to Fig. 8. The release queue is set as a
concatenation list of the header information
(release_queue_head) 451 and the queue component 460. The
queue component 460 contains the heap identifier (head_id)
461, the release request time (release_time) 462, the
subsequent queue information (successor) 463, and the memory
area information 464.
[0109]
The heap identifier (heap_id) 461 is heap
identification information of the memory area set
corresponding to each processor. The release request time
(release_time) 462 indicates time at which heap request is
issued, namely, time at which the thread issues a use
request of heap. The subsequent queue information
(successor) 463 is a pointer to a subsequent queue in the
release queue. The memory area information 464 is access
information to the memory area available to the processor
corresponding to the heap identifier (heap_id) 461.
[0110]
The header information (release_queue_head) 451
contains the heap identifier (heap_id), and is set as
information containing the pointer information of the front
queue. As shown, all queue components are acquired by
tracing the subsequent queue information (successor) 463 of
each queue component from the header information
(release_queue_head) 451.
[0111]
Available processors are allocated to each thread in a
resource allocation process, a heap area corresponding to
each processor is identified, and the thread is on standby
waiting to be executed. At this point of time, a queue
component is set in the release queue corresponding to the
allocated processor.
[0112]
The release queue discussed with reference to Fig. 8 is
stored as the memory area management information. To
allocate the memory area, the release request time set for
each component of the queue in the release queue is compared
with the oldest entry time in the thread list. The memory
area allocation process is performed on the queue component
with the release request time set prior to the oldest entry
time, and is thus reliably performed to the memory area that
is not set as an access target in all threads. The memory
area allocation process is thus performed in each thread in
a manner free from access error.
[0113]
The value of a reference counter (rf) can be used to
determine whether the memory area is accessible. The
reference counter is set for each heap (memory area). If
the count of the reference counter is 1 or larger, the heap
(memory area) can be referenced. In other words, a thread
referencing the heap is present.
[0114]
To access the heap (memory area), a memory address is
acquired from a pointer object holding address information
of the heap (memory area). The acquired memory address is
then set in a register. Accessing is then performed in
accordance with the address set in the register. If another
thread attempts to access memory in the middle of this
process, memory information at the access destination can be
changed from planned one. However, reliable memory
accessing is performed by comparing the request release time
set in the release queue discussed with reference to Fig. 8
with the oldest entry time of the thread list.
[0115]
A weak pointer is one type of pointer objects. The
weak pointer is a special pointer that does not increase the
count of the above-mentioned reference counter (rf) set in
response to the heap (memory area). Although the weak
pointer references the heap (memory area) as standard
pointers do, the weak pointer is different from the standard
pointers in that the count of the reference counter (rf)
corresponding to the heap (memory area) does not account for
the weak pointer. Whether the reference counter (rf) is
referenced or not cannot be determined based on the value of
the reference counter. If the heap reference of the weak
pointer is released, address information corresponding to
the heap held by the weak pointer is updated to 0 (NULL).
More specifically, the weak pointer updates own pointer
information to 0 (NULL) without affecting the reference
counter of the heap.
[0116]
If the pointer information held by the weak pointer is
acquired and stored in a register during the memory
referencing, the information held by the weak pointer is
immediately replaced with 0 (NULL). Subsequent memory
accessing using the pointer information of the weak pointer
can be performed no longer, and the pointer information of
the weak pointer is missing. The modification of the
release queue of Fig. 8 previously discussed cannot be
performed smoothly. This problem is overcome as discussed
below.
[0117]
Reliable memory accessing and release queue updating
using the weak pointer are described below with reference to
Fig. 15. Fig. 15 illustrates a weak pointer and a heap
(memory area) 600 having a reference memory area referenced
by the weak pointer. The memory area information 464 of the
queue component 460 in the release queue of Fig. 8 has the
structure of the heap (memory area) 600 of Fig. 15.
[0118]
Weak pointers a-n reference the same reference memory
area. As shown, each of the weak pointers a-n contains a
pointer head including a pointer ID and a member variable as
discussed as follows:
(a) successor,
(b) predecessor, and
(c) object pointer.
[0119]
The object pointer is an object member variable as
memory area information to be referenced. A series of weak
pointers a-n references the same reference memory area, and
has the same object pointer.
[0120]
The successor and the predecessor are pointer variables
that chain the weak pointers having the same reference
memory area to the heap (memory area) having the reference
memory area referenced by the weak pointer. The successor
is identification information of one of a weak pointer and a
heap as a subsequent object. The predecessor is
identification information of one of a weak pointer and a
heap as a preceding object.
[0121]
The successor and the predecessor are set in the weak
pointer having the same reference memory area and the heap
(memory area) having the reference memory area referenced by
the weak pointer. A two-way link, namely, a chain is
constructed to mutually connect a series of weak pointers
and heaps. Such a chain is referred to as a weak pointer
chain.
[0122]
Information concerning a retirement flag and a
reference counter is set in the heap. As previously
discussed, the reference counter has a value responsive to a
reference environment of the memory area. The reference
counter does not account for reference information relating
to the weak pointer but that of the pointers other than the
weak pointer. The retirement flag is used to determine
whether the reference counter is not referenced by the
pointers including the weak pointer, in other words, whether
the thread is retired. The retirement flag is set to [1] if
the thread is retired, and set to [0] if the thread is
unretired. In an initialization process allocating a new
memory, the retirement flag is set to [0].
[0123]
The weak pointer chain is thus constructed. A pointer
value is acquired from the weak pointer. More specifically,
an object pointer as an object member variable corresponding
to an address required to reference the reference memory
area is acquired. The acquisition process is described
below with reference to a flowchart of Fig. 16.
[0124]
It is determined in step S501 in the acquisition
process of the pointer value from the weak pointer whether
the following conditions (1) and (2) are satisfied.
Condition (1) is that the object pointer of the weak pointer,
namely, the object member variable is non-zero. Condition
(2) is that the value of the reference counter (rf) set in
the heap linked by the weak pointer chain is equal to or
greater than 1.
[0125]
If it is determined that the two conditions are
satisfied, processing proceeds to step S502. The object
pointer as the object member variable corresponding to the
address required to reference the reference memory area set
in the weak pointer is then returned. If it is determined
that the two conditions are not satisfied, processing
proceeds to step S503 to return [0].
[0126]
If it is determined that the object pointer of the weak
pointer, namely, the object member variable is zero, or if
it is determined that the count of the reference counter
(rf) set in the heap linked by the weak pointer chain is 0,
0 is returned in step S503. If the count of the reference
counter (rf) is zero, referencing is not performed by the
pointers other than the weak pointer. However, whether
referencing is performed by the weak pointer cannot be
determined. If the pointer value is acquired from the weak
pointer, the object pointer of the weak pointer is set to
zero. Memory accessing using the pointer information of the
weak pointer can be performed no longer. With the pointer
information of the weak pointer missing, the updating of the
release queue cannot be smoothly updated. To preclude this
problem, the pointer value is not acquired under this
condition.
[0127]
A flush process of the release queue is described below
with reference to Fig. 17. The release queue has been
discussed with reference to Fig. 8, and is managed by the
memory area manager (heap management module) 313. As
previously discussed, in the object-oriented memory
management process, the resource is handled as an object,
and the memory management is performed based on the memory
area having a finite size called heap. The element managing
the allocation of the object to the heap is the memory area
manager (heap management module) 313. The memory area
manager (heap management module) 313 appropriately releases
the finite heap while efficiently allocating the memory area
(heap) to each thread requesting heap.
[0128]
The memory area manager (heap management module) 313
holds heap management information set on a per processor
basis. In other words, the number of heap management
information units equals the number of processors. The heap
management information contains the release queue of Fig. 8.
The release queue is information of a memory area (heap),
which is not yet released although the release thereof has
been requested.
[0129]
A special process is performed in the flushing of the
release queue, namely, the updating process in the
arrangement containing the weak pointer. The release queue
flush process is described below with reference to a
flowchart of Fig. 17. The process of Fig. 17 is
successively performed on all objects (release queue
components) contained in the release queue.
[0130]
In step S601, the release queue is emptied. More
specifically, the front queue of the header information
(release_queue_head) 451 of Fig. 8 is emptied, and the queue
is disconnected.
[0131]
In step S602, the release time of the object (release
queue component) set in the release queue to be processed,
namely, the request release time (release_time) is compared
with the oldest entry time set in the thread list
corresponding to the processor. If it is determined that
the request release time (release_time) is smaller than the
oldest entry time, processing proceeds to step S603.
[0132]
It is determined in step S603 whether one of the
following conditions (a) and (b) is satisfied.
The condition (a) is that the retirement flag set in
the heap (memory area) identified by the heap ID of the
object (release queue component) to be processed is set to
be a retired state.
The condition (b) is that no weak pointer is present in
the weak pointer chain set corresponding to the heap (memory
area), in other words, that the weak pointer chain is empty.
[0133]
If one of the above-referenced conditions (a) and (b)
is satisfied, processing proceeds to step S604. The object
is discarded. In other words, the memory area corresponding
to the object set in the release queue is released and the
object (release queue component) is deleted from the release
queue.
[0134]
If it is determined in step S603 that none of the
conditions (a) and (b) is satisfied, processing proceeds to
step S621. The value of the object pointer as the object
member variable of the weak pointer contained in the weak
pointer chain set corresponding to the heap is set to [0] .
In step S622, the retirement flag is set to [1]. In step
5623, present time is entered for the release time of the
object (release queue component) set at the release queue,
namely, the request release time (release_time). In step
5624, the object (release queue component) is set again to
the release queue .
[0135]
If it is determined in step S602 that the release time
of the object (release queue component) set in the release
queue to be processed, namely, the request release time
(release_time) is not smaller than the oldest entry time set
in the thread list corresponding to the processor,
processing proceeds to step S611. It is determined in step
S611 whether the reference counter (rf) set at the heap
(memory area) identified by the heap ID of the object is
zero. If it is determined that the reference counter is
zero, processing proceeds to step S624. The object (release
queue component) is again set to the release queue.
[0136]
The process of Fig. 17 is performed by the memory area
manager (heap management module) 313 in the operating system
310 of Fig. 3. In the arrangement with the weak pointer
contained as a pointer referencing the memory area, the
memory area manager (heap management module) 313 examines
the weak pointer referencing the memory area corresponding
to the queue component contained in the release queue and
the weak pointer chain composed of the memory area
containing the reference area of the weak pointer. If the
memory area manager (heap management module) 313 determines
that no weak pointer is contained in the weak pointer chain,
or that the retirement flag of the memory area contained in
the weak pointer chain is set to a retired state, the queue
component is discarded from the release queue, and the
memory area corresponding to the queue component is released.
[0137]
The process of Fig. 17 is also executed for the object
(release queue component) set in the release queue. With
this flush process performed in the arrangement
incorporating the weak pointer, the release queue is
reliably updated, the request release time set in the
release queue is reliably compared with the oldest entry
time of the thread list, and memory accessing is performed
in an error free manner.
[0138]
The present invention has been discussed with reference
to the particular embodiments. It is obvious that one of
ordinary skill in the art can make changes and modifications
to the embodiments of the present invention without
departing from the scope of the present invention. The
embodiments of the present invention have been discussed for
exemplary purposes only, and should not be construed as
limiting the scope of the present invention. To understand
the scope of the present invention, the claims should be
referred to.
[0139]
The above-references series of steps can be performed
by software, hardware, or a combination thereof. If the
series of steps is performed by software, a program forming
the software is installed from a recording medium or via a
network onto a computer incorporated into a hardware
structure or to a general-purpose computer, for example.
[0140]
The program can be recorded beforehand onto one of a
hard disk and a ROM (read-only memory) as a recording medium.
The program can also be recorded on a removable recording
media temporarily or permanently. The recording media
include a flexible disk, a CD-ROM (Compact Disk Read-Only
memory), a MO (Magneto-Optic) disk, a DVD (Digital Versatile
Disk), a magnetic disk, a semiconductor memory, etc. Such a
removable medium can be supplied in so-called package
software.
[0141]
The program can be installed from the removable
recording medium to the computer as described above.
Furthermore, the program can be transmitted in a wireless
fashion to the computer from a download site. The program
can also be transmitted in a wired fashion via a network
such as one of a LAN (local area network) and the Internet.
The program is then received by the computer and installed
onto a recording medium such as a hard disk in the computer.
[0142]
The process steps discussed in this description are
sequentially performed in the time series order as stated.
Alternatively, the steps may be performed in parallel or
separately. In this description, the system refers to a
logical system composed of a plurality of apparatuses, and
the elements of each apparatus are not necessarily contained
in the same casing.
Industrial Applicability
[0143]
As described above, in accordance with the arrangement
of the present invention, the thread list of the thread
information containing the entry time information that is
recorded on a per thread basis with a thread being as a data
processing unit is stored as the thread management
information, and the release queue containing the release
request time that is recorded on an area unit basis
concerning a release-requested but not yet released memory
area is stored as the memory area management information.
The release request time set in each queue component
contained in the release queue is compared with the oldest
entry time of each queue component in the thread list during
the memory area allocation process. The memory allocation
process is performed on only the memory area corresponding
to the queue component with the release request time set
prior to the oldest entry time. Only a memory area that is
not an access target in all threads is reliably selected and
subjected to the allocation process. The memory area
allocation process is safely preformed in a manner free from
the generation of access error in each thread.

CLAIMS
1. An information processing apparatus comprising:
a thread manager for managing thread information on a
per data processing unit basis, and
a memory area manager for managing a memory area,
wherein the thread manager stores, as thread management
information, a thread list containing entry time information
that is recorded on a per thread basis as function call time
of an operating system from a data processing program, and
wherein the memory area manager stores, as memory area
management information, a release queue containing release
request time that is recorded on an area unit basis
concerning a release-requested but not yet released memory
area, compares the release request time set in each queue
component contained in the release queue with the oldest
entry time of each queue component in the thread list during
a memory area allocation process, and allocates the memory
area corresponding to the queue component having the release
request time set prior to the oldest entry time.
2. The information processing apparatus according to
claim 1, wherein the thread manager generates a thread list
corresponding to each of a plurality of processors, records
the oldest entry time contained in entry time information
set in thread information contained in the thread list, onto
a header of each thread list, and manages the recorded
information set as being referenced by another processor.
3. The information processing apparatus according to
claim 2, wherein the memory area manager references all the
oldest entry time information set in the header of the
thread list corresponding to the processor managed by the
thread manager, selects the oldest of the oldest entry time
from the oldest entry time information set in the headers of
the thread list corresponding to all processors, compares
the selected oldest entry time with the release request time
set in each queue component contained in the release queue,
and allocates a memory area corresponding to the queue
component having the release request time set prior to the
selected oldest entry time.
4. The information processing apparatus according to
claim 1, wherein the thread manager records, on the header
of the thread list and a list component, identification
information of another list component, organizes the thread
list as a list that permits each component to be
successively acquired from the header, and updates the
identification information set in one of the header and the
list component during one of the entry of the thread and the
retirement of the thread.
5. The information processing apparatus according to
claim 1, wherein the memory area manager records, on the
header of the release queue and a queue component,
identification information of another queue component,
organizes the release queue as a list that permits each
queue component to be successively acquired from the header,
and updates the identification information set in one of the
header and the queue component during one of the setting of
a new queue and the deleting of a queue.
6. The information processing apparatus according to
claim 1, wherein the memory area manager performs a memory
area management process on a per heap unit basis, the heap
unit as a memory area having a finite size set corresponding
to each processor, stores, as the memory area management
information, a release queue containing release request time
that is recorded on a heap unit basis concerning a releaserequested
but not yet released heap, and allocates, during a
memory area allocation process, the memory area that is
recorded on a per heap unit basis in the queue component
contained in the release queue.
7. The information processing apparatus according to
claim 1, wherein the memory area manager examines a weak
pointer chain, composed of a weak pointer referencing the
memory area corresponding to the queue component contained
in the release queue, and if no weak pointer is present in
the weak pointer chain, discards the queue component from
the release queue, and releases the memory area
corresponding to the queue component.
8. The information processing apparatus according to
claim 1, wherein the memory area manager examines a
retirement flag of the memory area contained in a weak
pointer chain, composed of a weak pointer referencing the
memory area corresponding to the queue component contained
in the release queue and the memory area containing a
reference area of the weak pointer, and if the retirement
flag indicates a retired status, discards the queue
component from the release queue, and releases the memory
area corresponding to the queue component.
9. A memory area management method, comprising:
a thread management step of generating and updating a
thread list composed of thread information containing entry
time information that is recorded on a per thread basis as
function call time of an operating system from a data
processing program,
a memory area management step of generating and
updating, as memory area management information, a release
queue containing release request time that is recorded on a
per area basis concerning a release-requested but not yet
released memory area, and
a memory area allocation step of allocating the memory
area corresponding to the queue component having the entry
request time set prior to the oldest entry time, by
comparing the release request time set in each queue
component contained in the release queue with the oldest
entry time of each queue component in the thread list during
a memory area allocation process.
10. The memory area management method according to claim
9, wherein the thread management step comprises generating a
thread list corresponding to each of a plurality of
processors, recording the oldest entry time contained in
entry time information set in thread information contained
in the thread list, onto a header of each thread list, and
managing the recorded information set as being referenced by
another processor.
11. The memory area management method according to claim
10, wherein the memory area allocation step comprises
referencing all the oldest entry time information set in the
header of the thread list corresponding to a processor,
selecting the oldest of the oldest entry time from the
oldest entry time information set in the headers of the
thread list corresponding to all processors, comparing the
selected oldest entry time with the release request time set
in each queue component contained in the release queue, and
allocating a memory area corresponding to the queue
component having the release request time set prior to the
selected oldest entry time.
12. The memory area management method according to claim
9, wherein the thread management step comprises recording,
on the header of the thread list and a list component,
identification information of another list component,
organizing the thread list as a list that permits each
component to be successively acquired from the header, and
updating the identification information set in one of the
header and the list component during one of the entry of the
thread and the retirement of the thread.
13. The memory area management method according to claim
9, wherein the memory area management step comprises
recording, on the header of the release queue and a queue
component, identification information of another queue
component, organizing the release queue as a list that
permits each queue component to be successively acquired
from the header, and updating the identification information
set in one of the header and the queue component during one
of the setting of a new queue and the deleting of a queue.
14. The memory area management method according to claim
9, wherein the memory area management step comprises
performing a memory area management process on a per heap
unit basis, the heap unit as a memory area having a finite
size set corresponding to each processor, and storing, as
the memory area management information, a release queue
containing release request time that is recorded on a heap
unit basis concerning a release-requested but not yet
released heap, and
wherein the memory area allocation step comprises
allocating the memory area that is recorded on a per heap
unit basis in the queue component contained in the release
queue.
15. The memory area management method according to claim
9, wherein the memory area management step comprises
examining a weak pointer chain, composed of a weak pointer
referencing the memory area corresponding to the queue
component contained in the release queue, and if no weak
pointer is present in the weak pointer chain, discarding the
queue component from the release queue, and releasing the
memory area corresponding to the queue component.
16. The memory area management method according to claim
9, wherein the memory area management step comprises
examining a retirement flag of the memory area contained in
a weak pointer chain, composed of a weak pointer referencing
the memory area corresponding to the queue component
contained in the release queue and the memory area
containing a reference area of the weak pointer, and if the
retirement flag indicates a retired status, discarding the
queue component from the release queue, and releasing the
memory area corresponding to the queue component.
17. A computer program for performing a memory area
management process, comprising:
a thread management step of generating and updating a
thread list composed of thread information containing entry
time information that is recorded on a per thread basis as
function call time of an operating system from a data
processing program,
a memory area management step of generating and
updating, as memory area management information, a release
queue containing release request time that is recorded on a
per area basis concerning a release-requested but not yet
released memory area, and
a memory area allocation step of allocating the memory
area corresponding to the queue component having the entry
request time set prior to the oldest entry time, by
comparing the release request time set in each queue
component contained in the release queue with the oldest
entry time of each queue component in the thread list during
a memory area allocation process.