WO2014129247A1 - アボート削減方法、アボート削減装置、及びアボート削減プログラム - Google Patents

アボート削減方法、アボート削減装置、及びアボート削減プログラム Download PDF

Info

Publication number
WO2014129247A1
WO2014129247A1 PCT/JP2014/051051 JP2014051051W WO2014129247A1 WO 2014129247 A1 WO2014129247 A1 WO 2014129247A1 JP 2014051051 W JP2014051051 W JP 2014051051W WO 2014129247 A1 WO2014129247 A1 WO 2014129247A1
Authority
WO
WIPO (PCT)
Prior art keywords
abort
runtime
transaction
execution
helper
Prior art date
Application number
PCT/JP2014/051051
Other languages
English (en)
French (fr)
Inventor
怜 大平
仲池　卓也
ホセ・ジー カスタノス
ペン ウー
Original Assignee
インターナショナル・ビジネス・マシーンズ・コーポレーション
日本アイ・ビー・エム株式会社
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 インターナショナル・ビジネス・マシーンズ・コーポレーション, 日本アイ・ビー・エム株式会社 filed Critical インターナショナル・ビジネス・マシーンズ・コーポレーション
Priority to JP2015501363A priority Critical patent/JP5901835B2/ja
Priority to US14/769,739 priority patent/US9501314B2/en
Publication of WO2014129247A1 publication Critical patent/WO2014129247A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G06F9/467—Transactional memory

Definitions

  • the present invention relates to a technique for reducing the number of aborts in program execution using hardware transactional memory (HTM), and more specifically, a predetermined function is called during execution of a transaction block.
  • HTM hardware transactional memory
  • the present invention relates to a technique for reducing the number of aborts caused by.
  • HTM is a transactional memory implemented as hardware.
  • each running thread has its copy locally, and the processing result for the copy that has locally on condition that the value of the shared resource is not rewritten by another thread when the processing is completed Write. This process is called commit. ⁇ If the shared resource value has been rewritten by another thread, the processing itself is discarded.
  • a transaction can be aborted at any time (referred to as an abort), and when aborted, changes to the shared resource that the transaction has made are canceled (referred to as rollback).
  • a transaction is a collection of a series of inseparable processes executed by a single thread.
  • HTM-based parallel library HTM-basedconcurrent HTM is used for various optimizations such as library.
  • the managed runtime environment relies on various runtime helpers such as JIT compilers and memory allocators.
  • the runtime helper is a function of a virtual machine that is not included in the interpreter and JIT-compiled execution code, but is called from the interpreter and JIT-compiled code at the time of execution.
  • some of these runtime helpers cause an abort if called and executed during the execution of a transaction.
  • Patent Documents 1 to 3 and Non-Patent Documents 1 to 3 as conventional techniques for dealing with aborts.
  • Patent Document 1 and Non-Patent Document 2 disclose techniques for performing appropriate processing in an abort handler in accordance with information on the reason for abort provided by HTM hardware.
  • Patent Document 2 discloses a technique for temporarily interrupting a transaction while executing a certain transaction, performing arbitrary processing, and then starting the transaction.
  • Patent Document 3 discloses a technique for switching between implementations of a plurality of transactional memories at the time of execution.
  • Non-Patent Document 1 discloses a technique for executing a non-transaction path after retrying a plurality of times and then executing the transaction again when the transaction is aborted.
  • Non-Patent Document 3 discloses a technique for delaying re-execution of a transaction when aborted due to a collision between transactions.
  • the JIT compiler is called when a certain method is executed a predetermined number of times. However, if the call is made during a transaction, an abort occurs because the size of the work area used by the JIT compiler exceeds the transaction size supported by the hardware.
  • symbol resolution code resolution
  • code correction codepatching
  • Thread-local heap (thread-local heap: TLH) allocation is often called by a program, allocates TLH from the heap, and clears it with zero. However, if a TLH allocation is made during a transaction, an abort occurs because zero-clearing overflows beyond the transaction size limit described above.
  • asynchronous garbage collection (GC) check is started when each application that periodically checks the flag set by stop-the-world GC sleeps.
  • GC synchronous garbage collection
  • class loading is to load classes on demand during program execution. If class loading occurs during a transaction, I / O aborts the transaction.
  • Patent Document 1 and Non-Patent Document 2 use the abort reason provided by the hardware of the HTM. For example, if an asynchronous GC check or class load is called during a transaction, the reason for abort is the hardware viewpoint. Both are system call calls. For this reason, the techniques of Patent Literature 1 and Non-Patent Literature 2 cannot distinguish between the two and cannot take different appropriate measures.
  • Patent Document 3 it is necessary to switch between mounting of a plurality of transactional memories at the time of execution.
  • the switching timing since only the performance, current workload, and resource allocation are described in Patent Document 3 as the switching timing, it is possible to perform appropriate processing according to the type of runtime helper that can cause an abort. Absent.
  • Non-Patent Document 1 is a method of executing a non-transaction path on condition of a predetermined number of aborts and then executing a transaction again.
  • a predetermined number of aborts may be useless, or even if a non-transaction path is executed, the problem may not be solved. Therefore, it is necessary to perform an appropriate process according to the type of runtime helper, but a technique for that is not described in Non-Patent Document 1.
  • Non-Patent Document 3 is a method of delaying the re-execution of a transaction for a while when aborted due to a collision between transactions. Therefore, even if this technique is applied to an abort caused by a call to a runtime helper, the abort is not resolved.
  • the present invention has been made to solve the above-described problems, and an object thereof is to provide a technique for reducing the number of aborts caused by a runtime helper being called during execution of a transaction block.
  • the abort reduction method includes: (a) the computer executing the runtime helper in response to a runtime helper call during execution of a transaction block; and (b) aborting due to the runtime helper call.
  • the computer executes an abort handler; and (c) after execution of the abort handler in step (b), the computer executes a non-transaction path corresponding to the transaction block. Steps.
  • the execution of the runtime helper includes a process for passing ID information indicating a type of the runtime helper to the abort handler.
  • the execution of the abort handler includes the ID of the runtime helper that caused the abort. Processing to obtain information and invalidate the transaction block for a particular type of runtime helper.
  • the runtime helper is a function of a virtual machine that is not included in the interpreter and JIT-compiled execution code, but is called from the interpreter and JIT-compiled code at the time of execution.
  • the transaction block is a program area surrounded by a transaction start instruction and a transaction end instruction, and is a program area that is executed as a transaction in the program execution using the hardware transactional memory.
  • the process of invalidating the transaction block for the specific type of runtime helper invalidates the transaction block unconditionally for the first type of runtime helper that cannot be executed even in a non-transaction path. And the second type runtime helper that can be executed in the non-transaction path, on the condition that the second type runtime helper is not called during the execution of the non-transaction path once. Including the process of invalidating the block.
  • the first type of runtime helper includes runtime code modification
  • the second type of runtime helper includes runtime compilation and class loading.
  • the computer reactivates the transaction block in response to the program reaching a steady state.
  • the method further includes the step of:
  • the following configuration may be adopted instead of the configuration for re-enabling the transaction block. That is, when the runtime helper is the second type runtime helper, the execution content of the runtime helper is recorded using a non-transaction writing command, and the transaction is performed using the ID information as an argument. Includes processing to issue an abort instruction. In addition, when the abort handler is executed, when the transaction block is invalidated for the second type of runtime helper, the recorded processing content is registered in a table.
  • the abort reduction method further includes the step of (e) re-validating the transaction block in response to the execution of the processing content registered in the table.
  • the processing content is identification information of a method to be compiled
  • the runtime helper of the second type is class loading
  • the processing content is an identifier of a class to be loaded.
  • the abort handler determines thread local heap allocation and asynchronous garbage collection check as runtime helpers other than the specific type.
  • the computer invalidates all transaction blocks at the start of execution of the program, and (g) the computer waits for a predetermined period from the start of execution of the program. Validating all transaction blocks in response to elapse.
  • the execution of the runtime helper includes a process of issuing a transaction abort instruction
  • the process for passing the ID information to the abort handler includes a process of using the ID information as an argument of the transaction abort instruction.
  • the process for passing the ID information to the abort handler includes a process of recording the ID information using a non-transactional write instruction, and after the process, the runtime helper is a process of the original runtime helper. May be performed.
  • the execution of the runtime helper records information necessary for the execution using a non-transaction writing instruction on condition that the runtime helper is another type of runtime helper different from the specific type. Processing to include.
  • the execution of the abort handler includes a process of executing the other type of runtime helper using the recorded necessary information. Then, instead of the step (c) after the processing, the computer includes (h) a step of re-executing the transaction block.
  • the following configuration may be adopted instead of the configuration for delaying execution of the runtime helper. That is, the execution of the runtime helper is a process of recording information necessary for the execution using a non-transaction writing instruction on condition that the runtime helper is another type of runtime helper different from the specific type. And a process of canceling the execution.
  • the abort reduction method further includes the step of (i) the computer executing the transaction block using the necessary information recorded on the other type of runtime helper after executing the transaction block. Including.
  • the runtime helper of the specific type includes class loading
  • the runtime helper of the other type is runtime compilation
  • information necessary for the execution is identification information of a method to be compiled.
  • the specific type of runtime helper includes class loading
  • the other type of runtime helper is runtime code correction
  • the information necessary for execution is an address and data to be corrected at runtime code. .
  • the execution of the runtime helper replaces a call for runtime code modification in a transaction block included in the code to be compiled with a transaction abort instruction, and And a process of creating a correspondence table from the address of the transaction abort instruction to the information necessary for correcting the runtime code.
  • the abort reduction method further includes (j) re-execution of the transaction block after the computer executes an abort handler in response to execution of the replaced transaction abort instruction.
  • the abort handler is executed by subtracting the correspondence table from the address of the transaction abort instruction to obtain necessary information, correcting the runtime code, and overwriting the transaction abort instruction with a nop instruction. including.
  • the following configuration may be employed in place of the replacement configuration for runtime code correction by the compiler. That is, Execution of the abort handler prohibits writing on the page containing the instruction address where the abort occurred, provided that the runtime helper corrects the runtime code, and the cause of the abort is a write protection exception Including the process of correcting the runtime code by obtaining the address and data to be corrected at runtime by identifying the write command at the position where the write protection occurred, invalidating the write prohibition on the condition of .
  • the abort reduction method further includes (k) the computer re-executing the transaction block instead of the step (c) after the write prohibition process by the abort handler or the execution code correction.
  • the present invention can also be grasped as an abort reduction program for causing a computer to execute each step of the above-described abort reduction method. Moreover, it can also be grasped as an abort reduction device provided with means adapted to execute each step of such an abort reduction method.
  • the process for passing the ID information indicating the type of the runtime helper to the abort handler is performed, so that the processing corresponding to the type of the runtime helper can be performed from the beginning in the abort handler.
  • a transaction block can be invalidated for a specific type of runtime helper.
  • the number of aborts caused by the runtime helper being called during execution of the transaction block can be efficiently reduced without waste.
  • FIG. 5A is a flowchart illustrating an example of the processing flow in the first half of the processing by the abort handler.
  • FIG. 5B is a flowchart illustrating an example of the processing flow in the latter half of the processing by the abort handler.
  • FIG. 7A is a flowchart illustrating an example of a flow of transaction block validation processing.
  • FIG. 7B is a flowchart showing another example of the transaction block validation processing flow. It is a flowchart which shows the other example of the flow of a process by a runtime helper. It is a flowchart which shows the other example of the flow of a process by a runtime helper. It is a flowchart which shows the other example of the flow of a part of process by an abort handler. It is a flowchart which shows an example of the flow of a process by a JIT compiler.
  • FIG. 17A is a diagram showing experimental results comparing throughput according to the number of threads between the conventional technique and the present invention.
  • FIG. 17B is a diagram showing experimental results comparing throughput according to the number of threads between the conventional technique and the present invention.
  • FIG. 1 shows an example of a hardware configuration of a computer system 100 suitable for carrying out the present invention.
  • the computer system 100 includes a main CPU (central processing unit) 102 and a main memory 104 connected to a bus 106.
  • the CPU 102 is a multiprocessor capable of parallel processing, and includes an HTM 102a.
  • the HTM 102a is a transactional memory implemented as hardware, and as described above, each of the executing threads has a copy locally, and the value of the shared resource is not changed when the processing is completed. Confirm and write the processing results at once. Also, if the HTM 102a has been rewritten by another thread, those values have been changed, so that the processing itself can be discarded and restarted.
  • the transaction by the HTM 102a may be aborted at any time, and when aborted, the changes to the shared data that the transaction has made are canceled and rolled back.
  • a transaction is a collection of a series of inseparable processes executed by a single thread.
  • a display 110 for example, a liquid crystal display (LCD) can be connected to the bus 106 via a display controller 108.
  • the display 110 is used to display information about a computer connected to a network via a communication line and information about software running on the computer with an appropriate graphic interface for managing the computer. used.
  • a disk 114 such as a silicon disk or a hard disk, can be connected to the bus 106 via a SATA or IDE controller 112.
  • the bus 106 may also optionally be connected to a drive 116, such as a CD, DVD or BD drive, via a SATA or IDE controller 112.
  • a keyboard 120 and a mouse 122 may optionally be connected to the bus 106 via a keyboard / mouse controller 118 or a USB bus (not shown), but this is not necessary for implementing the present invention. *
  • the disk 114 stores an operating system, a program that provides a virtual machine such as a Java (registered trademark) virtual machine (VM), and other programs and data so that they can be loaded into the main memory 104.
  • a virtual machine such as a Java (registered trademark) virtual machine (VM)
  • VM virtual machine
  • the abort reduction program can provide functions to be described later for a part of a program that provides a virtual machine, that is, an interpreter, a compiled code execution unit, an abort handler, and a plurality of runtime helpers. It can be implemented by modifying as follows.
  • the above computer program can be compressed and divided into a plurality of pieces and recorded on a plurality of media.
  • the drive 116 can be used to install a program from the CD-ROM, DVD-ROM or BD to the disk 114 as required.
  • the communication interface 126 follows, for example, the Ethernet (registered trademark) protocol.
  • the communication interface 126 is connected to the bus 106 via the communication controller 124, plays a role of physically connecting the computer system 100 to the communication line 128, and is a TCP / IP of the communication function of the operating system of the computer system 100.
  • a network interface layer is provided for the communication protocol.
  • the communication line may be based on a wired LAN environment or a wireless LAN environment, for example, based on a Wi-Fi standard such as IEEE 802.11a / b / g / n.
  • the computer system 100 used in the embodiment of the present invention may be an apparatus that can store and execute the abort reduction program according to the embodiment of the present invention, such as a PC, a server, A workstation or the like can be used as an abort reduction device.
  • a PC personal computer
  • server personal computer
  • a workstation personal computer
  • the component demonstrated above is an illustration, All the components are not necessarily an essential component of this invention.
  • FIG. 2 is a diagram showing an example of the software configuration of the computer system 100 shown in FIG.
  • the CPU 102 reads a virtual machine such as a Java (registered trademark) virtual machine (VM) and an operating system from the disk 114 to the main memory 104 and executes the virtual machine 206 and the operating system 202 in the main memory 104.
  • VM virtual machine
  • the operating system 202 is software that provides basic functions of the computer system 100 such as management of the CPU 102 and memory.
  • the virtual machine 206 is an emulator that performs low-speed execution (interpret) of bytecode and execution of compiled code, manages execution of code, and provides various services to applications executed on the virtual machine.
  • the virtual machine 206 includes an interpreter 210, a compiled code execution unit 212, a dispatcher 214, a runtime helper group 218 including a plurality of runtime helpers, and an abort handler 204.
  • the dispatcher 214 refers to the code cache 216 which is a memory area for storing the compiled code generated by the JIT compiler 220 included in the runtime helper group 218, and the compiled code starting from the bytecode address to be executed next is the code cache. It is determined whether it is stored in H.216.
  • the interpreter 210 executes the bytecode to be processed at a low speed when there is no compiled code.
  • the compiled code execution unit 212 acquires the compiled code from the code cache 216 and executes it.
  • the CPU 102 is a multiprocessor capable of parallel processing, and includes the HTM 102a. Therefore, when there is a transaction block surrounded by a transaction start instruction and a transaction end instruction in the execution target code, the interpreter 210 executes the area as a transaction using the HTM 102a. When a transaction block is included in the JIT-compiled code, the compiled code execution unit 212 executes the area as a transaction using the HTM 102a.
  • the interpreter 210 and the compiled code execution unit 212 also execute a non-transactional path according to a predetermined condition.
  • the non-transaction path means a process that is semantically the same as the transaction block that is normally executed to advance the program when the execution of the transaction block aborts many times. There is one non-transaction path for each transaction block. Both are semantically the same, but the non-transaction path is slower to execute.
  • a non-transaction path may be written by a programmer, or a compiler or the like may be automatically generated from a transaction block code.
  • the interpreter 210 and the compiled code execution unit 212 are collectively referred to as an execution unit 208 (corresponding to the execution unit in claim 19 of the claims).
  • the runtime helper 218 includes a plurality of runtime helpers.
  • a runtime helper is a virtual machine function that is called at run time from interpreted or JIT-compiled code. Some runtime helpers can abort a transaction if executed during the transaction, and such runtime helpers are referred to herein as abort-proneproruntime helper 219. Call it. Whether or not it is an abortive runtime helper 219 depends on the implementation of the HTM, but as an example, a JIT compiler 220, a class loader 222, an asynchronous garbage collector (GC) 224, a TLH allocator 226, a symbol resolver 228 Can be mentioned.
  • the present invention aims to reduce the number of aborts caused by the abortive runtime helper 219. So, first, I will explain each of the abortive runtime helpers listed above.
  • the JIT compiler 220 is called when a certain method is executed a predetermined number of times. However, if the call is made during a transaction, an abort occurs because the size of the work area used by the JIT compiler 220 exceeds the transaction size supported by the hardware. A possible solution is to execute the non-transaction path only once and expect the JIT-compiled method to be executed during that time. If a method subject to JIT compilation is executed while executing a non-transaction path, the JIT compiler 220 is called outside the transaction block and executed successfully. On the other hand, if the method subject to JIT compilation is not executed while executing the non-transaction path, the transaction block is invalidated, and the transaction block is validated again after waiting for the program to reach a steady state.
  • the class loader 222 loads classes on demand during program execution. If class loading occurs during a transaction, I / O aborts the transaction. A possible solution is to perform a non-transaction path only once and expect that non-transaction path to use the same class. If the same class is used while executing a non-transaction path, the class loader 222 is called outside the transaction block and executed successfully. On the other hand, when the same class is not used during execution of a non-transaction path, the transaction block is invalidated, and the transaction block is validated again after waiting for the program to reach a steady state.
  • Asynchronous GC 224 is called when each application that periodically checks the flag set by stop-the-worldGC sleeps. However, since a system call call for sleep during a transaction is not allowed, an abort occurs when the setting of the flag is detected during the transaction.
  • a possible solution is to perform a non-transactional path. By executing the non-transaction path, it can be expected that the current thread will reach another asynchronous GC checkpoint before entering the next transaction, thereby calling the asynchronous GC 224 outside the transaction block.
  • TLH allocator 226 is often called by a program, allocates TLH from the heap, and clears it with zero. However, if TLH allocation is done during a transaction, an abort occurs because zero cleaning overflows the transaction size limit.
  • a possible solution is to perform a non-transactional path. By performing a non-transactional path, it can be expected that the current thread will allocate a new object before the next transaction is entered, thereby calling the TLH allocator 226 outside the transaction block.
  • the symbol resolver 228 or code correction is to resolve a symbol in a method on demand at the time of execution, and as a result, correct the code that refers to the symbol. Therefore, if symbol resolution is performed during a transaction, an abort occurs. However, in this case, even if a non-transaction path is executed, the code on the transaction path will not be corrected, and this does not solve the problem. A possible solution is therefore to invalidate the transaction block immediately so that no aborts occur unnecessarily.
  • the abort runtime helper 219 passes ID information indicating the type of the abort runtime helper 219 to the abort handler 204 when it is called during execution of a transaction block.
  • the abort property runtime helper 219 issues a transaction abort instruction using the ID information as an argument indicating the cause of the abort without performing original processing.
  • the abort handler 204 called when the transaction abort instruction is executed acquires the ID information of the abortive runtime helper 219 that caused the abort, and the ID information is a specific type of abortive runtime helper 219.
  • Transaction block is invalidated.
  • the abort handler 204 unconditionally invalidates the transaction block for the first type of runtime helper that cannot be executed even in a non-transaction path.
  • the abort handler 204 executes the non-transaction path only once for the second type runtime helper that can be executed in the non-transaction path, and the second type runtime helper is not called during the execution. Invalidate the transaction block.
  • the first type of runtime helper includes runtime code modification
  • the second type of runtime helper includes JIT compilation and class loading.
  • the abort handler 204 determines TLH allocation and asynchronous GC check as runtime helpers other than a specific type, and does nothing for them.
  • the execution unit 208 executes a non-transaction path corresponding to the transaction block in which the abort occurred.
  • the execution unit 208 revalidates the transaction block in response to the program reaching a steady state. This is because when the program is in a steady state, it is expected that the class causing the abort is loaded and the method causing the abort is compiled.
  • the state in which the transaction block is invalidated until the cause of the abort is resolved is referred to as a temporary non-transaction mode in this specification.
  • whether or not the program has reached a steady state depends on whether a sufficient number of classes have been loaded, a sufficient number of methods have been compiled, or both.
  • the following method may be used.
  • the time when a new class is not loaded and / or the time when a new method is not compiled or both last for 10 seconds or more.1000 new classes are loaded or 1000 new methods are compiled or both. ⁇
  • the number of classes loaded per second, the number of methods compiled per second, or both are monitored, and the number is less than 10 per second. However, numbers such as 10 seconds and 1000 are examples. It is preferable to obtain an optimum value in advance in a preliminary experiment.
  • the above-described abort reduction method can be extended from the following four viewpoints as the abort reduction base method.
  • Abort runtime helper 219 ID information is used to indicate the cause of the abort, and is used as an argument of the transaction abort instruction (base method) B2. Record the ID information of the abortive runtime helper 219 in the runtime helper recording area of the currently executing thread using the non-transactional write instruction.
  • Second embodiment (A1 + B2 + C1 + D1) Whether a runtime helper is aborted when called during a transaction depends on the HTM implementation. For example, JIT compilation does not cause a transaction abort on implementations that support very large transaction sizes. In such an implementation, if the abort abort runtime helper 219 issues a transaction abort instruction each time it is called during a transaction, performance is degraded.
  • the abortive runtime helper 219 uses the non-transaction write instruction to store the storage area of the thread that is currently being executed. To record.
  • the abort handler 204 determines whether or not such a record exists, and if it exists, determines the cause of the abort based on the record.
  • the information to be recorded in the recording area by the abortive runtime helper 219 may be its own ID information as an example.
  • the abortive runtime helper 219 is a code modification, it immediately invalidates the transaction block. Even when the abort property runtime helper 219 is the JIT compiler 220, the transaction block is invalidated on the condition that the JIT compiler 220 is not called in the execution of one non-transaction path. As described above, the execution of the non-transaction path is slower than the execution of the transaction block. Therefore, invalidating the transaction block degrades the performance.
  • the abortive runtime helper 219 called during the transaction is the JIT compiler 220 or the symbol resolver 228, the execution is delayed and executed in the abort handler 204.
  • the JIT compiler 220 and the symbol resolver 228 do not have side effects that are visible to the programmer (programexecution semantics), and their execution order is not strictly defined, so there is no problem even if execution is delayed in this way.
  • the class loader 222 since the class loader 222 has a side effect visible to the programmer (programmer-visiblesemantics), such a delay is not allowed.
  • the abort runtime helper 219 which is the JIT compiler 220 or the symbol resolver 228, uses the non-transaction write instruction to transmit information necessary for the original processing together with the ID information.
  • the abort handler 204 determines whether or not such a record exists, and if it exists, performs JIT compilation or code correction based on the record.
  • the information to be recorded in the recording area by the JIT compiler 220 is identification information of a method to be compiled.
  • Information to be recorded in the recording area by the symbol resolver 228 is an address and data to be corrected at the time of execution.
  • processing described below is added to the original processing by the JIT compiler 220 instead of using a non-transactional write instruction.
  • the JIT compiler 220 replaces the call for runtime code correction in the transaction block included in the code to be compiled with the transaction abort instruction, and converts the address of the transaction abort instruction to information necessary for the runtime code correction. Create a correspondence table.
  • the information necessary for correcting the runtime code is an address and data to be corrected for the runtime code.
  • the abort handler 204 called by execution of the replaced transaction abort instruction acquires necessary information by subtracting the correspondence table from the address of the transaction abort instruction.
  • the abort handler 204 corrects the runtime code based on the acquired information, and overwrites the transaction abort instruction with a nop instruction.
  • the execution unit 208 re-executes the transaction block.
  • Code modification is often used in JIT compiled code, such as JIT compilation and polymorphic inline method caching, as well as symbol resolution.
  • code modifications cause an abort if called while executing a transaction.
  • execution of the abort handler 204 can be delayed until processing of the abort handler 204 is started as in the third embodiment, from the viewpoint of software engineering, in the managed runtime, delay processing is performed at all code correction positions. Inserting logic for is not practical.
  • code correction processing is delayed without inserting logic for delay processing at all code correction positions.
  • the abort handler 204 first prohibits writing a page including the instruction address at which the abort occurred, on condition that the abort runtime helper 219 that caused the abort is a code correction at the time of execution. Thereafter, the execution unit 208 re-executes the transaction block. Then, the abort handler 204 that is called next invalidates the previous write prohibition on the condition that the cause of the abort is a write protection exception, and identifies the write command at the position where the write protection has occurred. The address and data to be corrected at runtime are acquired and the runtime code is corrected. Thereafter, the execution unit 208 re-executes the transaction block.
  • the transaction block is validated after confirming that the causing method is JIT compiled or the causing class is loaded. Therefore, in the sixth embodiment, the JIT compiler 220 and the class loader 222 that are called during transaction execution record the processing contents in the storage area of the currently executing thread using a non-transaction write instruction, A transaction abort command is issued with the ID information as an argument.
  • the processing content is identification information of a method to be compiled in the case of the JIT compiler 220, and an identifier of a class to be loaded in the case of the class loader 222.
  • the abort handler 204 When the abort handler 204 called by the transaction abort instruction invalidates the transaction block for the JIT compiler 220 and the class loader 222, the abort handler 204 reads the information recorded in the storage area of the currently executing thread and reads the global table. Register with. Thereafter, the execution unit 208 revalidates the transaction block in response to the execution of the processing content registered in the global table.
  • FIG. 3 is a flowchart showing an example of the flow of the entire abort reduction process according to the embodiment of the present invention.
  • FIG. 4 is a flowchart showing an example of the flow of processing by the abortive runtime helper 219.
  • FIGS. 5A and 5B are flowcharts showing an example of a partial flow of processing by the abort handler 204.
  • FIG. 6 is a flowchart illustrating an example of the flow of non-transaction path execution processing.
  • FIGS. 7A and 7B are flowcharts showing an example of the flow of transaction block validation processing.
  • the flowchart shown in FIG. 3 starts with the execution of a transaction block, and the execution unit 208 determines whether or not the current transaction block to be executed has been invalidated (step 300).
  • the execution unit 208 subsequently initializes a retry counter for counting the number of retries of the current transaction block with a positive integer (step). 302).
  • the execution unit 208 also increments an execution counter for counting the number of executions of the current transaction block by 1 (step 304).
  • the execution unit 208 starts and executes a transaction (steps 306 and 308). It is assumed that a retry counter is held for each thread, and an execution counter and an abort counter described later are held for each transaction block.
  • the execution counter and abort counter are initialized when a code including the corresponding transaction block is loaded.
  • the execution unit 208 determines whether or not the abort property runtime helper 219 is called in the transaction (step 310). If the abortive runtime helper 219 has been called (step 310: YES), the process proceeds to step 312, where the called abortive runtime helper 219 performs processing. Details of the processing by the abortive runtime helper 219 will be described later with reference to FIG. After the processing by the abortive runtime helper 219 or when the abortable runtime helper 219 has not been called (step 310: NO), the processing proceeds to step 314, and the execution unit 208 determines whether or not an abort has occurred in the transaction. Determine whether.
  • step 314 If an abort has occurred in the transaction (step 314: YES), the process proceeds to step 316, where the abort handler 204 performs the process. Details of the processing by the abort handler 204 will be described later with reference to FIG. On the other hand, if no abort has occurred in the transaction (step 314: NO), the process proceeds to step 320, the execution unit 208 ends the transaction (step 320), and ends the process.
  • the process by the abort handler 204 in step 316 has two results. If the result indicates 2, the process returns to step 306 and tries to execute the current transaction block again. On the other hand, when the result of processing by the abort handler 204 indicates 1 or when it is determined in step 300 that the current transaction block is invalidated (step 300: YES), the process proceeds to step 318, and the execution unit Performs a non-transactional path. Details of the non-transaction path execution process will be described later with reference to FIG. After the non-transaction path execution process, the process ends.
  • the flowchart shown in FIG. 4 shows details of processing by the abortive runtime helper 219 in step 312 of the flowchart shown in FIG.
  • the process starts at step 400, and the abort runtime helper 219 issues a transaction abort instruction using the ID indicating the type of the abort runtime helper 219 as an argument indicating the cause of the abort. Thereafter, the abortive runtime helper 219 terminates the process.
  • the processing of the flowchart shown in FIG. 4 is executed when the abortive runtime helper 219 is called during execution of a transaction. Note that the original processing is performed.
  • the flowchart shown in FIG. 5A shows the first half of the processing by the abort handler 204 in step 316 of the flowchart shown in FIG. Processing begins at step 500, where the abort handler 204 determines whether the cause of the abort is a TLH allocation or an asynchronous GC check. If the cause of the abort is either TLH allocation or asynchronous GC check (step 500: YES), the abort handler 204 ends the process leaving a result indicating 1. On the other hand, if the cause of the abort is neither TLH allocation nor asynchronous GC check (step 500: NO), then the abort handler 204 determines whether the cause of the abort is symbol resolution (step 502). . If the cause of the abort is symbol resolution (step 502: YES), the abort handler 204 immediately invalidates the current transaction block (step 510), and ends the process leaving a result indicating 1.
  • the abort handler 204 determines whether the cause of the abort is JIT compilation or class loading (step 504). If the cause of the abort is neither JIT compilation nor class loading (step 504: NO), the process continues to step 520 of the flowchart shown in FIG. On the other hand, if the cause of the abort is either JIT compilation or class loading (step 504: YES), then the abort handler 204 determines whether the non-tx-once flag is set for the current transaction block. Is determined (step 506).
  • the non-tx-once flag is a flag assigned for each transaction block, and is used together with a non-tx-execution flag assigned for each thread described later.
  • the non-transaction path is executed only once by the control using these flags, and the current transaction block is invalidated on the condition that the JIT compilation or class loading causing the abort is not executed during that time. Realize processing.
  • the non-tx-once flag is set in the execution of a non-transaction path, which will be described later with reference to FIG. 6. The setting indicates that no JIT compilation or class loading occurred during the execution of the non-transaction path. Show.
  • step 506 when the non-tx-once flag is not set (step 506: NO), the abort handler 204 then continues to the non-tx of the currently executed thread.
  • An -execution flag is set (step 508).
  • the non-tx-execution flag indicates that the cause of the abort was JIT compilation or class loading.
  • the abort handler 204 invalidates the current transaction block (step 510).
  • step 508 or step 510 the abort handler 204 ends the process leaving a result indicating 1.
  • the flowchart shown in FIG. 5 (b) shows the flow of the latter half of the process that is executed when the determination in step 504 of the flowchart shown in FIG. 5 (a) is NO.
  • Processing begins at step 520, where the abort handler 204 determines whether the retry counter value is greater than zero. If the retry counter value is greater than 0 (step 520: YES), the abort handler 204 decrements the retry counter value by 1 (step 522), and ends the process leaving a result indicating 2.
  • the abort handler 204 increments the abort counter of the current transaction block by 1 (step 524). Subsequently, the abort handler 204 determines whether or not the abort rate obtained by dividing the abort counter value by the execution counter value is smaller than a predetermined threshold (step 526). If the abort rate is smaller than the predetermined threshold (step 526: YES), the abort handler 204 ends the process leaving a result indicating 1. On the other hand, if the abort rate is equal to or higher than the predetermined threshold (step 526: NO), the abort handler 204 invalidates the current transaction block (step 528), and ends the process leaving a result indicating 1.
  • the flowchart shown in FIG. 6 shows the details of the non-transaction path execution process in step 318 of the flowchart shown in FIG.
  • the process starts at step 600, and the execution unit 208 starts executing a non-transaction path. Subsequently, when JIT compilation or class loading is triggered during execution of the non-transaction path, the execution unit 208 sets the non-tx-execution flag of the currently executing thread to the non-transaction path. JIT compilation or class loading is executed in synchronization with the execution of, and then the non-tx-execution flag of the currently executing thread is reset (step 602). Subsequently, the execution unit 208 ends the execution of the non-transaction path (Step 604).
  • the execution unit 208 determines whether or not the non-tx-execution flag of the currently executing thread is set (step 606). If the non-tx-execution flag of the currently executing thread is not set (step 606: NO), the execution unit 208 ends the process. On the other hand, when the non-tx-execution flag of the currently executing thread is set (step 606: YES), the execution unit 208 sets the non-tx-once flag assigned to the current transaction block. (Step 608) Thereafter, the non-tx-execution flag of the currently executing thread is reset (Step 610). Thereafter, the execution unit 208 ends the process.
  • the flowchart shown in FIG. 7A is a process periodically executed by the execution unit 208.
  • the process starts at step 700, and the execution unit 208 waits until a sufficient number of classes are loaded and a sufficient number of methods are compiled. Subsequently, the execution unit 208 re-enables all the transaction blocks invalidated due to JIT compilation or class loading, and resets the corresponding execution counter, abort counter, and non-tx-once flag (Step S208). 702). Then, the execution unit 208 ends the process.
  • FIG. 7B is a flowchart showing a flow of processing newly executed by the execution unit 208 at the start of program execution when the configuration of A2 is adopted in addition to the configuration of A1 in the first embodiment.
  • the process starts at step 710, and the execution unit 208 invalidates all transaction blocks included in the code of the program to be executed. Subsequently, the execution unit 208 waits until a sufficient number of classes are loaded and a sufficient number of methods are compiled (step 712). Subsequently, the execution unit 208 re-enables all transaction blocks in the code of the program to be executed, and resets the corresponding execution counter, abort counter, and non-tx-once flag (step 714). Then, the execution unit 208 ends the process.
  • FIG. 8 is a flowchart showing another example of the processing flow by the abortive runtime helper 219 in step 312 of the flowchart shown in FIG.
  • the flowchart shown in FIG. 8 starts at step 800, and the abortable runtime helper 219 records the ID indicating the type of the runtime helper in the storage area of the currently executing thread by using a non-transactional write instruction. Subsequently, the abortive runtime helper 219 executes its original process (step 802). Subsequently, the abortive runtime helper 219 determines whether or not the currently executing transaction has been aborted (step 804).
  • the abortive runtime helper 219 ends the process without doing anything.
  • the abortive runtime helper 219 clears the information recorded in the storage area of the currently executing thread (step 806) and ends the processing. To do.
  • the abort handler 204 reads the information recorded in the storage area of the currently executing thread at the beginning of the processing shown in the flowchart of FIG.
  • FIG. 9 is a flowchart showing another example of the processing flow by the abortive runtime helper 219 in step 312 of the flowchart shown in FIG.
  • FIG. 10 is a flowchart showing another example of the processing flow of the first half by the abort handler 204 in step 316 of the flowchart shown in FIG.
  • the flowchart shown in FIG. 9 starts in step 900, and the abortive runtime helper 219 determines whether or not the processing content is symbol resolution. If the processing content is symbol resolution (step 900: YES), the abortive runtime helper 219 uses the non-transactional write instruction to set the address and data of the code to be corrected in the storage area of the currently executing thread. Write (step 902).
  • the abortive runtime helper 219 determines whether or not the processing content is JIT compilation (step 904). If the processing content is JIT compilation (step 904: YES), the abortive runtime helper 219 uses the non-transactional write instruction to write the ID of the method to be JIT compiled into the storage area of the currently executing thread (step 904). 902). If the processing content is not JIT compilation in step 904 (step 904: NO), the post-processing of step 902 or step 906 proceeds to step 908, and the abortive runtime helper 219 indicates the type of the abortive runtime helper 219. A transaction abort instruction is issued as an argument indicating the cause of the abort. Thereafter, the abortive runtime helper 219 terminates the process.
  • the flowchart shown in FIG. 10 starts at step 1000, and the abort handler 204 determines whether or not the cause of the abort is symbol resolution. If the cause of the abort is symbol resolution (step 1000: YES), the abort handler 204 modifies the address of the recorded code with the data recorded in the storage area of the currently executing thread (step 1002). ) The process ends with the result indicating 2 left.
  • the abort handler 204 determines whether or not the cause of the abort is JIT compilation (step 1004). If the cause of the abort is JIT compilation (step 1004: YES), the abort handler 204 JIT compiles the method identified by the ID recorded in the storage area of the currently executing thread (step 100), 2 The process ends with a result indicating
  • the abort handler 204 determines whether the cause of the abort is TLH allocation or asynchronous GC check (step 1008). If the cause of the abort is either TLH allocation or asynchronous GC check (step 1008: YES), the abort handler 204 ends the process leaving a result indicating 1.
  • step 1010 determines whether the cause of the abort is a class load (step 1010). . If the cause of the abort is not class loading (step 1010: NO), the process continues to step 520 in the flowchart shown in FIG. On the other hand, if the cause of the abort is class loading (step 1010: YES), then the abort handler 204 determines whether the non-tx-once flag for the current transaction block is set (step) 1012).
  • step 1012 If the non-tx-once flag is not set (step 1012: NO), then the abort handler 204 sets the non-tx-execution flag of the currently executed thread (step 1014). On the other hand, if the non-tx-once flag is set (step 1012: YES), the abort handler 204 invalidates the current transaction block (step 1016). After step 1014 or step 1016, the abort handler 204 ends the process leaving a result indicating 1.
  • FIG. 11 is a flowchart illustrating an example of the flow of processing by the JIT compiler 220.
  • FIG. 12 is a flowchart showing another example of the process flow of the first half by the abort handler 204 in step 316 of the flowchart shown in FIG.
  • the flowchart shown in FIG. 11 starts when a certain method is executed a predetermined number of times and the JIT compiler 220 is called, and the JIT compiler 220 determines whether there is a transaction block in the code to be compiled (step 1100). If there is a transaction block in the code to be compiled (step 1100: YES), then the JIT compiler 220 determines whether there is a call for code correction in the found transaction block (step 1102).
  • step 1102 If there is a code correction call in the found transaction block (step 1102: YES), the JIT compiler 220 replaces the found code correction call with the transaction abort instruction and the code replaced from the instruction address of the abort instruction.
  • a correspondence table for information necessary for execution of correction is created (step 1104).
  • information necessary for executing the code correction is an address and data to be corrected at the time of execution.
  • step 1100 If there is no transaction block in the code to be compiled in step 1100 (step 1100: NO), if there is no code modification call in the transaction block found in step 1102 (step 1102: NO), or processing from step 1104 Advances to step 1106, the JIT compiler 220 performs normal JIT compilation processing, and thereafter ends the processing.
  • the flowchart shown in FIG. 12 starts at step 1200, and the abort handler 204 determines whether or not the cause of the abort is symbol resolution. This determination can be made by searching the correspondence table created by the JIT compiler 220 at the instruction address where the abort occurred, and determining whether or not there is a hit. If a hit occurs, it can be determined that the cause of the abort is symbol resolution. If the cause of the abort is symbol resolution (step 1200: YES), the abort handler 204 obtains necessary information by subtracting the correspondence table created by the JIT compiler 220 from the instruction address where the abort occurred. The code is corrected using the information, and the abort instruction is replaced with a nop instruction which means that nothing is done (step 1202). Thereafter, the abort handler 204 ends the process leaving a result indicating 2.
  • the abort handler 204 determines whether the cause of the abort is TLH allocation or asynchronous GC check (step 1204). If the cause of the abort is either TLH allocation or asynchronous GC check (step 1204: YES), the abort handler 204 ends the process leaving a result indicating 1.
  • step 1204 determines whether the cause of the abort is JIT compilation or class loading (step 1204). Step 1206). If the cause of the abort is neither JIT compilation nor class loading (step 1206: NO), the process continues to step 520 of the flowchart shown in FIG. On the other hand, if the cause of the abort is either JIT compilation or class loading (step 1206: YES), then the abort handler 204 determines whether the non-tx-once flag for the current transaction block is set. Is determined (step 1208).
  • step 1208 If the non-tx-once flag is not set (step 1208: NO), then the abort handler 204 sets the non-tx-execution flag of the currently executed thread (step 1210). On the other hand, if the non-tx-once flag is set (step 1208: YES), the abort handler 204 invalidates the current transaction block (step 1212). After step 1210 or step 1212, the abort handler 204 ends the process leaving a result indicating 1.
  • FIG. 13 is a flowchart showing another example of the processing flow of the first half by the abort handler 204 in step 316 of the flowchart shown in FIG.
  • the flowchart shown in FIG. 13 starts at step 1300, and the abort handler 204 determines whether or not the cause of the abort is a code correction. If the cause of the abort is code correction (step 1300: YES), the abort handler 204 write-protects the page including the instruction address where the abort occurred (step 1302). Thereafter, the abort handler 204 ends the process leaving a result indicating 2.
  • the abort handler 204 determines whether the cause of the abort is a write protection exception (step 1304). If the cause of the abort is a write protection exception (step 1304: YES), the abort handler 204 modifies the runtime code by disabling the write protection and identifying the write instruction where the write protection occurred. The power address and data are acquired, and the code at the time of execution is corrected (step 1306). Thereafter, the abort handler 204 ends the process leaving a result indicating 2.
  • the abort handler 204 determines whether the cause of the abort is a TLH allocation or an asynchronous GC check (step 1308). If the cause of the abort is either TLH allocation or asynchronous GC check (step 1308: YES), the abort handler 204 ends the process leaving a result indicating 1.
  • the abort handler 204 determines whether the cause of the abort is JIT compilation or class loading (step 1308). Step 1310). If the cause of the abort is neither JIT compilation nor class loading (step 11310: NO), the process continues to step 520 of the flowchart shown in FIG. On the other hand, if the cause of the abort is either JIT compilation or class loading (step 1310: YES), then the abort handler 204 determines whether the non-tx-once flag for the current transaction block is set. Is determined (step 1312).
  • step 1312 If the non-tx-once flag is not set (step 1312: NO), then the abort handler 204 sets the non-tx-execution flag of the currently executed thread. On the other hand, if the non-tx-once flag is set (step 1312: YES), the abort handler 204 invalidates the current transaction block (step 1316). After step 1314 or step 1316, the abort handler 204 ends the process leaving a result indicating 1.
  • FIG. 14 is a flowchart showing another example of the flow of processing by the abortive runtime helper 219 in step 312 of the flowchart shown in FIG.
  • FIG. 15 is a flowchart showing another example of the processing flow of the first half by the abort handler 204 in step 316 of the flowchart shown in FIG.
  • FIG. 16 is a flowchart illustrating another example of the transaction block validation processing flow.
  • the flowchart shown in FIG. 14 starts at step 1400, and the abortive runtime helper 219 determines whether the processing content is JIT compilation or class loading. If the processing content is either JIT compilation or class loading (step 1400: YES), the abortive runtime helper 219 should perform JIT compilation in the storage area of the currently executing thread using a non-transactional write instruction. Write the ID of the method or the ID of the class to be loaded (step 1402).
  • the abortive runtime helper 219 uses an ID indicating the type of the abortable runtime helper 219 as an argument indicating the cause of the abort.
  • a transaction abort instruction is issued (step 1404). Thereafter, the abortive runtime helper 219 terminates the process.
  • the flowchart shown in FIG. 15 starts at step 1500, and the abort handler 204 determines whether the cause of the abort is TLH allocation or asynchronous GC check. If the cause of the abort is either TLH allocation or asynchronous GC check (step 1500: YES), the abort handler 204 ends the process leaving a result indicating 1. On the other hand, if the cause of the abort is neither TLH allocation nor asynchronous GC check (step 1500: NO), then the abort handler 204 determines whether the cause of the abort is symbol resolution (step 1502). . If the cause of the abort is symbol resolution (step 1502: NO), the abort handler 204 immediately invalidates the current transaction block (step 1504), and ends the process leaving a result indicating 1.
  • the abort handler 204 determines whether the cause of the abort is JIT compilation or class loading (step 1506). If the cause of the abort is neither JIT compilation nor class loading (step 1506: NO), the process continues to step 520 of the flowchart shown in FIG. On the other hand, if the cause of the abort is either JIT compilation or class loading (step 1506: YES), then the abort handler 204 determines whether the non-tx-once flag is set for the current transaction block. Is determined (step 1508).
  • step 1508 If the non-tx-once flag is not set (step 1508: NO), then the abort handler 204 sets the non-tx-execution flag of the currently executed thread (step 1510). On the other hand, if the non-tx-once flag is set (step 1508: YES), the abort handler 204 stores the method ID or class ID recorded in the storage area of the currently executing thread in the global table. Write (step 1512). Subsequently, the abort handler 204 invalidates the current transaction block (step 1514). After step 1510 or step 1514, the abort handler 204 ends the process leaving a result indicating 1.
  • the flowchart shown in FIG. 16 starts at step 1600, and the execution unit 208 waits until all methods and all classes in the global table are JIT-compiled or loaded, respectively. Subsequently, the execution unit 208 re-enables all the transaction blocks invalidated due to JIT compilation or class loading, and resets the corresponding execution counter, abort counter, and non-tx-once flag (Step S208). 702). Then, the execution unit 208 ends the process.
  • FIG. 17A shows the result of evaluating the performance of a 4-core zEC12 machine to which the abort reduction method of the present invention is applied using a micro benchmark that adds a counter.
  • FIG. 17B shows a result of evaluating the performance of a 16-core zEC12 machine to which the abort reduction method of the present invention is applied using Java (registered trademark) ConcurrentHashMap using HTM.
  • the horizontal axis indicates the number of threads
  • the vertical axis indicates the throughput. Note that the throughput value is 1 when the conventional technology for one thread is applied.
  • the applied abort reduction method of the present invention is the abort reduction method according to the third embodiment described above.
  • the compared prior art is a method described in Non-Patent Document 1, and when a transaction aborts, it is re-executed several times. If abort still occurs, a non-transaction path is executed and then the transaction is performed again. It is a technique of executing.
  • FIG. 17A the performance is reduced by 89% when the present invention is not used.
  • the experimental result shown in FIG. 17B the performance is reduced by 13% when the present invention is not used. This is because if the present invention is not used, JIT compilation and runtime code correction occur in the transaction, and the transaction continues to abort.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)
  • Executing Machine-Instructions (AREA)

Abstract

トランザクションブロックを実行中にランタイムヘルパーが呼び出されることに起因するアボートの回数を削減するための技術を提供する。 ハードウェアトランザクショナルメモリを用いたプログラム実行において、トランザクションブロックの実行中にランタイムヘルパーが呼び出されると、ランタイムヘルパーは、ランタイムヘルパーの種別を示すID情報をアボート・ハンドラに渡し、ランタイムヘルパーの呼び出しに起因したアボートに応答して、アボート・ハンドラはアボートの原因となったランタイムヘルパーのID情報を取得し、特定の種別のランタイムヘルパーに対してトランザクションブロックを無効化し、その後トランザクションブロックに対応する非トランザクションパスが実行され、所定の条件が満たされると、トランザクションブロックを再有効化する。

Description

アボート削減方法、アボート削減装置、及びアボート削減プログラム
　本発明は、ハードウェアトランザクショナルメモリ（Hardware Transactional Memory：HTM）を用いたプログラム実行におけるアボート回数を削減するための技術に関し、より詳細には、トランザクションブロックを実行中に所定の機能が呼び出されることにより引き起こされるアボートの回数を削減するための技術に関する。
　マルチコア・プロセッサでは、並列に実行されるスレッドがデータを共有して扱う共有メモリ型の並列プログラムが用いられることが多い。このとき、アクセスが競合しないようにする手法として、HTMと呼ばれる手法がある。HTMは、ハードウェアとして実装されるトランザクショナルメモリである。
　HTMでは、実行しているスレッドの各々がそのコピーをローカルにもち、処理が終了した時点で共有リソースの値が他のスレッドにより書き換えられていないことを条件にローカルにもつコピーに対する処理結果を一気に書き込む。この処理はコミットと呼ばれる。 共有リソースの値が他のスレッドにより書き換えられている場合、処理そのものが廃棄される。トランザクションはいつでも中止されることがあり（アボートという）、アボートされると、そのトランザクションがそれまでに行った共有リソースへの変更は取り消される（ロールバックという）。なお、トランザクションとは、１つのスレッドで実行される一連の不可分な処理をまとめたものである。
　最近では、HTMを搭載した商用マシンも市場に現れている。Java（登録商標）仮想マシン（VM）などのマネージドランタイム環境では、ロック除去（Lock elision）や部分インライン展開（partial inlining）、投機的チェック除去（speculative check elimination）、HTMベース並列ライブラリ（HTM-basedconcurrent library）など、種々の最適化のためにHTMが利用される。マネージドランタイム環境は、JITコンパイラやメモリ・アロケーター等の様々なランタイムヘルパーに依存している。ここで、ランタイムヘルパーとは、インタープリタとJITコンパイルされた実行コードには含まれないが、実行時にインタープリタとJITコンパイルされたコードから呼び出される仮想マシンの機能をいう。しかしながらこれらランタイムヘルパーの中には、トランザクション実行中に呼び出され実行されるとアボートを引き起こすものもある。
　アボートに対処する従来技術として、特許文献１～３及び非特許文献１～３が存在する。特許文献１及び非特許文献２は、HTMのハードウェアが提供するアボート理由の情報に応じてアボート・ハンドラの中で適切な処理を行う技術を開示する。また、特許文献２は、あるトランザクションを実行中に一時的にトランザクションを中断して任意の処理を行い、その後トランザクションを開始する技術を開示する。特許文献３は、複数のトランザクショナルメモリの実装を実行時に切り替える技術を開示する。
　また非特許文献１は、トランザクションがアボートした場合に、複数回リトライした後非トランザクションパスを実行し、その後再びトランザクションを実行する技術を開示する。非特許文献３は、トランザクション同士の衝突が原因でアボートした場合において、トランザクションの再実行を遅延させる技術を開示する。
米国特許出願公開第２０１０／１３１９５３号明細書 米国特許出願公開第２０１０／３３２８０７号明細書 米国特許出願公開第２００９／１７２３０６号明細書
Dave Dice, Yossi Lev, Mark Moir, Dan Nussbaum, "Early Experience with a Commercial Hardware Transactional Memory Implementation", In Sun Microsystems Technical Report TR-2009-180, 2009 Amy Wang, Peng Wu, Matthew Gaudet, Jose Nelson Amaral, Martin Ohmacht, Christopher Barton, Raul Silvera Maged Michael,"Evaluation of Blue Gene/Q Hardware Support for Transactional Memories",In PACT 2012 Mohammad Ansari, Mikiel Lujan, Chris Kirkham, Kim Jarvis, Christos Kotselidis, lan Watson, "Steal-on-abort:Dynamic Transaction Reordering to Reduce Conflicts inTransactional Memory", 4th Int’l ACM Sigplan Conferenceon High Performance Embedded Architectures and Compilers (HiPEAC’09),ACMPress, pp. 4-18, 2009.
　しかしながら、上述したランタイムヘルパーの呼び出しによって引き起こされるアボートは、単純にトランザクションをリトライしただけでは解決しない。
　例えばJITコンパイラは、あるメソッドが所定回数実行された場合に呼び出されるものである。しかしその呼び出しがトランザクション中になされると、JITコンパイラが使用する作業領域のサイズが、ハードウェアによりサポートされるトランザクションサイズを超えるため、アボートが起きる。
　また、シンボル解決（Symbol resolution）又はコード修正（codepatching）は、実行時にメソッド内のシンボルをオンデマンドで解決し、結果としてシンボルを参照するコードを修正するものである。そのためシンボル解決がトランザクション中に実行されると、アボートが起きる。
　また、スレッドローカルヒープ（thread-local heap: TLH）割り付けは、しばしばプログラムによって呼び出され、ヒープからTLHを割り付け、これをゼロでクリアするものである。しかしTLH割り付けがトランザクション中になされると、ゼロクリーニング（zero-clearing）が上述したトランザクションサイズの上限を超えてオーバーフローするため、アボートが起きる。
　また、非同期ガーベジコレクション（GC）チェックの実行は、stop-the-world GCによって設定されたフラグを定期的にチェックする各アプリケーションがスリープすることによって開始される。しかしながらトランザクション中におけるスリープのためのシステムコール呼び出しは許されないため、トランザクション中に上記フラグの設定が検出されると、アボートが起きる。
　また、クラスロードは、プログラムの実行中にオンデマンドでクラスをロードするものである。もしトランザクション中にクラスロードが起きると、I/Oがトランザクションをアボートする。
　このようにランタイムヘルパーによって引き起こされるアボートの原因は様々であり、かつ単純にトランザクションをリトライするだけではアボートし続けるため、従来技術によって解決することは困難である。
　特許文献１及び非特許文献２の技術は、HTMのハードウェアが提供するアボート理由を利用するが、例えばトランザクション中に非同期GCチェック又はクラスロードが呼ばれたとすると、アボートの理由はハードウェアの観点からはどちらもシステムコール呼び出しである。そのため特許文献１及び非特許文献２の技術では、両者の区別がつかずそれぞれに対し異なる適切な処置を取ることができない。
　また、特許文献２の技術によれば、サスペンド命令及びレジューム命令でアボートを引き起こし得るランタイムヘルパーを囲むことによりアボートを避けることが可能である。しかしながら特許文献２の技術の利用は、サスペンド命令及びレジューム命令がハードウェアによりサポートされていることが前提となるため、サポートのないハードウェアについては依然として問題が残る。
　また特許文献３の技術によれば、複数のトランザクショナルメモリの実装を実行時に切り替えることが必要となる。しかし切り替えのタイミングとして特許文献３において記載されているのはパフォーマンス、現在のワークロード、及びリソースの配置のみであるため、アボートを引き起こし得るランタイムヘルパーの種別に応じて適切な処理を行うことは出来ない。
　また、非特許文献１の技術は、所定回数のアボートを条件として非トランザクションパスを実行し、その後再度トランザクションを実行する手法である。しかしアボートを引き起こし得るランタイムヘルパーの種別によっては所定回数のアボートが無駄であったり、非トランザクションパスの実行によっても問題が解決しなかったりする。従って、ランタイムヘルパーの種別に応じて適切な処理を行うことが必要であるが、そのための手法は非特許文献１には記載されていない。
　また、非特許文献３の技術は、トランザクション同士の衝突が原因でアボートした場合にトランザクションの再実行をしばらく遅らせる手法である。従って、ランタイムヘルパーの呼び出しに起因するアボートに対して該技術を適用してもアボートが解消されることはない。
　この発明は、上記の問題点を解決するためになされたものであって、トランザクションブロックを実行中にランタイムヘルパーが呼び出されることに起因するアボートの回数を削減するための技術を提供することを目的とする。
　上記課題を解決するために、本発明の１態様によれば、以下のような、ハードウェアトランザクショナルメモリを用いたプログラム実行においてアボートの回数を削減するためのコンピュータによる方法が提供される。そのアボート削減方法は、（ａ）前記コンピュータが、トランザクションブロックの実行中におけるランタイムヘルパーの呼び出しに応答して、前記ランタイムヘルパーを実行するステップと、（ｂ）前記ランタイムヘルパーの呼び出しに起因したアボートに応答して、前記コンピュータが、アボート・ハンドラを実行するステップと、（ｃ）ステップ（ｂ）の前記アボート・ハンドラの実行の後、前記コンピュータが、前記トランザクションブロックに対応する非トランザクションパスを実行するステップとを含む。そして、前記ランタイムヘルパーの実行は、ランタイムヘルパーの種別を示すID情報を前記アボート・ハンドラに渡すための処理を含み、前記アボート・ハンドラの実行は、アボートの原因となった前記ランタイムヘルパーの前記ID情報を取得し、特定の種別のランタイムヘルパーに対して前記トランザクションブロックを無効化する処理を含む。なお、上述したように、ランタイムヘルパーとは、インタープリタとJITコンパイルされた実行コードには含まれないが、実行時にインタープリタとJITコンパイルされたコードから呼び出される仮想マシンの機能をいう。また、トランザクションブロックとは、トランザクション開始命令とトランザクション終了命令で囲まれたプログラム領域であり、ハードウェアトランザクショナルメモリを用いたプログラム実行において、トランザクションとして実行されるプログラム領域である。
　好ましくは、前記特定の種別のランタイムヘルパーに対して前記トランザクションブロックを無効化する処理は、非トランザクションパスにおいても実行不可能な第１の種別のランタイムヘルパーに対し無条件で前記トランザクションブロックを無効化する処理と、非トランザクションパスにおいては実行可能な第２の種別のランタイムヘルパーに対し、一度の前記非トランザクションパスを実行中に前記第２の種別のランタイムヘルパーが呼び出されないことを条件として前記トランザクションブロックを無効化する処理とを含む。
　ここで、第１の種別のランタイムヘルパーは、実行時コード修正を含み、前記第２の種別のランタイムヘルパーは、実行時コンパイルとクラスロードとを含む。
　より好ましくは、上記アボート削減方法は、（ｄ）条件付きで前記トランザクションブロックが無効化された場合において、前記コンピュータが、プログラムが定常状態に達したことに応答して前記トランザクションブロックを再有効化するステップを更に含む。
　上記トランザクションブロックの再有効化の構成に代えて以下の構成を採用してもよい。即ち、前記ランタイムヘルパーの実行は、前記ランタイムヘルパーが前記第２の種別のランタイムヘルパーである場合に、その処理内容を、非トランザクション書き込み命令を用いて記録し、及び、前記ID情報を引数としてトランザクションアボート命令を発行する処理を含む。また、前記アボート・ハンドラの実行は、前記第２の種別のランタイムヘルパーに対して前記トランザクションブロックを無効化する場合に、前記記録した処理内容を表に登録する。そして、上記アボート削減方法は、（ｅ）前記コンピュータが、前記表に登録された処理内容が実行されたことに応答して、前記トランザクションブロックを再有効化するステップを更に含む。
　ここで、前記第２の種別のランタイムヘルパーが実行時コンパイルである場合、前記処理内容は、コンパイルすべきメソッドの識別情報であり、前記第２の種別のランタイムヘルパーがクラスロードである場合、前記処理内容は、ロードすべきクラスの識別子である。
　また好ましくは、前記アボート・ハンドラは、スレッドローカルヒープ割付と、非同期ガーベジコレクションチェックとを、前記特定の種別以外のランタイムヘルパーと判断する。
　また好ましくは、上記アボート削減方法は、（ｆ）前記コンピュータが、プログラムの実行開始において全てのトランザクションブロックを無効化するステップと、（ｇ）前記コンピュータが、前記プログラムの実行開始から所定の期間が経過することに応答して、前記全てのトランザクションブロックを有効化するステップとを更に含む。
　また好ましくは、前記ランタイムヘルパーの実行は、トランザクションアボート命令を発行する処理を含み、前記ID情報をアボート・ハンドラに渡すための処理は、前記ID情報を前記トランザクションアボート命令の引数とする処理を含む。これに代えて、前記ID情報をアボート・ハンドラに渡すための処理は、非トランザクション書き込み命令を用いて前記ID情報を記録する処理を含み、該処理の後前記ランタイムヘルパーは本来のランタイムヘルパーの処理を行ってもよい。
　また好ましくは、前記ランタイムヘルパーの実行は、該ランタイムヘルパーが前記特定の種別と異なる他の種別のランタイムヘルパーであることを条件に、その実行に必要な情報を、非トランザクション書き込み命令を用いて記録する処理を含む。また、前記アボート・ハンドラの実行は、前記他の種別のランタイムヘルパーに対し、記録された前記必要な情報を用いてその実行を行う処理を含む。そして、該処理の後ステップ（ｃ）の代わりに、（ｈ）前記コンピュータが、前記トランザクションブロックを再実行するステップを含む。
　上記ランタイムヘルパーの実行遅延のための構成に代えて以下の構成を採用してもよい。即ち、前記ランタイムヘルパーの実行は、該ランタイムヘルパーが前記特定の種別と異なる他の種別のランタイムヘルパーであることを条件に、その実行に必要な情報を、非トランザクション書き込み命令を用いて記録する処理と、その実行をキャンセルする処理とを含む。そして、上記アボート削減方法は、（ｉ）前記コンピュータが、前記トランザクションブロックを実行後、前記他の種別のランタイムヘルパーに対し、記録された前記必要な情報を用いてその実行処理を行うステップを更に含む。
　ここで、前記特定の種別のランタイムヘルパーはクラスロードを含み、前記他の種別のランタイムヘルパーは、実行時コンパイルであり、前記実行に必要な情報はコンパイルすべきメソッドの識別情報である。また、前記特定の種別のランタイムヘルパーはクラスロードを含み、前記他の種別のランタイムヘルパーは、実行時コード修正であり、前記実行に必要な情報は実行時コード修正されるべきアドレス及びデータである。
　また好ましくは、前記ランタイムヘルパーが実行時コンパイルである場合に、前記ランタイムヘルパーの実行は、コンパイル対象のコードに含まれるトランザクションブロック内の実行時コード修正の呼び出しを、トランザクションアボート命令で置換し、該トランザクションアボート命令のアドレスから前記実行時コード修正に必要な情報への対応表を作成する処理を含む。そして上記アボート削減方法は、（ｊ）前記コンピュータが、置換された前記トランザクションアボート命令の実行に応答してアボート・ハンドラを実行した後に、前記トランザクションブロックを再実行するステップを更に含む。ここで前記アボート・ハンドラの実行は、前記トランザクションアボート命令のアドレスから前記対応表を引いて必要な情報を取得することにより前記実行時コード修正を行い、前記トランザクションアボート命令をｎｏｐ命令で上書きする処理を含む。
　上記コンパイラによる実行時コード修正の置換構成に代えて、以下の構成を採用してもよい。即ち、
前記アボート・ハンドラの実行は、前記ランタイムヘルパーが実行時コード修正であることを条件に、アボートが起きた命令アドレスを含むページを書き込み禁止にし、及び、アボートの原因が書込み保護の例外であることを条件に、前記書込み禁止を無効化し、書込み保護が起きた位置の書き込み命令を識別することにより実行時コード修正されるべきアドレスとデータを取得して、前記実行時コード修正を行う処理をふくむ。そして上記アボート削減方法は、（ｋ）前記コンピュータが、前記アボート・ハンドラによる書き込み禁止処理又は前記実行時コード修正の後ステップ（ｃ）の代わりに、前記トランザクションブロックを再実行するステップを更に含む。
　以上、アボート削減方法として本発明を説明したが、本発明は、上記説明したアボート削減方法の各ステップをコンピュータに実行させるためのアボート削減プログラムとして把握することもできる。また、そのようなアボート削減方法の各ステップを実行するように適合された手段を備えるアボート削減装置として把握することもできる。
　本発明によれば、ランタイムヘルパーの実行において、ランタイムヘルパーの種別を示すID情報をアボート・ハンドラに渡すための処理が行われるので、アボート・ハンドラにおいてランタイムヘルパーの種別に応じた処理が最初から可能となり、特定の種別のランタイムヘルパーに対しては、トランザクションブロックを無効化する処理を行うことができる。結果として、トランザクションブロックを実行中にランタイムヘルパーが呼び出されることに起因するアボートの回数を、無駄なく効率的に削減することができる。本発明のその他の効果については、各実施の形態の記載から理解される。
本発明の実施の形態に係るアボート削減装置を実現するのに好適なコンピュータ・システム１００のハードウェア構成の一例を示した図である。 図１に示すコンピュータ・システム１００のソフトウェアの構成の一例を示す図である。 本発明の実施の形態に係るアボート削減処理全体の流れの一例を示すフローチャートである。 ランタイムヘルパーによる処理の流れの一例を示すフローチャートである。 図５（ａ）は、アボート・ハンドラによる処理の前半の処理の流れの一例を示すフローチャートである。図５（ｂ）は、アボート・ハンドラによる処理の後半の処理の流れの一例を示すフローチャートである。 非トランザクション・パスの実行処理の流れの一例を示すフローチャートである。 図７（ａ）は、トランザクションブロックの有効化処理の流れの一例を示すフローチャートである。図７（ｂ）は、トランザクションブロックの有効化処理の流れの他の例を示すフローチャートである。 ランタイムヘルパーによる処理の流れの他の例を示すフローチャートである。 ランタイムヘルパーによる処理の流れの他の例を示すフローチャートである。 アボート・ハンドラによる処理の一部の流れの他の例を示すフローチャートである。 ＪＩＴコンパイラによる処理の流れの一例を示すフローチャートである。 アボート・ハンドラによる処理の一部の流れの他の例を示すフローチャートである。 アボート・ハンドラによる処理の一部の流れの他の例を示すフローチャートである。 ランタイムヘルパーによる処理の流れの他の例を示すフローチャートである。 アボート・ハンドラによる処理の一部の流れの他の例を示すフローチャートである。 トランザクションブロックの有効化処理の流れの他の例を示すフローチャートである。 図１７（ａ）は、従来技術と本発明とでスレッド数に応じたスループットを比較した実験結果を示す図である。図１７（ｂ）は、従来技術と本発明とでスレッド数に応じたスループットを比較した実験結果を示す図である。
　以下、本発明を実施するための形態を図面に基づいて詳細に説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。なお、実施の形態の説明の全体を通じて同じ要素には同じ番号を付している。
　図１は、本発明を実施するのに好適なコンピュータ・システム１００のハードウェア構成の一例を示す。コンピュータ・システム１００は、バス１０６に接続されたメインCPU（中央処理装置）１０２とメイン・メモリ１０４を含んでいる。CPU１０２は、並列処理が可能なマルチプロセッサとされ、HTM１０２ａを含んで構成される。HTM１０２ａは、ハードウェアとして実装されるトランザクショナルメモリで、上述したように、実行しているスレッドの各々がそのコピーをローカルにもち、処理が終了した時点でその共有リソースの値が変更されていないことを確認し、処理結果を一気に書き込む。また、HTM１０２ａは、他のスレッドにより書き換えられている場合は、それらの値が変更されているため、処理そのものを廃棄してやり直すことができる。更にHTM１０２ａによるトランザクションは、いつでもアボートすることがあり、アボートすると、そのトランザクションがそれまでに行った共有データへの変更は取り消され、ロールバックする。なお、トランザクションとは、１つのスレッドで実行される一連の不可分な処理をまとめたものである。
　バス１０６には、ディスプレイ・コントローラ１０８を介して、ディスプレイ１１０、例えば液晶ディスプレイ（ＬＣＤ）が接続されうる。ディスプレイ１１０は、コンピュータの管理のために、通信回線を介してネットワークに接続されたコンピュータについての情報と、そのコンピュータ上で動作中のソフトウェアについての情報を、適当なグラフィック・インタフェースで表示するために使用される。
　バス１０６にはまた、ＳＡＴＡ又はＩＤＥコントローラ１１２を介して、ディスク１１４、例えばシリコン・ディスク又はハードディスクが接続されうる。バス１０６にはまた、ＳＡＴＡ又はＩＤＥコントローラ１１２を介して、任意的に、ドライブ１１６、例えばＣＤ、ＤＶＤまたはＢＤドライブが接続されうる。バス１０６にはさらに、任意的に、キーボード・マウスコントローラ１１８又はＵＳＢバス（図示せず）を介して、キーボード１２０及びマウス１２２が接続されうるが、本発明を実施する上では必要ない。　　
　ディスク１１４には、オペレーティング・システム、Java（登録商標）仮想マシン（VM）等の仮想マシンを提供するプログラム、その他のプログラム及びデータが、メイン・メモリ１０４にロード可能なように記憶されている。
　本発明の実施形態によるアボート削減プログラムは、仮想マシンを提供するプログラムの一部、即ち、インタープリタ、コンパイル済みコード実行部、アボート・ハンドラ、及び複数のランタイムヘルパーを、それぞれ後述する機能を提供可能なように修正することによって実装可能である。
　上記コンピュータ・プログラムは圧縮し、また複数に分割して複数の媒体に記録することもできる。ドライブ１１６は、必要に応じて、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭまたはＢＤからプログラムをディスク１１４にインストールするために使用されうる。
　通信インタフェース１２６は、例えばイーサネット（登録商標）・プロトコルに従う。通信インタフェース１２６は、通信コントローラ１２４を介してバス１０６に接続され、コンピュータ・システム１００を通信回線１２８に物理的に接続する役割を担い、コンピュータ・システム１００のオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワーク・インタフェース層を提供する。なお、通信回線は、有線ＬＡＮ環境に基づくもの、又は、無線ＬＡＮ環境、例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎなどのＷｉ－Ｆｉ規格に基づくものであってもよい。
　以上から、本発明の実施態様において使用されるコンピュータ・システム１００は、本発明の実施の形態に係るアボート削減プログラムを格納し、それを実行することが出来る装置であってよく、ＰＣ、サーバ、ワークステーション等をアボート削減装置とすることが可能である。なお、上記説明した構成要素は例示であり、そのすべての構成要素が本発明の必須構成要素となるわけではない。
　図２は、図１に示すコンピュータ・システム１００のソフトウェアの構成の一例を示す図である。CPU１０２は、ディスク１１４からJava（登録商標）仮想マシン（VM）等の仮想マシン、オペレーティング・システムをメイン・メモリ１０４に読み出し実行することにより、仮想マシン２０６、オペレーティング・システム２０２をメイン・メモリ１０４に展開する。オペレーティング・システム２０２は、ＣＰＵ１０２やメモリの管理など、コンピュータ・システム１００が有する基本的な機能を提供するソフトウェアである。
　仮想マシン２０６は、バイトコードの低速実行（Interpret）、およびコンパイル済みコードの実行を行うエミュレータであり、コードの実行を管理し、仮想マシン上で実行されるアプリケーションに対して様々なサービスを提供する。仮想マシン２０６は、インタープリタ２１０と、コンパイル済みコード実行部２１２と、ディスパッチャ２１４と、複数のランタイムヘルパーを含むランタイムヘルパー群２１８と、アボート・ハンドラ２０４を含んで構成される。
　ディスパッチャ２１４は、ランタイムヘルパー群２１８に含まれるJITコンパイラ２２０が生成したコンパイル済みコードを保存するメモリ領域であるコードキャッシュ２１６を参照して、次に実行するバイトコードアドレスから始まるコンパイル済みコードがコードキャッシュ２１６に保存されている否かを判定する。インタープリタ２１０は、コンパイル済みコードが存在しない場合に、処理対象のバイトコードを低速に実行する。コンパイル済みコード実行部２１２は、コンパイル済みコードが存在する場合、コードキャッシュ２１６からコンパイル済みコードを取得して実行する。
　上述したように、本発明においてCPU１０２は、並列処理が可能なマルチプロセッサとされ、HTM１０２ａを含んで構成される。従って、インタープリタ２１０は、実行対象のコードにトランザクション開始命令とトランザクション終了命令とで囲まれたトランザクションブロックが存在する場合、該領域を、HTM１０２ａを利用してトランザクションとして実行する。またJITコンパイルされたコードにトランザクションブロックが含まれる場合、コンパイル済みコード実行部２１２は該領域を、HTM１０２ａを利用してトランザクションとして実行する。
　インタープリタ２１０及びコンパイル済みコード実行部２１２はまた、トランザクションが失敗する場合、それぞれ所定の条件に従って非トランザクションパス（non-transactional path）を実行する。ここで、非トランザクションパスとは、トランザクションブロックの実行が何度もアボートする場合にプログラムを先に進めるため通常実行される、トランザクションブロックと意味的に同じ処理をいう。非トランザクションパスは、トランザクションブロック毎に一つ存在する。両者は意味的に同じであるが、非トランザクションパスの方が実行は遅い。なお、プログラム中にトランザクションブロックを書く場合、非トランザクションパスはプログラマが書く場合もあればコンパイラなどがトランザクションブロックのコードから自動的に生成する場合もある。仮想マシンなどシステムが自動的にトランザクションブロックを作る場合、非トランザクションパスもそのシステムが同時に生成するのが一般的である。本実施形態に係る仮想マシン２０６もまた、プログラム中にトランザクションブロックが存在する場合、及びトランザクションブロックを自動で作る場合、対応する非トランザクションパスを同時に生成するものとする。なお、以下では、インタープリタ２１０及びコンパイル済みコード実行部２１２をまとめて、実行部２０８（特許請求の範囲の請求項１９における実行部に相当）という。
　ランタイムヘルパー２１８は複数のランタイムヘルパーを含む。ランタイムヘルパーは、実行時にインタープリタやJITコンパイルされたコードから呼び出される仮想マシンの機能である。ランタイムヘルパーの中には、トランザクション中に実行されるとトランザクションをアボートさせる可能性のあるものも存在し、本明細書ではそのようなランタイムヘルパーを、アボート性ランタイムヘルパー（abort-prone runtime helper）２１９と呼ぶ。アボート性ランタイムヘルパー２１９であるか否かはHTMの実装にも依存するが、一例として、JITコンパイラ２２０、クラスローダー２２２、非同期ガーベジコレクター（garbage collector：GC）２２４、TLHアロケータ２２６、シンボル・リゾルバー２２８を挙げることができる。本発明は、アボート性ランタイムヘルパー２１９によって引き起こされるアボートの回数を削減することを目的とする。そこでまずは上に挙げた個々のアボート性ランタイムヘルパーについて説明する。
　JITコンパイラ２２０は、あるメソッドが所定回数実行された場合に呼び出されるものである。しかしその呼び出しがトランザクション中になされると、JITコンパイラ２２０が使用する作業領域のサイズがハードウェアによりサポートされるトランザクションサイズを超えるため、アボートが起きる。そこで考えられる解決方法は、一度だけ非トランザクションパスを実行し、その間にJITコンパイル対象のメソッドが実行されることを期待することである。もし、非トランザクションパスを実行中にJITコンパイル対象のメソッドが実行されれば、JITコンパイラ２２０はトランザクションブロックの外で呼び出され、成功裏に実行される。一方、非トランザクションパスを実行中にJITコンパイル対象のメソッドが実行されない場合は、トランザクションブロックを無効化し、プログラムが定常状態になるのを待って再度トランザクションブロックを有効化する。
　クラスローダー２２２は、プログラムの実行中にオンデマンドでクラスをロードするものである。もしトランザクション中にクラスロードが起きると、I/Oがトランザクションをアボートする。そこで考えられる解決方法は、一度だけ非トランザクションパスを実行し、その非トランザクションパスが同じクラスを使用することを期待することである。もし、非トランザクションパスを実行中に同じクラスが使用されれば、クラスローダー２２２はトランザクションブロックの外で呼び出され、成功裏に実行される。一方、非トランザクションパスを実行中に同じクラスが使用されない場合は、トランザクションブロックを無効化し、プログラムが定常状態になるのを待って再度トランザクションブロックを有効化する。
　非同期GC２２４は、stop-the-worldGCによって設定されたフラグを定期的にチェックする各アプリケーションがスリープすることによって呼び出される。しかしながらトランザクション中におけるスリープのためのシステムコール呼び出しは許されないため、トランザクション中に上記フラグの設定が検出されると、アボートが起きる。そこで考えられる解決方法は、非トランザクションパスを実行することである。非トランザクションパスを実行することで、次にトランザクションに入る前に、現在のスレッドが別の非同期GCチェックポイントに到達し、これによってトランザクションブロックの外で非同期GC２２４が呼び出されることが期待できる。
　TLHアロケータ２２６は、しばしばプログラムによって呼び出され、ヒープからTLHを割り付け、これをゼロでクリアするものである。しかしTLH割り付けがトランザクション中になされると、ゼロクリーニングがトランザクションサイズの上限を超えてオーバーフローするため、アボートが起きる。そこで考えられる解決方法は、非トランザクションパスを実行することである。非トランザクションパスを実行することで、次にトランザクションに入る前に、現在のスレッドが新しいオブジェクトを割り付け、これによってトランザクションブロックの外でTLHアロケータ２２６が呼び出されることが期待できる。
　シンボル・リゾルバー２２８又はコード修正は、実行時にメソッド内のシンボルをオンデマンドで解決し、結果としてシンボルを参照するコードを修正するものである。そのためシンボル解決がトランザクション中に実行されると、アボートが起きる。しかしこの場合、非トランザクションパスを実行しても、トランザクションパス上のコードが修正されることはないので、問題解決にはならない。従って考えられる解決方法は直ちにトランザクションブロックを無効化して、無駄にアボートが起きないようにすることである。
　このように、アボート性ランタイムヘルパー２１９によって引き起こされるアボートの原因は様々であり、アボートの回数を削減する解決策もそれぞれ異なる。そこで本発明の実施形態に係るアボート性ランタイムヘルパー２１９はその種類に関わらず、トランザクションブロックの実行中において呼び出されると、そのアボート性ランタイムヘルパー２１９の種別を示すID情報をアボート・ハンドラ２０４に渡す。好ましくは、アボート性ランタイムヘルパー２１９は、トランザクションブロックの実行中において呼び出されると、本来の処理を行うことなくそのID情報をアボート原因を示す引数としてトランザクションアボート命令を発行する。　
　トランザクションアボート命令が実行されることにより呼び出されるアボート・ハンドラ２０４は、アボートの原因となったアボート性ランタイムヘルパー２１９のID情報を取得し、ID情報が特定の種別のアボート性ランタイムヘルパー２１９であることを示す場合に、トランザクションブロックを無効化する。好ましくは、アボート・ハンドラ２０４は、非トランザクションパスにおいても実行不可能な第１の種別のランタイムヘルパーに対し無条件でトランザクションブロックを無効化する。また、アボート・ハンドラ２０４は、非トランザクションパスにおいては実行可能な第２の種別のランタイムヘルパーに対し、一度だけ非トランザクションパスを実行し、その実行中に第２の種別のランタイムヘルパーが呼び出されなかった場合にトランザクションブロックを無効化する。ここで、第１の種別のランタイムヘルパーは、実行時コード修正を含み、第２の種別のランタイムヘルパーは、JITコンパイルとクラスロードとを含む。なお、アボート・ハンドラ２０４は、TLH割り付けと、非同期GCチェックとを、特定の種別以外のランタイムヘルパーとして判断し、これらに対しては何もしない。
　アボート・ハンドラ２０４による処理の後は、実行部２０８が、アボートが起きたトランザクションブロックに対応する非トランザクションパスを実行する。また、アボート・ハンドラ２０４によって条件付きでトランザクションブロックが無効化された場合、実行部２０８は、プログラムが定常状態に達したことに応答してトランザクションブロックを再有効化する。これは、プログラムが定常状態おいては、アボートの原因となったクラスがロードされ、また、アボートの原因となったメソッドがコンパイルされていることを期待するからである。このようにアボートの原因が解決されるまでの間のトランザクションブロックを無効化した状態を、本明細書においては一時的な非トランザクションモードと呼ぶ。なお、プログラムが定常状態に達したか否かの判定は、十分な数のクラスがロードされたか否か、又は十分な数のメソッドがコンパイルされたか否か、或いはその両方であるか否かによって判定してよく、例えば、以下のような方法が挙げられる。
・新しいクラスがロードされない時間、又は新しいメソッドがコンパイルされない時間、或いはその両方が10秒間以上続いた
・クラスが新たに1000個ロードされた、又はメソッドが新たに1000個コンパイルされた、或いはその両方である
・1秒間にロードされるクラス数、又は1秒間にコンパイルされるメソッド数、あるいはその両方を監視して、10個/秒未満になった
なお、10秒、1000個などの数は一例であり、予備実験で最適な値を予め求めておくのが好ましい。
　上述したアボート削減の方法は、アボート削減のベースの手法として以下に記載する４つの観点から拡張することが可能である。
A.一時的な非トランザクションモードに入るタイミング
　A1.　一時的な非トランザクションモードへ入るタイミングをトランザクションごとに決定する（ベースの手法）
　A2.　プログラム実行開始直後のウォーミングアップにおいて一時的な非トランザクションモードに積極的に入っておく（その後プログラムが安定状態となった後にA1.の手法を採用）
B.アボート原因の識別方法
　B1.　アボート性ランタイムヘルパー２１９のID情報をアボートの原因を示す情報とし、トランザクションアボート命令の引数とする（ベースの手法）
　B2.　非トランザクション書き込み命令を用いて、アボート性ランタイムヘルパー２１９のID情報を現在実行中のスレッドのランタイムヘルパーの記録領域に記録する
　B3.　非トランザクション書き込み命令を用いて、アボート性ランタイムヘルパー２１９のID情報のみならず、アボート性ランタイムヘルパー２１９の処理に必要な情報をも現在実行中のスレッドのランタイムヘルパーの記録領域に記録する
　B4.　トランザクションアボート命令の命令アドレスからコード修正に必要な情報への対応表を作成する
　B5.　ページ保護機能を利用する
なお、非トランザクション書き込み命令とは通常の書き込み命令を意味し、トランザクションがアボートしてもロールバックされることはない書き込み命令をいう。
C.アボート原因の解決方法
　C1.　 非トランザクションパスの実行、又はトランザクションブロックの無効化、或いはその両方（ベースの手法）
　C2.　 アボート性ランタイムヘルパー２１９の処理を遅延させ、アボート・ハンドラ２０４の実行中に行う
D.一時的な非トランザクションモードから抜け出すタイミング
　D1.　プログラムが定常状態に達するのまで待つ（ベースの手法）
　D2.　アボート・ハンドラ２０４内での遅延処理が終わるまで待つ
　D3.　アボートにより実行されなかったクラスロードの全てのクラスがロードされ、又はコンパイルされなかった全てのメソッドがコンパイルされ、或いはその両方がなされるまで待つ
　ベースの手法を第１の実施形態とし、上述した拡張方法を組み合わせてなし得る他の５つの実施形態を第２の実施形態～第６の実施の形態として以下に説明する。
第２の実施形態（A1+B2+C1+D1）
　あるランタイムヘルパーがトランザクションを実行中に呼び出された場合にアボートを引き起こすか否かはHTMの実装に依存する。例えば、JITコンパイルは、非常に大きいトランザクションサイズをサポートする実装上ではトランザクションのアボートを引き起こすことはない。このような実装において、アボート性ランタイムヘルパー２１９がトランザクション中に呼び出される度トランザクションアボート命令を発行すると、パフォーマンスの低下を招いてしまう。
　そこで第２の実施形態では、トランザクションアボート命令を発行する代わりに、アボート性ランタイムヘルパー２１９は、その本来の処理が実行されたことを、非トランザクション書き込み命令を用いて現在実行中のスレッドの記憶領域に記録する。アボート・ハンドラ２０４は、そのような記録が存在するか否かを判定し、存在する場合にその記録に基づきアボートの原因を決定する。ここでアボート性ランタイムヘルパー２１９が記録領域に記録すべき情報は、一例としてそれ自体のID情報であってよい。
第３の実施形態（A1+B3+C2+D2）
　ベースの第１の実施形態では、アボート性ランタイムヘルパー２１９がコード修正の場合、直ちにトランザクションブロックを無効化する。アボート性ランタイムヘルパー２１９がJITコンパイラ２２０である場合も、１度の非トランザクションパスの実行においてJITコンパイラ２２０が呼び出されないことを条件にトランザクションブロックを無効化する。上述したように非トランザクションパスの実行はトランザクションブロックの実行よりも遅いので、トランザクションブロックを無効化するとパフォーマンスが低下する。
　そこで第３の実施の形態では、トランザクション中に呼び出されるアボート性ランタイムヘルパー２１９がJITコンパイラ２２０やシンボル・リゾルバー２２８である場合、その実行を遅延させ、アボート・ハンドラ２０４内で実行させる。JITコンパイラ２２０やシンボル・リゾルバー２２８はプログラマから見える副作用を持たず（programexecution semantics）、その実行順序は厳しく定義されるものではないため、このように実行を遅延させても問題はない。その一方で、クラスローダー２２２は、プログラマから見える副作用を持つ（programmer-visiblesemantics）ためこのような遅延は許されない。
　トランザクションアボート命令を発行する代わりに実行を遅延させるため、JITコンパイラ２２０やシンボル・リゾルバー２２８であるアボート性ランタイムヘルパー２１９は、そのID情報と共に本来の処理に必要な情報を、非トランザクション書き込み命令を用いて現在実行中のスレッドの記憶領域に記録する。アボート・ハンドラ２０４は、そのような記録が存在するか否かを判定し、存在する場合にその記録に基づきJITコンパイル又はコード修正を行う。ここでJITコンパイラ２２０が記録領域に記録すべき情報は、コンパイルすべきメソッドの識別情報である。また、シンボル・リゾルバー２２８が記録領域に記録すべき情報は、実行時コード修正されるべきアドレス及びデータである。アボート・ハンドラ２０４による上記処理が終了した後は、実行部２０８がトランザクションブロックを再実行する。
第４の実施形態（A1+B4+C2+D2） 
　第３の実施の形態では非トランザクション書き込み命令を利用した。しかしながら非トランザクション書き込み命令をサポートしないマシンも存在する。
　そこで第３の実施の形態では、非トランザクション書き込み命令を用いる代わりに、JITコンパイラ２２０による本来の処理に以下に説明する処理を追加する。即ち、JITコンパイラ２２０は、コンパイル対象のコードに含まれるトランザクションブロック内の実行時コード修正の呼び出しを、トランザクションアボート命令で置換し、該トランザクションアボート命令のアドレスから実行時コード修正に必要な情報への対応表を作成する。ここで実行時コード修正に必要な情報とは、実行時コード修正されるべきアドレス及びデータである。
　置換されたトランザクションアボート命令の実行により呼び出されたアボート・ハンドラ２０４は、トランザクションアボート命令のアドレスから上記対応表を引いて必要な情報を取得する。そして、アボート・ハンドラ２０４は、取得した情報に基づいて実行時コード修正を行い、上記トランザクションアボート命令をｎｏｐ命令で上書きする。アボート・ハンドラ２０４による上記処理が終了した後は、実行部２０８がトランザクションブロックを再実行する。
第５の実施形態（A1+B5+C2+D2）
 コード修正は、シンボル解決だけでなく、JITコンパイルや多相的インライン・メソッド・キャッシュ（polymorphic inline methodcaching）など、JITコンパイルされたコードにおいてよく利用される。しかしながらこれまで述べてきたように、コード修正はトランザクションを実行中に呼び出されるとアボートを引き起こす。第３の実施形態のようにアボート・ハンドラ２０４の処理が開始されるまでその実行を遅延させることもできるが、ソフトウェアエンジニアリングの観点からすれば、マネージドランタイムにおいて、全てのコード修正の位置で遅延処理のためのロジックを挿入することは現実的ではない。
　そこで、第５の実施形態では、全てのコード修正の位置で遅延処理のためのロジックを挿入することなしにコード修正の処理を遅延させる。そのためにまず、アボート・ハンドラ２０４は、アボートを引き起こしたアボート性ランタイムヘルパー２１９が実行時コード修正であることを条件に、アボートが起きた命令アドレスを含むページを書き込み禁止にする。その後実行部２０８が、トランザクションブロックを再実行する。そして、次に呼び出されたアボート・ハンドラ２０４は、アボートの原因が書込み保護の例外であることを条件に、先ほどの書込み禁止を無効化し、書込み保護が起きた位置の書き込み命令を識別することにより実行時コード修正されるべきアドレスとデータを取得して、実行時コード修正を行う。その後実行部２０８が、トランザクションブロックを再再実行する。
第６の実施の形態（A1+B1+C1+D3）
　ベースの第１の実施形態では、JITコンパイラ２２０又はクラスローダー２２２のトランザクション中の呼び出しに起因してトランザクションブロックを無効化した場合、プログラムが定常状態になるのを待ってトランザクションブロックを再有効化する。しかしながら、プログラムの定常状態において、原因となったメソッドがJITコンパイルされ、又は原因となったクラスがロードされているという保証はない。
　そこで第６の実施形態では、原因となったメソッドがJITコンパイルされ、又は原因となったクラスがロードされたことを確認した後にトランザクションブロックを有効化するようにする。そのために、第６の実施形態では、トランザクション実行中に呼び出されたJITコンパイラ２２０及びクラスローダー２２２は、その処理内容を、非トランザクション書き込み命令を用いて現在実行中のスレッドの記憶領域に記録し、及び、ID情報を引数としてトランザクションアボート命令を発行する。ここで処理内容は、JITコンパイラ２２０の場合コンパイルすべきメソッドの識別情報であり、クラスローダー２２２の場合、ロードすべきクラスの識別子である。
　トランザクションアボート命令により呼び出されたアボート・ハンドラ２０４は、JITコンパイラ２２０及びクラスローダー２２２に対してトランザクションブロックを無効化する場合に、現在実行中のスレッドの記憶領域に記録された情報を読み出してグローバル表に登録する。その後実行部２０８は、グローバル表に登録された処理内容が実行されたことに応答して、トランザクションブロックを再有効化する。
　次に図３～図１６を参照して、本発明のアボート削減処理の流れを説明する。まず、図３～図７を参照して、第１の実施形態によるアボート削減処理の流れを説明する。図３は、本発明の実施の形態に係るアボート削減処理全体の流れの一例を示すフローチャートである。図４は、アボート性ランタイムヘルパー２１９による処理の流れの一例を示すフローチャートである。図５（ａ）及び（ｂ）は、アボート・ハンドラ２０４による処理の一部の流れの一例を示すフローチャートである。図６は、非トランザクション・パスの実行処理の流れの一例を示すフローチャートである。図７（ａ）及び（ｂ）は、トランザクションブロックの有効化処理の流れの一例を示すフローチャートである。
　図３に示すフローチャートは、トランザクションブロックの実行により開始し、実行部２０８は、実行しようとする現在のトランザクションブロックが無効化されているか否かを判定する（ステップ３００）。現在のトランザクションブロックが無効化されていない場合（ステップ３００：ＮＯ）、続いて実行部２０８は、現在のトランザクションブロックのリトライ回数をカウントするためのリトライ・カウンタを正の整数で初期化する（ステップ３０２）。実行部２０８はまた、現在のトランザクションブロックの実行回数をカウントするための実行カウンタを１増やす（ステップ３０４）。そして実行部２０８は、トランザクションを開始し、実行する（ステップ３０６、ステップ３０８）。なお、リトライ・カウンタはスレッドごと、実行カウンタと後述するアボート・カウンタは、トランザクションブロックごと保持するものとする。なお、実行カウンタとアボート・カウンタの初期化は、対応するトランザクションブロックを含むコードがロードされた際に初期化される。
　続いて実行部２０８は、トランザクション内でアボート性ランタイムヘルパー２１９が呼び出されたか否かを判定する（ステップ３１０）。アボート性ランタイムヘルパー２１９が呼び出された場合（ステップ３１０：ＹＥＳ）、処理はステップ３１２へ進み、呼び出されたアボート性ランタイムヘルパー２１９により処理がなされる。アボート性ランタイムヘルパー２１９による処理の詳細は、図４を参照して後述する。アボート性ランタイムヘルパー２１９による処理の後、又は、アボート性ランタイムヘルパー２１９が呼び出されなかった場合（ステップ３１０：ＮＯ）、処理はステップ３１４へ進み、実行部２０８は、トランザクション内でアボートが起きたか否かを判定する。
　トランザクション内でアボートが起きた場合（ステップ３１４：ＹＥＳ）、処理はステップ３１６へ進み、アボート・ハンドラ２０４による処理がなされる。アボート・ハンドラ２０４による処理の詳細は、図５を参照して後述する。一方トランザクション内でアボートが起きなかった場合（ステップ３１４：ＮＯ）、処理はステップ３２０へ進み、実行部２０８はトランザクションを終了して（ステップ３２０）、処理を終了する。
　ステップ３１６におけるアボート・ハンドラ２０４による処理は２つの結果を有し、結果が２を示す場合、処理はステップ３０６へ戻って、現在のトランザクションブロックの実行を再度試みる。一方、アボート・ハンドラ２０４による処理の結果が１を示す場合、又はステップ３００において現在のトランザクションブロックが無効化されていると判定した場合（ステップ３００：ＹＥＳ）、処理はステップ３１８へ進み、実行部は非トランザクションパスを実行する。非トランザクションパス実行処理の詳細は、図６を参照して後述する。非トランザクションパス実行処理の後、処理は終了する。
　図４に示すフローチャートは、図３に示すフローチャートのステップ３１２におけるアボート性ランタイムヘルパー２１９による処理の詳細を示す。処理はステップ４００で開始し、アボート性ランタイムヘルパー２１９は、そのアボート性ランタイムヘルパー２１９の種別を示すＩＤをアボートの原因を示す引数として、トランザクションアボート命令を発行する。その後アボート性ランタイムヘルパー２１９は処理を終了する。なお、図４に示すフローチャートの処理は、アボート性ランタイムヘルパー２１９がトランザクションを実行中に呼び出された場合に実行されるものであり、トランザクションが実行中でない場合には、アボート性ランタイムヘルパー２１９はそれぞれ本来の処理を行うことに留意されたい。
　図５（ａ）に示すフローチャートは、図３に示すフローチャートのステップ３１６におけるアボート・ハンドラ２０４による処理の前半を示す。処理はステップ５００で開始し、アボート・ハンドラ２０４は、アボートの原因がTLH割り付け又は非同期GCチェックであるか否かを判定する。アボートの原因がTLH割り付け又は非同期GCチェックのいずれかである場合（ステップ５００：ＹＥＳ）、アボート・ハンドラ２０４は１を示す結果を残して処理を終了する。一方、アボートの原因がTLH割り付け又は非同期GCチェックのいずれでもない場合（ステップ５００：ＮＯ）、続いてアボート・ハンドラ２０４は、アボートの原因がシンボル解決であるか否かを判定する（ステップ５０２）。アボートの原因がシンボル解決である場合（ステップ５０２：ＹＥＳ）、アボート・ハンドラ２０４は直ちに現在のトランザクションブロックを無効化し（ステップ５１０）、１を示す結果を残して処理を終了する。
　アボートの原因がシンボル解決でない場合（ステップ５０２：ＮＯ）、続いてアボート・ハンドラ２０４は、アボートの原因がJITコンパイル又はクラスロードであるか否かを判定する（ステップ５０４）。アボートの原因がJITコンパイル又はクラスロードのいずれでもない場合（ステップ５０４：ＮＯ）、処理は図５（ｂ）に示すフローチャートのステップ５２０に続く。一方、アボートの原因がJITコンパイル又はクラスロードのいずれかである場合（ステップ５０４：ＹＥＳ）、続いてアボート・ハンドラ２０４は、現在のトランザクションブロックについてのnon-tx-onceフラグが設定されているか否かを判定する（ステップ５０６）。
　ここでnon-tx-onceフラグとは、トランザクションブロックごとに割り当てるフラグであり、後述するスレッドごとに割り当てるnon-tx-executionフラグと共に用いるフラグである。本実施例ではこれらフラグを用いた制御により、一度だけ非トランザクションパスを実行し、その間にアボートの原因となったJITコンパイル又はクラスロードが実行されないことを条件として、現在のトランザクションブロックを無効化する処理を実現する。なお、non-tx-onceフラグの設定は、図６を参照して後述する非トランザクションパスの実行においてなされ、その設定は、非トランザクションパスの実行中にJITコンパイル又はクラスロードが起きなかったことを示す。
　図５（ａ）のフローチャートのステップ５０６に戻って、non-tx-onceフラグが設定されていない場合（ステップ５０６：ＮＯ）、続いてアボート・ハンドラ２０４は現在実行されているスレッドのnon-tx-executionフラグを設定する（ステップ５０８）。このように、non-tx-executionフラグは、アボートの原因がJITコンパイル又はクラスロードであったこと示す。一方、non-tx-onceフラグが設定されていた場合（ステップ５０６：ＹＥＳ）、アボート・ハンドラ２０４は現在のトランザクションブロックを無効化する（ステップ５１０）。これは、上述したように、non-tx-onceフラグの設定は、一度だけ実行した非トランザクションパスの実行中にJITコンパイル又はクラスロードが起きなかったことを示すためである。ステップ５０８又はステップ５１０の後、アボート・ハンドラ２０４は１を示す結果を残して処理を終了する。
　図５（ｂ）に示すフローチャートは、図５（ａ）に示すフローチャートのステップ５０４における判定がＮＯであった場合に実行される後の後半の処理の流れを示す。処理はステップ５２０で開始し、アボート・ハンドラ２０４はリトライ・カウンタの値が０より大きいか否かを判定する。リトライ・カウンタの値が０より大きい場合（ステップ５２０：ＹＥＳ）、アボート・ハンドラ２０４はリトライ・カウンタの値を１減らして（ステップ５２２）、２を示す結果を残して処理を終了する。
　一方、リトライ・カウンタの値が０以下の場合（ステップ５２２：ＮＯ）、アボート・ハンドラ２０４は現在のトランザクションブロックのアボート・カウンタを１増やす（ステップ５２４）。続いてアボート・ハンドラ２０４は、アボート・カウンタの値を実行カウンタの値で割ることにより求められるアボート率が所定の閾値より小さいか否かを判定する（ステップ５２６）。アボート率が所定の閾値より小さい場合（ステップ５２６：ＹＥＳ）、アボート・ハンドラ２０４は、１を示す結果を残して処理を終了する。一方、アボート率が所定の閾値以上である場合（ステップ５２６：ＮＯ）、アボート・ハンドラ２０４は、現在のトランザクションブロックを無効化し（ステップ５２８）、１を示す結果を残して処理を終了する。
　図６に示すフローチャートは、図３に示すフローチャートのステップ３１８の非トランザクションパス実行の処理の詳細を示す。処理はステップ６００で開始し、実行部２０８は、非トランザクションパスの実行を開始する。続いて実行部２０８は、非トランザクションパスの実行中にJITコンパイル又はクラスロードがトリガーされた場合、現在実行中のスレッドのnon-tx-executionフラグが設定されていることを条件として、非トランザクションパスの実行と同期してJITコンパイル又はクラスロードを実行し、その後現在実行中のスレッドのnon-tx-executionフラグをリセットする（ステップ６０２）。続いて実行部２０８は、非トランザクションパスの実行を終了する（ステップ６０４）。
　続いて実行部２０８は、現在実行中のスレッドのnon-tx-executionフラグが設定されているか否かを判定する（ステップ６０６）。現在実行中のスレッドのnon-tx-executionフラグが設定されていない場合（ステップ６０６：ＮＯ）、実行部２０８は処理を終了する。一方、現在実行中のスレッドのnon-tx-executionフラグが設定されている場合（ステップ６０６：ＹＥＳ）、実行部２０８は、現在のトランザクションブロックに割り当てられているnon-tx-onceフラグを設定し（ステップ６０８）、その後、現在実行中のスレッドのnon-tx-executionフラグをリセットする（ステップ６１０）。その後実行部２０８は処理を終了する。
　図７（ａ）に示すフローチャートは、実行部２０８により定期的に実行される処理である。処理はステップ７００で開始し、実行部２０８は、十分な数のクラスがロードされ、かつ、十分な数のメソッドがコンパイルされるまで待機する。続いて実行部２０８は、JITコンパイル又はクラスロードが原因で無効化された全てのトランザクションブロックを再度有効化し、対応する実行カウンタ、アボート・カウンタ、及びnon-tx-onceフラグを全てリセットする（ステップ７０２）。そして実行部２０８は処理を終了する。
　図７（ｂ）は、第１の実施形態においてA1の構成に加えてA2の構成を採用した場合に、実行部２０８によりプログラム実行開始時に新たに実行される処理の流れを示すフローチャートである。処理はステップ７１０で開始し、実行部２０８は、実行しようとするプログラムのコードに含まれる全てのトランザクションブロックを無効化する。続いて実行部２０８は、十分な数のクラスがロードされ、かつ、十分な数のメソッドがコンパイルされるまで待機する（ステップ７１２）。続いて実行部２０８は、実行しようとするプログラムのコード内の全てのトランザクションブロックを再度有効化し、対応する実行カウンタ、アボート・カウンタ、及びnon-tx-onceフラグを全てリセットする（ステップ７１４）。そして実行部２０８は処理を終了する。
　次に図３、図５～図８を参照して、第２の実施形態によるアボート削減処理の流れを説明する。但し、図８に示すフローチャートを除いた残りの図のフローチャートについては、第１の実施形態に関連して既に説明済みであるためここでは説明を省略する。図８は、図３に示すフローチャートのステップ３１２におけるアボート性ランタイムヘルパー２１９による処理の流れの他の例を示すフローチャートである。
　図８に示すフローチャートは、ステップ８００で開始し、アボート性ランタイムヘルパー２１９は、非トランザクション書き込み命令を用いて、そのランタイムヘルパーの種別を示すＩＤを現在実行中のスレッドの記憶領域に記録する。続いてアボート性ランタイムヘルパー２１９は、その本来の処理を実行する（ステップ８０２）。続いてアボート性ランタイムヘルパー２１９は、現在実行中のトランザクションがアボートしたか否かを判定する（ステップ８０４）。
　現在実行中のトランザクションがアボートした場合（ステップ８０４：ＹＥＳ）、アボート性ランタイムヘルパー２１９は何もせずに処理を終了する。一方、現在実行中のトランザクションがアボートしていない場合（ステップ８０４：ＮＯ）、アボート性ランタイムヘルパー２１９は現在実行中のスレッドの記憶領域に記録した情報をクリアして（ステップ８０６）、処理を終了する。なお、第２の実施形態においてアボート・ハンドラ２０４は、図５のフローチャートに示す処理の最初に現在実行中のスレッドの記憶領域に記録された情報を読み取るものとする。
　次に図３、図５（ｂ）、図６、図７、図９、及び図１０を参照して、第３の実施形態によるアボート削減処理の流れを説明する。但し、図９及び図１０に示すフローチャートを除いた残りの図のフローチャートについては、第１の実施形態に関連して既に説明済みであるためここでは説明を省略する。但し、第３の実施形態においては、JITコンパイルが原因でトランザクションブロックが無効化されることはないため、図７（ａ）、（ｂ）にそれぞれ示すフローチャートのステップ７００、７０２、７１２及び７１４におけるJITコンパイルについての記載は削除する必要があることに留意されたい。図９は、図３に示すフローチャートのステップ３１２におけるアボート性ランタイムヘルパー２１９による処理の流れの他の例を示すフローチャートである。図１０は、図３に示すフローチャートのステップ３１６におけるアボート・ハンドラ２０４による前半の処理の流れの他の例を示すフローチャートである。
　図９に示すフローチャートは、ステップ９００で開始し、アボート性ランタイムヘルパー２１９は、その処理内容がシンボル解決であるか否かを判定する。その処理内容がシンボル解決である場合（ステップ９００：ＹＥＳ）、アボート性ランタイムヘルパー２１９は非トランザクション書き込み命令を用いて、現在実行中のスレッドの記憶領域に、修正すべきコードのアドレスとデータとを書き込む（ステップ９０２）。
　一方、その処理内容がシンボル解決でない場合（ステップ９００：ＮＯ）、続いてアボート性ランタイムヘルパー２１９は、その処理内容がJITコンパイルであるか否かを判定する（ステップ９０４）。処理内容がJITコンパイルである場合（ステップ９０４：ＹＥＳ）、アボート性ランタイムヘルパー２１９は非トランザクション書き込み命令を用いて、現在実行中のスレッドの記憶領域に、JITコンパイルすべきメソッドのＩＤを書き込む（ステップ９０２）。ステップ９０４において処理内容がJITコンパイルでない場合（ステップ９０４：ＮＯ）、ステップ９０２、又はステップ９０６の後処理はステップ９０８へ進み、アボート性ランタイムヘルパー２１９は、そのアボート性ランタイムヘルパー２１９の種別を示すＩＤをアボートの原因を示す引数として、トランザクションアボート命令を発行する。その後アボート性ランタイムヘルパー２１９は処理を終了する。
　図１０に示すフローチャートは、ステップ１０００で開始し、アボート・ハンドラ２０４は、アボートの原因がシンボル解決であるか否かを判定する。アボートの原因がシンボル解決である場合（ステップ１０００：ＹＥＳ）、アボート・ハンドラ２０４は、現在実行中のスレッドの記憶領域に記録されたデータで、同じく記録されたコードのアドレスを修正し（ステップ１００２）、２を示す結果を残して処理を終了する。
　一方、アボートの原因がシンボル解決でない場合（ステップ１０００：ＮＯ）、続いてアボート・ハンドラ２０４は、アボートの原因がJITコンパイルであるか否かを判定する（ステップ１００４）。アボートの原因がJITコンパイルである場合（ステップ１００４：ＹＥＳ）、アボート・ハンドラ２０４は、現在実行中のスレッドの記憶領域に記録されたＩＤで識別されるメソッドをJITコンパイルし（ステップ１００）、２を示す結果を残して処理を終了する。
　一方、アボートの原因がJITコンパイルでない場合（ステップ１００４：ＮＯ）、続いてアボート・ハンドラ２０４は、アボートの原因がTLH割り付け又は非同期GCチェックであるか否かを判定する（ステップ１００８）。アボートの原因がTLH割り付け又は非同期GCチェックのいずれかである場合（ステップ１００８：ＹＥＳ）、アボート・ハンドラ２０４は１を示す結果を残して処理を終了する。
　一方、アボートの原因がTLH割り付け又は非同期GCチェックのいずれでもない場合（ステップ１００８：ＮＯ）、続いてアボート・ハンドラ２０４は、アボートの原因がクラスロードであるか否かを判定する（ステップ１０１０）。アボートの原因がクラスロードでない場合（ステップ１０１０：ＮＯ）、処理は図５（ｂ）に示すフローチャートのステップ５２０に続く。一方、アボートの原因がクラスロードである場合（ステップ１０１０：ＹＥＳ）、続いてアボート・ハンドラ２０４は、現在のトランザクションブロックについてのnon-tx-onceフラグが設定されているか否かを判定する（ステップ１０１２）。
　non-tx-onceフラグが設定されていない場合（ステップ１０１２：ＮＯ）、続いてアボート・ハンドラ２０４は現在実行されているスレッドのnon-tx-executionフラグを設定する（ステップ１０１４）。一方、non-tx-onceフラグが設定されていた場合（ステップ１０１２：ＹＥＳ）、アボート・ハンドラ２０４は現在のトランザクションブロックを無効化する（ステップ１０１６）。ステップ１０１４又はステップ１０１６の後、アボート・ハンドラ２０４は１を示す結果を残して処理を終了する。
　次に図３、図４、図５（ｂ）、図６、図７、図１１、図１２を参照して、第４の実施形態によるアボート削減処理の流れを説明する。但し、図１１及び１２に示すフローチャートを除いた残りの図のフローチャートについては、第１の実施形態に関連して既に説明済みであるためここでは説明を省略する。図１１は、JITコンパイラ２２０による処理の流れの一例を示すフローチャートである。図１２は、図３に示すフローチャートのステップ３１６におけるアボート・ハンドラ２０４による前半の処理の流れの他の例を示すフローチャートである。
　図１１に示すフローチャートは、あるメソッドが所定回数実行されJITコンパイラ２２０が呼び出されることにより開始し、JITコンパイラ２２０はコンパイル対象のコード内にトランザクションブロックがあるか否かを判定する（ステップ１１００）。コンパイル対象のコード内にトランザクションブロックがある場合（ステップ１１００：ＹＥＳ）、続いてJITコンパイラ２２０は、見つかったトランザクションブロック内に、コード修正の呼び出しがあるか否かを判定する（ステップ１１０２）。
　見つかったトランザクションブロック内にコード修正の呼び出しがある場合（ステップ１１０２：ＹＥＳ）、JITコンパイラ２２０は、見つかったコード修正の呼び出しをトランザクションアボート命令で置換し、かつ、アボート命令の命令アドレスから置換したコード修正の実行に必要な情報への対応表を作成する（ステップ１１０４）。ここでコード修正の実行に必要な情報は、実行時コード修正されるべきアドレス及びデータである。
　ステップ１１００においてコンパイル対象のコード内にトランザクションブロックがない場合（ステップ１１００：ＮＯ）、ステップ１１０２において見つかったトランザクションブロック内にコード修正の呼び出しがない場合（ステップ１１０２：ＮＯ）、又はステップ１１０４から、処理はステップ１１０６へ進み、JITコンパイラ２２０は通常のJITコンパイル処理を行い、その後処理を終了する。
　図１２に示すフローチャートは、ステップ１２００で開始し、アボート・ハンドラ２０４は、アボートの原因がシンボル解決であるか否かを判定する。該判定は、アボートが起きた命令アドレスで、JITコンパイラ２２０により作成された対応表を検索し、ヒットするか否かを判定することにより行うことができる。ヒットした場合アボートの原因がシンボル解決であると判定できる。アボートの原因がシンボル解決である場合（ステップ１２００：ＹＥＳ）、アボート・ハンドラ２０４は、アボートが起きた命令アドレスからJITコンパイラ２２０により作成された対応表を引いて必要な情報を取得し、取得した情報を用いてコード修正を実行し、更に何もしないという意味であるnop命令にアボート命令を置換する（ステップ１２０２）。その後アボート・ハンドラ２０４は、２を示す結果を残して処理を終了する。
　一方、アボートの原因がシンボル解決でない場合（ステップ１２００：ＮＯ）、続いてアボート・ハンドラ２０４は、アボートの原因がTLH割り付け又は非同期GCチェックであるか否かを判定する（ステップ１２０４）。アボートの原因がTLH割り付け又は非同期GCチェックのいずれかである場合（ステップ１２０４：ＹＥＳ）、アボート・ハンドラ２０４は１を示す結果を残して処理を終了する。
　一方、アボートの原因がTLH割り付け又は非同期GCチェックのいずれでもない場合（ステップ１２０４：ＮＯ）、続いてアボート・ハンドラ２０４は、アボートの原因がJITコンパイル又はクラスロードであるか否かを判定する（ステップ１２０６）。アボートの原因がJITコンパイル又はクラスロードのいずれでもない場合（ステップ１２０６：ＮＯ）、処理は図５（ｂ）に示すフローチャートのステップ５２０に続く。一方、アボートの原因がJITコンパイル又はクラスロードのいずれかである場合（ステップ１２０６：ＹＥＳ）、続いてアボート・ハンドラ２０４は、現在のトランザクションブロックについてのnon-tx-onceフラグが設定されているか否かを判定する（ステップ１２０８）。
　non-tx-onceフラグが設定されていない場合（ステップ１２０８：ＮＯ）、続いてアボート・ハンドラ２０４は現在実行されているスレッドのnon-tx-executionフラグを設定する（ステップ１２１０）。一方、non-tx-onceフラグが設定されていた場合（ステップ１２０８：ＹＥＳ）、アボート・ハンドラ２０４は現在のトランザクションブロックを無効化する（ステップ１２１２）。ステップ１２１０又はステップ１２１２の後、アボート・ハンドラ２０４は１を示す結果を残して処理を終了する。
　次に図３、図４、図５（ｂ）、図６、図７、図１３を参照して、第５の実施形態によるアボート削減処理の流れを説明する。但し、図１３に示すフローチャートを除いた残りの図のフローチャートについては、第１の実施形態に関連して既に説明済みであるためここでは説明を省略する。図１３は、図３に示すフローチャートのステップ３１６におけるアボート・ハンドラ２０４による前半の処理の流れの他の例を示すフローチャートである。
　図１３に示すフローチャートは、ステップ１３００で開始し、アボート・ハンドラ２０４は、アボートの原因がコード修正であるか否かを判定する。アボートの原因がコード修正である場合（ステップ１３００：ＹＥＳ）、アボート・ハンドラ２０４は、アボートが起きた命令アドレスを含むページを書き込み保護する（ステップ１３０２）。その後アボート・ハンドラ２０４は、２を示す結果を残して処理を終了する。
　一方、アボートの原因がコード修正でない場合（ステップ１３００：ＮＯ）、続いてアボート・ハンドラ２０４は、アボートの原因が書込み保護の例外であるか否かを判定する（ステップ１３０４）。アボートの原因が書込み保護の例外である場合（ステップ１３０４：ＹＥＳ）、アボート・ハンドラ２０４は、書込み保護を無効化し、書込み保護が起きた場所の書き込み命令を識別することにより実行時コード修正されるべきアドレスとデータを取得し、実行時コード修正を行う（ステップ１３０６）。その後アボート・ハンドラ２０４は、２を示す結果を残して処理を終了する。
　一方、アボートの原因が書込み保護の例外でない場合（ステップ１３０４：ＮＯ）、続いてアボート・ハンドラ２０４は、アボートの原因がTLH割り付け又は非同期GCチェックであるか否かを判定する（ステップ１３０８）。アボートの原因がTLH割り付け又は非同期GCチェックのいずれかである場合（ステップ１３０８：ＹＥＳ）、アボート・ハンドラ２０４は１を示す結果を残して処理を終了する。
　一方、アボートの原因がTLH割り付け又は非同期GCチェックのいずれでもない場合（ステップ１３０８：ＮＯ）、続いてアボート・ハンドラ２０４は、アボートの原因がJITコンパイル又はクラスロードであるか否かを判定する（ステップ１３１０）。アボートの原因がJITコンパイル又はクラスロードのいずれでもない場合（ステップ１１３１０：ＮＯ）、処理は図５（ｂ）に示すフローチャートのステップ５２０に続く。一方、アボートの原因がJITコンパイル又はクラスロードのいずれかである場合（ステップ１３１０：ＹＥＳ）、続いてアボート・ハンドラ２０４は、現在のトランザクションブロックについてのnon-tx-onceフラグが設定されているか否かを判定する（ステップ１３１２）。
　non-tx-onceフラグが設定されていない場合（ステップ１３１２：ＮＯ）、続いてアボート・ハンドラ２０４は現在実行されているスレッドのnon-tx-executionフラグを設定する。一方、non-tx-onceフラグが設定されていた場合（ステップ１３１２：ＹＥＳ）、アボート・ハンドラ２０４は現在のトランザクションブロックを無効化する（ステップ１３１６）。ステップ１３１４又はステップ１３１６の後、アボート・ハンドラ２０４は１を示す結果を残して処理を終了する。
　次に図３、図５（ｂ）、図６、図１４、図１５、図１６を参照して、第６の実施形態によるアボート削減処理の流れを説明する。但し、図１４、図１５及び１６に示すフローチャートを除いた残りの図のフローチャートについては、第１の実施形態に関連して既に説明済みであるためここでは説明を省略する。図１４は、図３に示すフローチャートのステップ３１２におけるアボート性ランタイムヘルパー２１９による処理の流れの他の例を示すフローチャートである。図１５は、図３に示すフローチャートのステップ３１６におけるアボート・ハンドラ２０４による前半の処理の流れの他の例を示すフローチャートである。図１６は、トランザクションブロックの有効化処理の流れの他の例を示すフローチャートである。
　図１４に示すフローチャートは、ステップ１４００で開始し、アボート性ランタイムヘルパー２１９は、その処理内容がJITコンパイル又はクラスロードであるか否かを判定する。その処理内容がJITコンパイル又はクラスロードのいずれかである場合（ステップ１４００：ＹＥＳ）、アボート性ランタイムヘルパー２１９は非トランザクション書き込み命令を用いて、現在実行中のスレッドの記憶領域に、JITコンパイルすべきメソッドのＩＤ又はロードすべきクラスのＩＤを書き込む（ステップ１４０２）。
　一方、その処理内容がJITコンパイル又はクラスロードのいずれでもない場合（ステップ１４００：ＮＯ）、続いてアボート性ランタイムヘルパー２１９は、そのアボート性ランタイムヘルパー２１９の種別を示すＩＤをアボートの原因を示す引数として、トランザクションアボート命令を発行する（ステップ１４０４）。その後アボート性ランタイムヘルパー２１９は処理を終了する。
　図１５に示すフローチャートは、ステップ１５００で開始し、アボート・ハンドラ２０４は、アボートの原因がTLH割り付け又は非同期GCチェックであるか否かを判定する。アボートの原因がTLH割り付け又は非同期GCチェックのいずれかである場合（ステップ１５００：ＹＥＳ）、アボート・ハンドラ２０４は１を示す結果を残して処理を終了する。一方、アボートの原因がTLH割り付け又は非同期GCチェックのいずれでもない場合（ステップ１５００：ＮＯ）、続いてアボート・ハンドラ２０４は、アボートの原因がシンボル解決であるか否かを判定する（ステップ１５０２）。アボートの原因がシンボル解決である場合（ステップ１５０２：ＮＯ）、アボート・ハンドラ２０４は直ちに現在のトランザクションブロックを無効化し（ステップ１５０４）、１を示す結果を残して処理を終了する。
　アボートの原因がシンボル解決でない場合（ステップ１５０２：ＮＯ）、続いてアボート・ハンドラ２０４は、アボートの原因がJITコンパイル又はクラスロードであるか否かを判定する（ステップ１５０６）。アボートの原因がJITコンパイル又はクラスロードのいずれでもない場合（ステップ１５０６：ＮＯ）、処理は図５（ｂ）に示すフローチャートのステップ５２０に続く。一方、アボートの原因がJITコンパイル又はクラスロードのいずれかである場合（ステップ１５０６：ＹＥＳ）、続いてアボート・ハンドラ２０４は、現在のトランザクションブロックについてのnon-tx-onceフラグが設定されているか否かを判定する（ステップ１５０８）。
　non-tx-onceフラグが設定されていない場合（ステップ１５０８：ＮＯ）、続いてアボート・ハンドラ２０４は現在実行されているスレッドのnon-tx-executionフラグを設定する（ステップ１５１０）。一方、non-tx-onceフラグが設定されていた場合（ステップ１５０８：ＹＥＳ）、アボート・ハンドラ２０４は、現在実行中のスレッドの記憶領域に記録されたメソッドＩＤ又はクラスＩＤを、グローバル・テーブルに書き込む（ステップ１５１２）。続いてアボート・ハンドラ２０４は現在のトランザクションブロックを無効化する（ステップ１５１４）。ステップ１５１０又はステップ１５１４の後、アボート・ハンドラ２０４は１を示す結果を残して処理を終了する。
　図１６に示すフローチャートは、ステップ１６００で開始し、実行部２０８は、グローバル・テーブル内の全てのメソッドと全てのクラスとが、それぞれJITコンパイル又はロードされるまで待機する。続いて実行部２０８は、JITコンパイル又はクラスロードが原因で無効化された全てのトランザクションブロックを再度有効化し、対応する実行カウンタ、アボート・カウンタ、及びnon-tx-onceフラグを全てリセットする（ステップ７０２）。そして実行部２０８は処理を終了する。
　次に図１７を参照して実験結果について説明する。図１７（ａ）は、カウンタを加算するマイクロベンチマークを用いて本発明のアボート削減方法を適用した４コアのzEC12マシンの性能を評価した結果を示す。また、図１７（ｂ）は、HTMを用いたJava(登録商標)のConcurrentHashMapを用いて本発明のアボート削減方法を適用した１６コアのzEC12マシンの性能を評価した結果を示す。いずれのグラフも横軸はスレッド数を示し、縦軸は、スループットを示す。なお、スループットは、１スレッド時の従来技術を適用した場合のスループット値を１としている。
　適用した本発明のアボート削減方法は、上述した第３の実施形態によるアボート削減方法である。また、比較した従来技術は、非特許文献１に記載される手法であり、トランザクションがアボートした場合に何度か再実行し、それでもアボートが起こる場合には非トランザクションパスを実行してから再度トランザクションを実行するという手法である。図１７（ａ）に示す実験結果では、本発明を利用しない場合はパフォーマンスが８９％低下している。図１７（ｂ）はに示す実験結果では、本発明を利用しない場合はパフォーマンスが１３％低下している。これは本発明を利用しない場合、トランザクション中でJITコンパイルと実行時コード修正が起きてトランザクションがアボートし続けるからである。
　以上、実施形態を用いて本発明の説明をしたが、本発明の技術範囲は上記実施形態に記載の範囲には限定されない。上記の実施形態に、種々の変更または改良を加えることが可能であることが当業者に明らかである。例えば、第３の実施形態では、トランザクション中に呼び出されるアボート性ランタイムヘルパー２１９がJITコンパイラ２２０やシンボル・リゾルバー２２８である場合、その実行を遅延させ、アボート・ハンドラ２０４内で実行させた。しかしながら同様の方法で実行に必要な情報を記録しておき、その後これをアボート・ハンドラ内ではなくアボート・ハンドラによる処理の後実行部２０９により実行させてもよい。従って、そのような変更または改良を加えた形態も当然に本発明の技術的範囲に含まれる。
　なお、特許請求の範囲、明細書、及び図面中において示した装置、システム、プログラム、及び方法における動作、手順、ステップ、及び段階等の各処理の実行順序は、特段「より前に」、「先立って」等と明示しておらず、また、前の処理の出力を後の処理で用いるのでない限り任意の順序で実現しうることに留意すべきである。また、前の処理の出力を後の処理で用いる場合でも、前の処理と後の処理の間に他の処理が入ることは可能である場合があること、又は間に他の処理が入るように記載されていても前の処理を後の処理の直前に行うよう変更することも可能である場合があることも留意されたい。特許請求の範囲、明細書、及び図面中の動作フローに関して、便宜上「まず、」、「次に、」、「続いて、」等を用いて説明したとしても、この順で実施することが必須であることを必ずしも意味するとは限らない。

Claims (20)

  1. 　ハードウェアトランザクショナルメモリを用いたプログラム実行においてアボートの回数を削減するためのコンピュータによる方法であって、
    （ａ）前記コンピュータが、トランザクションブロックの実行中におけるランタイムヘルパーの呼び出しに応答して、前記ランタイムヘルパーを実行するステップと、
    （ｂ）前記ランタイムヘルパーの呼び出しに起因したアボートに応答して、前記コンピュータが、アボート・ハンドラを実行するステップと、
    （ｃ）ステップ（ｂ）の前記アボート・ハンドラの実行の後、前記コンピュータが、前記トランザクションブロックに対応する非トランザクションパスを実行するステップとを含み、
    　前記ランタイムヘルパーの実行は、ランタイムヘルパーの種別を示すID情報を前記アボート・ハンドラに渡すための処理を含み、
    　前記アボート・ハンドラの実行は、アボートの原因となった前記ランタイムヘルパーの前記ID情報を取得し、特定の種別のランタイムヘルパーに対して前記トランザクションブロックを無効化する処理を含む、
    アボート削減方法。
  2. 　前記特定の種別のランタイムヘルパーに対して前記トランザクションブロックを無効化する処理は、非トランザクションパスにおいても実行不可能な第１の種別のランタイムヘルパーに対し無条件で前記トランザクションブロックを無効化する処理と、非トランザクションパスにおいては実行可能な第２の種別のランタイムヘルパーに対し、一度の前記非トランザクションパスを実行中に前記第２の種別のランタイムヘルパーが呼び出されないことを条件として前記トランザクションブロックを無効化する処理とを含む、請求項１に記載のアボート削減方法。
  3. 　前記第１の種別のランタイムヘルパーは、実行時コード修正を含み、前記第２の種別のランタイムヘルパーは、実行時コンパイルとクラスロードとを含む、請求項２に記載のアボート削減方法。
  4. 　（ｄ）条件付きで前記トランザクションブロックが無効化された場合において、前記コンピュータが、プログラムが定常状態に達したことに応答して前記トランザクションブロックを再有効化するステップを更に含む、請求項３に記載のアボート削減方法。
  5. 　前記ランタイムヘルパーの実行は、前記ランタイムヘルパーが前記第２の種別のランタイムヘルパーである場合に、その処理内容を、非トランザクション書き込み命令を用いて記録し、及び、前記ID情報を引数としてトランザクションアボート命令を発行する処理を含み、前記アボート・ハンドラの実行は、前記第２の種別のランタイムヘルパーに対して前記トランザクションブロックを無効化する場合に、前記記録した処理内容を表に登録し、及び、（ｅ）前記コンピュータが、前記表に登録された処理内容が実行されたことに応答して、前記トランザクションブロックを再有効化するステップを更に含む、請求項３に記載のアボート削減方法。
  6. 　前記第２の種別のランタイムヘルパーが実行時コンパイルである場合、前記処理内容は、コンパイルすべきメソッドの識別情報であり、前記第２の種別のランタイムヘルパーがクラスロードである場合、前記処理内容は、ロードすべきクラスの識別子である請求項５に記載のアボート削減方法。
  7. 　前記アボート・ハンドラは、スレッドローカルヒープ割付と、非同期ガーベジコレクションチェックとを、前記特定の種別以外のランタイムヘルパーとして判断する、請求項３に記載のアボート削減方法。
  8. 　（ｆ）前記コンピュータが、プログラムの実行開始において全てのトランザクションブロックを無効化するステップと、（ｇ）前記コンピュータが、前記プログラムの実行開始から所定の期間が経過することに応答して、前記全てのトランザクションブロックを有効化するステップとを更に含む、請求項１に記載のアボート削減方法。
  9. 　前記ランタイムヘルパーの実行は、トランザクションアボート命令を発行する処理を含み、前記ID情報をアボート・ハンドラに渡すための処理は、前記ID情報を前記トランザクションアボート命令の引数とする処理を含む、請求項１に記載のアボート削減方法。
  10. 　前記ID情報をアボート・ハンドラに渡すための処理は、非トランザクション書き込み命令を用いて前記ID情報を記録する処理を含み、該処理の後前記ランタイムヘルパーは本来のランタイムヘルパーの処理を行う、請求項１に記載のアボート削減方法。
  11. 　前記ランタイムヘルパーの実行は、該ランタイムヘルパーが前記特定の種別と異なる他の種別のランタイムヘルパーであることを条件に、その実行に必要な情報を、非トランザクション書き込み命令を用いて記録する処理を含み、前記アボート・ハンドラの実行は、前記他の種別のランタイムヘルパーに対し、記録された前記必要な情報を用いてその実行を行う処理を含み、及び、該処理の後ステップ（ｃ）の代わりに、（ｈ）前記コンピュータが、前記トランザクションブロックを再実行するステップを含む、請求項１に記載のアボート削減方法。
  12. 　前記ランタイムヘルパーの実行は、該ランタイムヘルパーが前記特定の種別と異なる他の種別のランタイムヘルパーであることを条件に、その実行に必要な情報を、非トランザクション書き込み命令を用いて記録する処理と、その実行をキャンセルする処理とを含み、（ｉ）前記コンピュータが、前記トランザクションブロックを実行後、前記他の種別のランタイムヘルパーに対し、記録された前記必要な情報を用いてその実行処理を行うステップを更に含む、請求項１に記載のアボート削減方法。
  13. 　前記特定の種別のランタイムヘルパーはクラスロードを含み、前記他の種別のランタイムヘルパーは、実行時コンパイルであり、前記実行に必要な情報はコンパイルすべきメソッドの識別情報である、請求項１１又は１２に記載のアボート削減方法。
  14. 　前記特定の種別のランタイムヘルパーはクラスロードを含み、前記他の種別のランタイムヘルパーは、実行時コード修正であり、前記実行に必要な情報は実行時コード修正されるべきアドレス及びデータである、請求項１１又は１２に記載のアボート削減方法。
  15. 　前記ランタイムヘルパーが実行時コンパイルである場合に、前記ランタイムヘルパーの実行は、コンパイル対象のコードに含まれるトランザクションブロック内の実行時コード修正の呼び出しを、トランザクションアボート命令で置換し、該トランザクションアボート命令のアドレスから前記実行時コード修正に必要な情報への対応表を作成する処理を含み、（ｊ）前記コンピュータが、置換された前記トランザクションアボート命令の実行に応答してアボート・ハンドラを実行した後に、前記トランザクションブロックを再実行するステップを更に含み、前記アボート・ハンドラの実行は、前記トランザクションアボート命令のアドレスから前記対応表を引いて必要な情報を取得することにより前記実行時コード修正を行い、前記トランザクションアボート命令をｎｏｐ命令で上書きする処理を含む、請求項１に記載のアボート削減方法。
  16. 　前記アボート・ハンドラの実行は、前記ランタイムヘルパーが実行時コード修正であることを条件に、アボートが起きた命令アドレスを含むページを書き込み禁止にし、及び、アボートの原因が書込み保護の例外であることを条件に、前記書込み禁止を無効化し、書込み保護が起きた位置の書き込み命令を識別することにより実行時コード修正されるべきアドレスとデータを取得して、前記実行時コード修正を行い、（ｋ）前記コンピュータが、前記アボート・ハンドラによる書き込み禁止処理又は前記実行時コード修正の後ステップ（ｃ）の代わりに、前記トランザクションブロックを再実行するステップを更に含む、請求項１に記載のアボート削減方法。
  17. 　コンピュータに、請求項１乃至１６のいずれかに一項に記載のアボート削減方法の各ステップを実行させるためのアボート削減プログラム。
  18. 　請求項１乃至１６のいずれかに一項に記載のアボート削減方法の各ステップを実行するように適合された手段を備える、アボート削減装置。
  19. 　ハードウェアトランザクショナルメモリを用いたプログラム実行においてアボートの回数を削減するための装置であって、
    　実行部と、
    複数のランタイムヘルパーと、
    アボート・ハンドラとを含み、
    　　前記ランタイムヘルパーの各々は、前記実行部によるトランザクションブロックの実行中に呼び出されることに応答して、ランタイムヘルパーの種別を示すID情報を前記アボート・ハンドラに渡すための処理を行い、
    　　前記アボート・ハンドラは、アボートの原因となった前記ランタイムヘルパーの前記ID情報を取得し、特定の種別のランタイムヘルパーに対して前記トランザクションブロックを無効化する処理を行い、及び、
    　　前記実行部は、前記ランタイムヘルパーの呼び出しに起因した前記アボート・ハンドラの処理の後に、前記トランザクションブロックに対応する非トランザクションパスを実行する、アボート削減装置。
  20. 　前記特定の種別のランタイムヘルパーに対して前記トランザクションブロックを無効化する処理は、非トランザクションパスにおいても実行不可能な第１の種別のランタイムヘルパーに対し無条件で前　記トランザクションブロックを無効化する処理と、非トランザクションパスにおいては実行可能な第２の種別のランタイムヘルパーに対し、一度の前記非トランザクションパスを実行中に前記第２の種別のランタイムヘルパーが呼び出されないことを条件として前記トランザクションブロックを無効する処理とを含み、前記実行部は、条件付きで前記トランザクションブロックが無効化された場合に、プログラムが定常状態に達したことに応答して前記トランザクションブロックを再有効化する、請求項１９に記載のアボート削減装置。
PCT/JP2014/051051 2013-02-22 2014-01-21 アボート削減方法、アボート削減装置、及びアボート削減プログラム WO2014129247A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2015501363A JP5901835B2 (ja) 2013-02-22 2014-01-21 アボート削減方法、アボート削減装置、及びアボート削減プログラム
US14/769,739 US9501314B2 (en) 2013-02-22 2014-01-21 Reducing aborts caused by a runtime helper called during execution of a transaction block

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2013-033433 2013-02-22
JP2013033433 2013-02-22

Publications (1)

Publication Number Publication Date
WO2014129247A1 true WO2014129247A1 (ja) 2014-08-28

Family

ID=51391044

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/051051 WO2014129247A1 (ja) 2013-02-22 2014-01-21 アボート削減方法、アボート削減装置、及びアボート削減プログラム

Country Status (3)

Country Link
US (1) US9501314B2 (ja)
JP (1) JP5901835B2 (ja)
WO (1) WO2014129247A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019120464A1 (en) * 2017-12-18 2019-06-27 Huawei Technologies Co., Ltd. Scalable hardware transactional memory

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010121218A (ja) 2001-12-04 2010-06-03 Nippon Steel Corp 金属酸化物及び／又は金属水酸化物被覆金属材料の製造方法
WO2011081704A2 (en) * 2009-12-15 2011-07-07 Intel Corporation Handling operating system (os) transitions in an unbounded transactional memory (utm) mode

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8706982B2 (en) * 2007-12-30 2014-04-22 Intel Corporation Mechanisms for strong atomicity in a transactional memory system
US7966459B2 (en) 2007-12-31 2011-06-21 Oracle America, Inc. System and method for supporting phased transactional memory modes
US8776063B2 (en) 2008-11-26 2014-07-08 Oracle America, Inc. Method and system for hardware feedback in transactional memory
CN101788922B (zh) * 2009-01-22 2013-12-25 国际商业机器公司 基于辅助线程实现事务存储系统的方法和装置
US8489864B2 (en) 2009-06-26 2013-07-16 Microsoft Corporation Performing escape actions in transactions
US8301849B2 (en) * 2009-12-23 2012-10-30 Intel Corporation Transactional memory in out-of-order processors with XABORT having immediate argument
US9626187B2 (en) * 2010-05-27 2017-04-18 International Business Machines Corporation Transactional memory system supporting unbroken suspended execution
KR101203131B1 (ko) 2010-07-26 2012-11-20 (주)지오메디칼 다공성 콘택트렌즈 제조방법 및 그 제조방법에 의하여 제조된 다공성 콘택트렌즈
US8424015B2 (en) * 2010-09-30 2013-04-16 International Business Machines Corporation Transactional memory preemption mechanism
US9436477B2 (en) * 2012-06-15 2016-09-06 International Business Machines Corporation Transaction abort instruction
US20150278123A1 (en) * 2014-03-28 2015-10-01 Alex Nayshtut Low-overhead detection of unauthorized memory modification using transactional memory

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010121218A (ja) 2001-12-04 2010-06-03 Nippon Steel Corp 金属酸化物及び／又は金属水酸化物被覆金属材料の製造方法
WO2011081704A2 (en) * 2009-12-15 2011-07-07 Intel Corporation Handling operating system (os) transitions in an unbounded transactional memory (utm) mode

Also Published As

Publication number Publication date
US20160004557A1 (en) 2016-01-07
US9501314B2 (en) 2016-11-22
JP5901835B2 (ja) 2016-04-13
JPWO2014129247A1 (ja) 2017-02-02

Similar Documents

Publication Publication Date Title
US9626187B2 (en) Transactional memory system supporting unbroken suspended execution
US8544022B2 (en) Transactional memory preemption mechanism
JP5592015B2 (ja) ハードウェア制限に基づく調整可能なトランザクション・サイズを利用してコードを動的に最適化する装置、方法およびシステム
US8402224B2 (en) Thread-shared software code caches
US8990786B2 (en) Program optimizing apparatus, program optimizing method, and program optimizing article of manufacture
JP5460430B2 (ja) 動的コンパイラプログラム、動的コンパイル方法及び動的コンパイル装置
TWI812750B (zh) 交易式比較及丟棄指令
TWI786181B (zh) 在例外遮罩更新指令之後允許未中止的交易處理
JP2011134202A (ja) メモリ管理装置、メモリ管理方法、及びメモリ管理プログラム
CN107003897B (zh) 监控事务处理资源的利用率
US8296742B2 (en) Automatic native generation
US10346196B2 (en) Techniques for enhancing progress for hardware transactional memory
CN101425052B (zh) 一种事务性内存的实现方法
JP5901835B2 (ja) アボート削減方法、アボート削減装置、及びアボート削減プログラム
Zhou et al. Efficient atomic durability on eADR-enabled persistent memory
EP2176761B1 (en) Object model for transactional memory
JP2007249736A (ja) 言語処理実行方法およびその計算機システム
Yang et al. Lightweight monitors for the Java virtual machine
Nowack et al. Parallelize the Runtime Checks–Not the Application
JP2015090647A (ja) ハードウェア割り込みを用いるサンプリング・プロファイラの精度改善方法、システム、及びプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14754188

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015501363

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14769739

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14754188

Country of ref document: EP

Kind code of ref document: A1