DE112009005006T5 - Optimizations for an Unbound Transactional Storage System (UTM) - Google Patents

Abstract

A method and apparatus for optimizing an unbounded transactional memory (UTM) system are described herein. Hardware support for monitors, buffers, and metadata is provided wherein metadata orthogonal metaphysical address spaces can be separately connected to threads and / or software subsystems within threads. In addition, the metadata may be held by hardware in a compressed manner with respect to software transparent data. In addition, in response to a metadata access instruction / operations, the hardware is able to support a forced metadata value to enable multiple modes of transactional execution. However, if monitors, buffered data, metadata or other information is lost or conflicts are detected, the hardware provides for variations of a loss instruction capable of polling a transaction history register for such loss or conflict and execution in response to a flag to capture the capture of the loss or conflict. Similarly, several variations of a commit instruction are provided to enable software to define commit conditions and commit deletion information. In addition, the hardware provides support to allow suspension and resumption of transactions at ring level transitions.

Description

TERRITORY

This invention relates to the field of processor execution, and more particularly to the execution of instruction sets.

BACKGROUND

Advances in semiconductor processing and logic design have allowed for an increase in the amount of logic that may be present on integrated circuit devices. As a result, computer system configurations have been developed from a single or multiple integrated circuits in a system to multiple cores and multiple logical processors resident on individual integrated circuits. A processor or integrated circuit typically includes a single-processor chip, wherein the processor chip may include any number of cores or logical processors.

The ever increasing number of cores and logic processors on integrated circuits allows multiple software threads to be executed concurrently. However, the increase in the number of software threads that can run concurrently has resulted in problems in synchronizing data shared between the software threads. One conventional approach to sharing shared data in multi-core or multiple-logic processor systems involves the use of latches to guarantee mutual exclusion via multiple accesses to shared data. However, the ever-increasing ability to execute multiple software threads potentially results in a fake contention and serialization of execution.

For example, consider a hash table that contains shared data together. With a locking system, a programmer can lock the entire hash table, allowing a thread access to the entire hash table. However, the throughput and performance of other threads are potentially adversely affected because they can not access entries in the hash table until the lock is resolved. Alternatively, each entry in the hash table can be locked. After extrapolating this simple example to a large scalable program, it is obvious that for both types, the complexity of a lock conflict situation, serialization, fine synchronization and deadlock avoidance will be extremely cumbersome for programmers.

Another recent data synchronization technique involves the use of transactional memory (TM). Often, transactional execution involves execution of a grouping of a plurality of micro-operations, operations, or instructions. In the above example, both threads execute in the hash table and their memory accesses are monitored / tracked. If both threads access the same entry / modify the same entry, a conflict resolution can be performed to ensure data validity. One type of transactional execution includes Software Transactional Memory (STM), where memory access, conflict resolution, task abends, and other transactional task tracking are often performed without software hardware support.

Another type of transactional execution includes a hardware transactional memory (HTM) system that includes hardware to support access tracking, conflict resolution, and other transactional tasks. Previously, actual memory data arrays have been augmented with additional bits to hold information, such as hardware attributes for tracking reads, writes, and buffering, and thus data is moved with the data from the processor to memory. Often this information is called permanent, i. H. it is not lost on cache flush as the information moves through the memory hierarchy with the data. However, this durability imposes an additional overhead on the memory hierarchy system.

In addition, previous hardware transactional memory (HTM) systems were burdened with a number of inefficiencies. As a first example, HTMs currently do not provide an efficient way to transition between unbuffered or buffered and unmonitored states to a buffered and monitored state to ensure consistency before committing a transaction. As another example, there are numerous inefficiencies of the interface of an HTM with software. In particular, the Hardware does not provide a mechanism to properly accelerate software memory access barriers that are aware of different forms of strong and weak atomicity between transactional and non-transactional operations. In addition, during an attempted commit of a transaction, hardware provides no means of determining when to abort or commit a transaction based on a loss of monitoring, buffering, and / or other attribute information. Similarly, the instruction set for these prior HTMs does not provide for commit instructions that define information to be held or deleted when a transaction commits. Other exemplary efficiencies include: HTMs do not provide instructions for efficient vector or jump execution in detecting a conflict or loss of information, and the inability of current HTMs to handle Ringlevel priority transitions during transaction execution.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limited by the figures of the accompanying drawings.

1 Figure 1 illustrates one embodiment of a processor that includes multiple processing elements that are capable of executing multiple software threads concurrently;

2 illustrates an embodiment for mapping metadata for a data item;

3 Figure 12 illustrates one embodiment of multiple orthogonal metaphysical address spaces for separate software subsystems in a plurality of processing elements;

4 Figure 1 illustrates one embodiment of compression of metadata to data;

5 Figure 12 illustrates an embodiment of a flowchart for a metadata access method;

6 Fig. 12 illustrates an embodiment of a metadata storage element to aid in accelerating transients in high and low atomicity environments;

7 Fig. 12 illustrates an embodiment of a flowchart for accelerating non-transactional operations while maintaining the atomicity in a transactional environment;

8th FIG. 12 illustrates an embodiment of a flowchart for a method of efficiently transferring a block of data to a buffered and monitored state prior to committing a transaction; FIG.

9 FIG. 12 illustrates an embodiment of hardware for assisting a loss instruction to hop to a target based on a status value in a transaction status register; FIG.

10 Fig. 11 illustrates an embodiment of a flowchart for a method of executing a loss instruction to hop to a target based on a conflict or loss of specific information;

11 Figure 4 illustrates one embodiment of hardware supporting a definition of commit conditions and clear controls in a commit instruction;

12 Figure 12 illustrates an embodiment of a flowchart for a method of executing a commit instruction that defines commit conditions and clear controls;

13 Figure 1 illustrates one embodiment of hardware for supporting handling privilege level transitions during the execution of transactions.

DETAILED DESCRIPTION

In the following description, numerous specific details, such as specific hardware structures for transactional execution, specific types and implementations of access monitors, specific types of cache coherency models for detecting access conflicts, are specific Data granularities and specific types of memory accesses and locations, etc. set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that these specific details need not be employed to practice the present invention. Other examples have included well-known components or methods such as encoding transactions in software, inserting operations to perform enumerated functions by a compiler, delineating transactions, specific and alternative multi-core and multi-threaded processor architectures, specific compiler methods. Implementations and specific operating details of microprocessors are not described in detail to avoid unnecessary concealment of the present invention.

The methods and apparatus described herein are for optimizing hardware and software for Unbounded Transactional Memory (UTM) execution (Transactional Unlimited Memory Execution). In particular, the optimizations are explained primarily with reference to a support of a UTM system. However, the methods and apparatus described herein may be used in any form of a transactional memory system, such as in hardware to support or speed up software transactional memory (STM) systems, pure hardware transactional memory (HTM) systems, or a hybrid thereof that differs in implementation from a UTM system.

With reference to 1 shows an embodiment of a processor that is suitable for the simultaneous execution of multiple threads. Note that the processor 100 may include hardware support for hardware transactional execution. Either in connection with a hardware-transactional execution or separately, the processor can 100 Also, hardware support for software transactional memory (STM) hardware acceleration, a separate execution of an STM, or a combination thereof, such as providing a hybrid Transactional Memory (TM) system. The processor 100 includes any processor, such as a microprocessor, an embedded processor, a digital signal processor (DSP), a network processor or other device for executing code. The processor 100 As shown, it includes a plurality of processing elements.

In one embodiment, a processing element relates to a thread unit, a process unit, a context, a logical processor, a hardware thread, a core, and / or any other element capable of holding a state for a processor, such as an execution state or an architectural state. In other words, a processing element according to one embodiment relates to any hardware capable of being independently associated with code, such as a software thread, operating system, application, or other code.

A physical processor typically refers to an integrated circuit that potentially includes any number of other processing elements, such as cores or hardware threads.

One core often refers to logic residing on an integrated circuit capable of maintaining an independent architectural state, each independently maintained architectural state being associated with at least some dedicated execution resources. Unlike cores, a hardware thread typically refers to any logic residing on an integrated circuit that is capable of maintaining an independent architectural state, with independently maintained architectural states sharing access to execution resources. As can be seen, there is an overlap between the nomenclature of a hardware thread and a kernel when certain resources are shared and others are dedicated to an architectural state. Often, a kernel and a hardware thread are seen by an operating system as individual logical processors, with the operating system being able to individually plan operations on each logical processor.

A logical processor 100 as he is in 1 includes two cores, a core 101 and a core 102 that provide access to a higher-level cache 110 share together. Although the processor 100 asymmetric cores, ie cores of different configurations, functional units and / or logic, symmetric cores are shown. Consequently, the core becomes 102 , which is identical to the core 101 is illustrated, not explained in detail, to avoid repetition of the explanation. In addition, the core includes 101 two hardware threads 101 and 101b while the core 102 two hardware threads 102 and 102b includes. Therefore, software entities, such as an operating system, the processor 100 potentially as four separate processors, ie four logical processors or processing elements capable of executing four software threads simultaneously.

Here's a first thread with architectural state registers 101 , a second thread with architectural state registers 101b , a third thread with architectural state registers 102 and a fourth thread with architectural state registers 102b connected. As shown, the architectural state registers 101 in architectural state registers 101b replicates, allowing individual architectural states / contexts for the logical processor 101 and the logical processor 101b can be stored. Other minor resources, such as instruction pointers and renaming logic in the Rename Allocator logic 130 can also do the threads 101 and 101b be replicated. Some resources, such as reorder buffers in the reorganization / retention unit 135 , ILTB 120 , Load / store buffers and queues can be shared by partitioning. Other resources, such as general purpose internal registers, page table base registers, low level data cache, and data TLBs 115 , Execution unit (s) 140 and parts of an out-of-order unit 135 are potentially shared completely in common.

The processor 100 often includes other resources that may be fully shared, in particular divided by partitioning or dedicated by / for processing elements. in 1 FIG. 3 illustrates one embodiment of a purely exemplary processor with illustrative functional units / resources of a processor. It should be understood, however, that a processor may include any of these functional units and may include or may be omitted any other known functional entity, logic, or firmware not shown.

As shown, the processor includes 100 a bus interface module 105 to communicate with devices external to the processor, such as a storage system 175 , a chipset, northbridge or other integrated circuit. The memory 175 can for the processor 100 be dedicated or can be shared with other devices in a system. A cache 110 higher level or further-out cache 110 is meant to retrieve recently retrieved items from a cache 110 cache higher level. Note that a higher level or further-out cache refers to levels that increase or decrease further from the execution unit (s). In one embodiment, the cache is 110 higher level around a second level data cache. However, the cache is 110 higher level is not limited in this way, since it may include or be associated with an instruction cache. A trace cache, ie a type of instruction cache, may instead be after the decoder 125 be connected to save recently decoded traces. The module 120 also potentially includes a branch target buffer to predict branches to be executed or taken, and an instruction translation buffer (I-DLB) to store address translation entries for instructions.

The decoding module 125 is with the polling unit 120 coupled to decode retrieved elements. In one embodiment, the processor is 100 associated with an instruction set architecture (ISA) that defines / specifies instructions on the processor 100 are executable. Here, machine code instructions that are recognized by the ISA often include a portion of the instruction referred to as an op code that relates to / specifies an instruction or operation to be executed.

In one example, the allocator and renamer block includes 130 an allocator for reserving resources, such as register files for storing results of an instruction processing. However, the threads are 101 and 101b potentially suitable for out-of-order execution, with the allocator and renamer block 130 also reserves other resources, such as reorder buffers for tracking instruction results. The unit 130 may also include a register renamer to program / instruction reference registers into other internal registers of the processor 100 rename. The reorder / retirement unit 135 includes components such as the aforementioned reorder buffers, load buffers, and memory buffers to support out-of-order execution and, subsequently, in-order retirement of instructions executed out-of-order.

The scheduler and execution unit (s) block 140 In one embodiment, a scheduler unit for scheduling instructions / operations on execution units. For example, a floating point instruction is scheduled on a port of an execution unit that includes an available floating point execution unit. Register files associated with the execution units are also included to store information instruction processing results. Exemplary execution units include a floating point execution unit, an integer execution unit, a Jump execution unit, a load execution unit, a memory execution unit and other known execution units.

A low-level data cache and a data translation buffer (D-TLB) 150 are with an execution unit (execution units) 140 coupled. The data cache is adapted to store recently used elements or elements on which operations have been performed, such as data operands potentially held in memory coherency states. The D-TLB is adapted to store recent address translations from virtual linear to physical. As a specific example, a processor may include a page table structure to divide a physical memory into a plurality of virtual pages.

In one embodiment, the processor is 100 for hardware transaction execution, software transaction execution, or a combination or hybrid thereof. A transaction, which may also be referred to as a critical or atomic code section, comprises a grouping of instructions, operations, or micro-operations to be executed as an atomic group. For example, instructions or operations may be used to unmask a transaction or critical section. In one embodiment, which will be described in further detail below, these instructions are part of a set of instructions, such as an instruction set architecture (ISA), which may be hardware of a processor 100 , such as the decoders described above, are recognizable. Often these instructions, once compiled from a high level language into a hardware recognizable assembler language, include opcodes or other portions of the instructions that decoders detect during a decode stage.

Typically, during execution of a transaction, updates to the memory are not made globally visible until the transaction is committed. As an example, a transactional write to a location for a local thread is potentially visible, however, the write data is not forwarded in response to a read from another thread until the transaction comprising the transactional write is committed. While the transaction is still pending, data points / items loaded from memory and written to memory are tracked, as will be explained in more detail below. Once the transaction reaches a commit point, the transaction is committed and updates made during the transaction are made generally visible if no conflicts are detected for the transaction.

However, if the transaction is invalidated during the suspend state, the transaction is aborted and potentially restarted without making the updates globally visible. Thus, the limbo of a transaction as used herein refers to a transaction that has begun execution and has not been committed or aborted, i. H. is floating.

A software transaction memory (STM) system often involves performing access tracking, conflict resolution or other transaction storage tasks in software or at least partially in software. In one embodiment, the processor is 108 adapted to execute a compiler to compile a program code to support transactional execution. Here, the compiler can insert operations, calls, functions, and other code to allow execution of transactions.

A compiler often includes a program or set of programs to translate source code into destination text / code. Typically, compilation of a program of application code with a compiler is performed in multiple phases and passes to transform a high level programming language code into a low level machine or assembly language code. However, single pass compilers still know how to be used for easy compilation. A compiler may use any known compilation technique and may perform any compiler operation, such as lexical analysis, preprocessing, parsing, semantic analysis, code generation, code transformation, and code optimization.

Larger compilers often include multiple phases, but these phases are mostly comprised of two general phases: (1) a front-end, ie where syntactic processing, semantic processing and some transformations / optimizations can generally take place and (2) Back-end, where generally analysis, transformations, optimizations, and code generation take place. Some compilers refer to a middle-end that demonstrates blurring the boundary between a front-end and a back-end of a compiler. As a result, a reference insertion, association, creation, or other operation of a compiler in each of the aforementioned phases or in each of the aforementioned passes, as well as in any other known phase or in any other known passage of a compiler. As an illustrative example, a compiler inserts potentially transactional operations, calls, functions, etc. into one or more phases of compilation, such as insertion of calls / operations in a front-end phase of compilation, and then transformation of the calls / operations in a low-level code during a transactional memory transformation phase.

Nevertheless, despite the execution environment and the dynamic and static nature of a compiler, in accordance with one embodiment, the compiler compiles program code to enable transactional execution. Therefore, reference to the execution of a program code according to an embodiment (1) relates to the execution of a compiler program (either compiler programs) either dynamically or statically to compile main program code, maintain transactional structures, or perform other transaction related operations (2) Execution of a main program code including transactional operations / calls, (3) execution of other program code, such as libraries associated with the main program code, or (4) a combination thereof.

Often, in software transactional memory (STM) systems, a compiler is used to insert some operations, calls and other codes inline with application code to be compiled, while other operations, calls, functions and code are provided separately in libraries , This potentially offers library distributors the ability to optimize and update the libraries without recompiling the application code. As a specific example, a call to a commit function may be inserted inline in application code at a commit point of a transaction, while the commit function is provided separately in an updateable library. In addition, the choice of where to place special operations and calls potentially affects the efficiency of the application code. For example, if a filtering operation described in greater detail with reference to access barriers with reference to 6 is inserted inline with code, the filtering operation may be performed before a vector-guided execution to a barrier instead of inefficient vectoring to the barrier and then performing the filtering operation.

In one embodiment, the processor is 100 adapted to perform transactions using hardware / logic, ie in a hardware transactional memory (HTM) system. Many specific implementation details exist from an architectural as well as a microarchitectural perspective when implementing an HTM; however, most of them are not discussed herein to avoid unnecessarily obscuring the invention. However, for purposes of illustration, a few structures and implementations are disclosed. However, it should be understood that these structures and implementations are not required and may be extended and / or replaced by other structures having different implementation details.

As a combination, the processor 100 be configured to perform transactions in an unbound transactional storage (UTM) system attempting to take advantage of the benefits of both the STM and HTM systems. For example, an HTM is often fast and efficient for running small transactions because it does not rely on software to perform all access tracking, conflict detection, validation, and commit transactions. However, HTMs are usually only able to handle smaller transactions, while STMs are capable of handling unrestricted size transactions. Thus, in one embodiment, a UTM system uses hardware to perform smaller transactions and software to perform transactions that are too large for the hardware. As will be seen from the discussion below, hardware, even when handling software transactions, can be used to support and accelerate the software. In addition, it should be noted that the same hardware can also be used to support and accelerate a pure STM system.

As discussed above, transactions include transactional memory accesses to data elements by both local processing elements within a processor 100 as well as potentially by other processing elements. Without security mechanisms in a transactional storage system, some of these accesses would potentially result in invalid data and invalid execution, ie, writing to data invalidating a read, or reading invalid data. Consequently, a processor includes 100 potentially logic to memory accesses to and from data elements for identification of to track or monitor potential conflicts, such as reading monitors and writing monitors, as explained below.

A data unit or data item may include data at any level of granularity, as defined by hardware, software, or a combination thereof. A non-exhaustive list of examples of data, data elements, data units, or references thereto, includes a memory address, a data object, a class, a dynamic language code type field, a dynamic language code type, a variable, an operand, a data structure, and an indirect one Reference to a memory address. However, any known grouping of data may be referred to as a data item or unit of data. Some of the above examples, such as a dynamic language code type field and a dynamic language code type, relate to dynamic language code data structures. By way of illustration, dynamic language code, such as Java ^™ from Sun Microsystems, Inc., is a strongly typed language. Each variable has a type known at compile time. The types are divided into two categories - primitive types (Boolean and numeric, such as int, float) and reference types (Classes, Interfaces, and Arrays). The values of reference types are references to objects. In Java, an object consisting of fields can be a class instance or an array. Assuming an object a of a class A, the notation A :: x is usually used to refer to the field x of a type A, and ax to refer to the field x of an object a of a class A. For example, an expression can be expressed as ax = ay + az. In this case, the field y and the field z are loaded for addition and the result is written in the field x.

Therefore, monitoring / buffering memory accesses to data elements may be performed at any data level granularity. For example, in one embodiment, memory accesses to data at a type level are monitored. In this case, a transactional write to a field A :: x and a non-transactional loading of a field A :: y can be monitored as accesses to the same data element, i. H. Type A. In another embodiment, memory access monitoring / buffering is performed on a field level granularity. In this case, a transactional write in A :: x and a non-transactional load of A :: y are not monitored as accesses to the same data item because they are references to separate fields. Note that other data structures or programming techniques may be considered when tracking memory accesses to data items. For example, suppose that the fields x and y of the object of class A, d. H. A :: x and A :: y point to class B objects, initialize to newly assigned objects, and never write to them after initialization. In one embodiment, a transactional write to a field B :: z of an object pointed to by A :: x is considered to be a non-transactional loading of a field B :: z of an object pointed to by A :: y , not monitored as memory access to the same data item. By extrapolating these examples, it can be seen that monitors can perform monitoring / buffering at any level of data granularity.

In one embodiment, the processor includes 100 Monitor to capture or track accesses and potential subsequent conflicts associated with those data elements. As an example, hardware includes a processor 100 Read monitors and write monitors to track loading and saving, which should be monitored accordingly. For example, despite the granularity of underlying storage structures, hardware monitor and write monitors should monitor data items at granularity of the data items. In one embodiment, a data element is constrained by tracking mechanisms associated with the granularity of the memory structures to ensure that at least the entire data element is properly monitored.

As a specific illustrative example, read and write monitors include attributes associated with cache locations, such as locations in a data cache 150 lower level to monitor load from and store to addresses associated with these locations. This becomes a read attribute for a cache location of a data cache 150 on a read event, set to an address associated with the cache location to be monitored for potentially conflicting writing to the same address. In this case, attributes operate in a similar manner for write events to monitor potentially conflicting reading and writing at the same address. To continue this example, hardware is able to detect read / write conflicts based on read and write snoops to cache locations with read and write attributes that are set to indicate that the cache locations are monitored appropriately. Conversely, setting read and write monitors or updating a cache location to a buffered state in accordance with one embodiment results in snoops such as Read requests or read-for-ownership requests that allow conflicts with addresses monitored in other caches to be captured.

Therefore, based on the design, various combinations of cache coherency requests and monitored cache line coherency states lead to potential conflicts, such as a cache line holding a data item in a common read-monitored state and a snoop holding a write request to the data element. Conversely, a cache line holding a data item that is in a buffered write state and an external snoop that is indicating a read request to the data item may be considered potentially conflicting. According to one embodiment, snoop logic is connected to conflict detection / reporting logic such as monitors and / or conflict detection / reporting logic, as well as status registers to report the conflicts, to detect such combinations of access requests and attribute states.

However, any combination of conditions and scenarios may be considered invalidating for a transaction, which may be defined by an instruction such as a commit instruction. This will be described in more detail below with reference to FIG 11 - 12 explained. Examples of factors that may be considered non-commit to a transaction include detecting a conflict in a transactionally accessed memory location, a loss of monitor information, a loss of buffered data, a loss of metadata associated with a transactionally accessed data item and detecting another invalidating event, such as an interrupt, a ring transition, or an explicit user instruction.

According to one embodiment, hardware is the processor 100 intended to keep transactional updates in a buffered manner. As discussed above, transactional writes are not made globally visible until a transaction is committed. However, a local software thread associated with the transactional write is able to access the transactional updates for subsequent transactional accesses. As a first example, a separate buffer structure will be in the processor 100 provided to hold the buffered updates that is set up to deliver the updates to the local thread and not to other external threads. However, including a separate buffer structure is potentially expensive and complex.

In contrast, as another example, a cache memory such as a data cache is used 150 used to buffer the updates while providing the same transactional functionality. Here is the cache 150 being able to hold data items in a buffered coherence state; in one case, a new buffered coherency state is added to a cache coherency protocol, such as a Modified Exclusive Shared Invalid (MESI) protocol, to form a MESIB protocol. In response to local requests for a buffered data item - a data item held in a buffered coherency state, the cache provides 150 the data item to the local processing element to ensure internal transactional sequential request. However, in response to external access requests, an error response is provided to ensure that the transactionally updated data item is not made globally visible until committed. Additionally, the buffered update is not restored to higher-level cache stores when one line of a cache 150 is kept in a buffered coherency state and has been selected for eviction - the buffered update should not be propagated through the storage system, ie, should not be made globally visible until after a commit. At commit the buffered. Transfer lines to a modified state to make the data element globally visible.

Note that the expressions internally and externally are often relative from the perspective of a thread associated with the execution of a transaction or processing elements that share a cache. For example, a first processing element for executing a software thread associated with the execution of a transaction is referred to as a local thread. Therefore, in the above discussion, if storing or loading is received from an address previously written by the first thread, resulting in a cache line for the address held in a buffered coherency state, the first thread is received supplied the buffered version of the cache line because it is the local thread. In contrast, a second thread may execute on a different processing element in the same processor, but is not associated with any execution of the transaction responsible for the cache line being held in the buffered state - an external thread; therefore, loading or saving from the second thread at the address misses the buffered version of the cache line and a normal cache replacement is used to fetch the non-buffered version of the cache line from higher-level memory.

Herein, the internal / local and external / remote threads are executed on the same processor and, in some embodiments, may also be executed on separate processing elements in the same core of a processor that share access to the cache in common. However, the use of these terms is not limited in this way. As discussed above, a local thread may refer to multiple threads that share access to a cache in common, we need not be specific to a single thread associated with running the transaction, while externally or remotely may refer to threads that do not share access to the cache.

As above in the first reference to 1 has been explained is the architecture of the processor 100 for illustrative purposes only. Similarly, the specific examples of translating data addresses to refer to metadata are also exemplary, as any method of mapping data to metadata in separate entries of the same memory can be used.

Metaphysical address spaces for metadata

metadata

In reference to 2 An embodiment of holding metadata for a data item in a processor is illustrated. As shown, metadata 217 for a data element 216 locally in a store 215 held. Metadata includes any property or attribute associated with a data item 216 connected, such as transactional information, which is a data element 216 affect. Some illustrative examples of metadata are included below; However, the disclosed examples of metadata are merely illustrative and do not form an exhaustive list. Additionally, a metadata location 217 any combination of the examples discussed below and other attributes for a data item 216 that are not specifically explained.

As a first example, metadata includes 217 a reference to a backup or buffer location for a transactionally written data item 216 if within a transaction on the data item 216 previously accessed, buffered, and / or backed up. Herein, in some implementations, becomes a backup copy of an earlier version of a data item 216 held in a different location, and as a result, the metadata includes 217 an address or other reference to the backup location.

Alternatively, metadata 217 even as a backup or buffer location for a data item 216 Act.

As another example, metadata includes 217 a filter value to repeat transactional accesses to a data item 216 to accelerate. Often, during transaction execution using software in transactional memory accesses, access barriers are executed to ensure consistency and data validity. For example, before a transactional load operation, a read barrier is executed to perform read barrier operations, such as testing whether a data item 216 is unlocked, determining whether a current read record of the transaction is still valid, updating a filter value, and logging version values in the read set set for the transaction to allow for later validation. However, if a read of this location was already performed during the execution of the transaction, the same read barrier operations are potentially not necessary.

Thus, one approach involves using a read filter to hold a first default value to indicate that the data item 216 or the address for this was not read during execution of the transaction, and to hold a second accessed value to indicate that the data item 216 or the address has already been accessed during a suspend state of the transaction. In essence, the second value accessed indicates that the reading career should be speeded up. In this case, if a transactional load operation is obtained and the read filter value at the metadata point 217 indicates that the data item 216 In one embodiment, the read barrier is ignored - not executed - to expedite transactional execution by not performing unnecessary redundant read barrier operations. Note that a write filter value may operate in the same way with respect to write operations. However, individual filter values are purely illustrative because in one embodiment a single filter value is used to indicate whether an address has already been accessed - either read or written. Here metadata access operations use metadata 217 For 216 both for shop as also check for save the single filter value, which is in contrast to the above examples, for which metadata 217 include a separate read filter value and write filter value. As a specific illustrative embodiment, four bits of metadata 217 a read filter to indicate whether to accelerate a read barrier for an associated data item, a write filter to indicate whether a write barrier is to be accelerated with respect to an associated data item, an undo filter to indicate whether undo operations are to be expedited, and assigned to a blending filter that can be used in any manner by software as a filter value.

A few other examples of metadata include an indication of a representation or reference to an address for a handler that is either generic or specific to a transaction associated with a data item, an irrevocable / willful nature of having a data item 216 associated transaction, a loss of a data item 216 , a loss of monitoring information for a data item 216 , one for a data element 216 detected conflict, an address of a read sentence or read entry in a read record associated with a data item, a prerecorded version for a data item 216 , a current version of a data element 216 , a lock on access to a data item 216 to allow a version value for the data item 216 , a transaction descriptor for the data element 216 associated transaction and other descriptive information associated with a transaction. Moreover, as described above, use of metadata is not limited to transactional information. Ms a logical consequence may be metadata 217 Also include information, properties, attributes or states that are associated with the data element 216 who are not involved in a transaction.

Continuing to explain metadata representations, the hardware monitors and buffered coherency states described above are also considered metadata in some embodiments. The monitors indicate whether a location is to be monitored for external read requests or external read-for-ownership (read-for-ownership) requests, while the buffered coherency state indicates whether an associated data cache line, which holds a data item is buffered. However, in the examples given above, monitors are maintained as attribute bits appended to cache lines or otherwise directly connected to cache lines while the buffered coherency state is added to cache line coherency state bits becomes. Thus, in this case, hardware monitors and buffered coherency states are part of the cache line structure that is not kept in a separate metaphysical address space, such as the illustrated metadata 217 , However, in other embodiments, monitors may be metadata 217 at one of the data element 216 be kept separate storage location and can similarly metadata 217 include a reference to indicate that the data item 216 is a buffered data item. Conversely, in place of an update-in-place architecture (locally updated architecture), a data element can be used 216 is updated and maintained in a buffered state as described above, metadata 217 hold the buffered data item while the globally visible version of the data item 216 maintained in its original location. Herein, at a commit, replaces the buffered update that is in the metadata 217 is held, the data element 216 ,

Lossy metadata

Similar to the discussion above with reference to buffered cache coherency states are metadata 217 in one embodiment, lossy-local information that is not delivered to the domain of external requests outside of the store. Assuming that for one embodiment of this memory 215 is a shared cache, a miss is not delivered to the domain outside of the cache in response to a metadata access operation. In essence, there is no reason to relay the miss externally to service the requests from a higher level store, as lossy metadata 217 are only held locally in the cache domain and do not persist as persistent data throughout the storage subsystem. Consequently, misses on lossy metadata are potentially treated in a rapid and efficient manner; an immediate allocation of memory in the processor can be allocated without waiting for a generation or handling of an external request for the metadata.

Metaphysical address space

As the illustrated embodiment shows, metadata becomes 217 at one of the data element 216 separated memory location - a different address - resulting in a separate metaphysical address space for metadata. Because the metaphysical address space is orthogonal to the Data address space, a metadata access operation on the metaphysical address space does not affect or modify a physical data entry. However, in one embodiment, metadata is held in the same memory, such as memory 215 , the metaphysical address space potentially destroys the data address space by competing for allocation in memory 215 , As an example, a data element 216 in an entry of a memory 215 cached while metadata 217 for the data 216 be kept in another entry of the cache. Here is a subsequent metadata operation to select the location of the data item 216 for depletion and replacement with metadata for another piece of data. As a result, meet with the address of the metadata 217 connected operations are not the data item 216 , However, a metadata address for a metadata item may include physical data, such as the data item 216 In the storage room 215 replace.

Although in this example metadata is potentially in competition with data for a cache-space, the ability to maintain metadata locally potentially results in efficient support for high-cost metadata to propagate long-lived metadata across a memory hierarchy. As can be seen from the assumption of this example, these metadata will be in the same memory, ie in memory 215 , held. However, in an alternative embodiment, metadata becomes 217 for the data element 216 or associated metadata held in a separate memory structure. Herein, addresses for metadata and for data may be the same, while a metaphysical portion of the metadata address indexes into a separate metadata storage structure instead of the data storage structure.

At a 1: 1 ratio of metadata to data, the metaphysical address space shadows the data address space, but remains orthogonal, as discussed above. In contrast, as discussed below, metadata related to physical data may be compressed. In this case, the size of a metaphysical address space for metadata does not shade the data address space in size, yet remains orthogonal.

Metaphysical address translation

Continuing to explain metaphysical address spaces, any method of translating a data address, such as an address for a data item, may be used 216 in a data address space, in a metaphysical address, such as a metadata metadata address 217 in a metaphysical address space. According to one embodiment, a metaphysical translation logic 210 used to get an address, such as a data address 200 translate into a metadata address. As shown, includes an address 200 an address associated with a data element 216 connected or referred to. A normal data translation, such as a translation between physical or linear and virtual addresses, can be used to construct a data element 216 In the storage room 215 to index. Additionally includes a compound of metadata 217 with the data element 216 a similar translation of an address 200 pointing to the data element 216 refers to another different address based on metadata 217 refers; therefore, a translation results in an address 200 in a data address with a data translation logic 205 and a different metaphysical address with a metaphysical translation 210 to separate accesses without mutual interference - thus creating the orthogonal nature of the two address spaces. As will be explained in more detail below, the use of a data translation is based 205 or a metaphysical translation 210 in one embodiment, on the type of operation for accessing data 200 A normal data access operation to access a data item 216 access uses a data translation 205 while performing a metadata access operation on metadata 217 to access, a metaphysical translation 210 which may be identified by a portion of an instruction / operation code (op code).

In another embodiment, an instruction identified by its op code may potentially access both data and metadata for a given metadata address, thus performing complex operations, such as conditional storage to data based on metadata. For example, an instruction is encoded into a test and set metadata operation to test and set metadata and an additional operation to set data to a value if the metadata test was successful. As another example, a data item may be moved from a data store to the appropriate metadata address based on a data read operation.

Examples of a translation of the data address 200 into a metadata address for metadata 217 are given immediately below. As a first example, translating a data address into a metadata address using a physical address or a virtual address - after a normal data translation 205 - plus adding a metaphysical value with a metaphysical translation logic 210 to separate data addresses from metadata addresses. In the situation where a virtual address without a translation is used, the metaphysical translation logic is included 210 a logic to combine the virtual address with a metaphysical value. However, in the case where a normal translation of an address from virtual to physical is used, a normal data translation becomes 205 used to get a translated address from the address 200 and then includes the metaphysical translation logic 210 a logic to combine the translated address with a metaphysical value to form a metadata address. As another example, the data address 200 using separate translation structures, tables, and / or logic in the metaphysical translation 210 translated to get a different metadata address. Here can be a metaphysical translation logic 210 mirror a logic or comprise a separate logic - logic to the address 200 with a metaphysical value compared to the data translation logic 205 , but includes the metaphysical translation logic 210 a table information to the address 200 to translate into another, different metadata address. It will be appreciated that either by adding information to, information added by an extension, a replacement of information therein or a translation of a data address to obtain a metadata address, the resulting different metadata address with the data element by the addition, extension , Substitution, or translation algorithm while remaining orthogonal against improper updating or reading of the data element.

A few specific illustrative examples of a translation of a data address into a metadata address, or in other words a determination of a metadata address from / based on a data address, are described below. (1) translating a first address to a second address using a normal virtual-to-physical address translation and adding, appending, or including a metaphysical value to or in the data address to form the metadata address; (2) non-performing address translation from virtual to physical to the data address and adding, appending, or incorporating a metaphysical value to or into the data address to form the metadata address; (3) translating a data address into a translated metadata address using metaphysical translation table logic, which may also include a metaphysical value, and does not necessarily require incorporation, addition, append or insertion of a metaphysical value to or into the translated metadata address in order to obtain the metadata address Metadata address form. In addition, any of the aforementioned translation techniques may include a compression ratio of data to metadata to separately store metadata for each compression ratio, i. H. based on it.

Here, an address for translation and / or compression may be modified, such as by neglecting specific bits of an address, removing specific bits of an address, changing the bit areas used at an address for a selection of different granularities of data, translating specific bits and adding or replacing specific bits with information related to metadata. The compression will be described in more detail below with reference to FIG 4 explained.

Multiple metaphysical address spaces

With reference to 3 An embodiment for supporting multiple metaphysical address spaces is illustrated. In one embodiment, each processing element is connected to a metaphysical address space so that each processing element is able to maintain independent metadata. Four processing elements 301 - 304 are shown. As explained above, a processing element may be any of the elements described above with reference to 1 include. As a first example, processing elements include cores of a processor. However, as an illustrative example, to promote the explanation below, processing elements become 301 - 304 discussed with reference to hardware threads (threads) in a processor. Each hardware thread is intended to execute a software thread and potentially multiple software subsystems.

Therefore, it is potentially beneficial to allow individual threads of the threads 301 - 304 Keep separate metadata. In one embodiment, the metaphysical translation logic is 310 intended to access different threads 301 - 304 their appropriate metaphysical address spaces. As an example, a thread identifier (ID) indexes in conjunction with an address is being referenced by a metadata access operation, into the correct metaphysical address space.

For illustrative purposes, suppose that a metadata access operation was performed with the thread 302 is connected and on address data 300 for the data element 316 refers, is received. Any translation method, as described above, may be used to designate the data address for the data element 316 translate into a metadata address. However, the translation additionally includes a combination with a thread ID 312 For example, from a control register for the thread 302 or an opcode of the received instruction from the thread 302 can be obtained. The combination may be appending the thread ID 302 to the address, a replacement of bits in the address, or any other known method of associating a thread ID with an address. The result is the metaphysical translation logic 310 capable of doing so from the metaphysical address space associated with the data element 316 connected to the processing element 302 to select / index into this.

The example suggests that by using the thread ID for the threads 301 - 304 as part of the translation into a metaphysical address of each processing element 301 - 304 is capable of independent metadata for the data element 316 maintain. However, a programmer does not have to manage the metaphysical address spaces individually because the hardware is able to keep them separate by using a thread ID in a software transparent manner. In addition, the metaphysical address spaces are orthogonal-one metadata access from one thread does not access metadata from another thread because each metadata access is associated with a separate set of addresses that includes a reference to a unique thread ID.

However, with respect to instructions / operations to access metadata, there may be certain situations in which metadata access from one thread is granted access to metadata of another thread. In other words, in some implementations, access via PEIDs and / or MDIDs (as discussed below) may be beneficial. For example, to determine if hardware has detected conflicts to examine monitor metadata from another thread, to determine whether an associated data item is being monitored by another thread, to delete metadata from other threads, or to determine commit conditions One thread needs to check for metadata of other threads that match the data item 316 are linked, modified or deleted.

Herein, a specific opcode for the operations to access metadata of another thread is recognized, and as a result, the metaphysical translation logic results 310 the translation of the address 300 in all metadata addresses for the metadata to be accessed. As a specific illustrative example in which four bits are sent to the address 300 where each bit is one of the processing elements 301 - 304 and a metadata access operation, such as a delete operation, all metadata for the data item 316 and then a metaphysical translation logic 310 Each of the four bits sets to all metadata 317 access. This can be the lookup logic for the memory 315 be constructed so that a single access, with all four bits set, on all metadata 317 accesses or the metaphysical translation logic 310 can generate four separate accesses with a different thread ID bit of the four set bits to all metadata 317 access. As an illustrative example, a mask may be applied to an address value to allow one thread to encounter metadata of another thread.

In addition, each processing element 301 - 304 as shown, may be connected to multiple metaphysical address spaces to interleave multiple contexts or software subsystems in a single thread with multiple metadata address spaces. For example, in some situations, it is potentially advantageous to allow multiple software subsystems in a single processing element to hold independent sets of metadata. Thus, in one example, orthogonal metadata address spaces may be provided at multiple processing element levels, such as core level, hardware thread level, and / software subsystem level. In the illustration, each processing element is 301 - 304 associated with two metaphysical address spaces, each of the two metaphysical address spaces to be connected to software subsystems to execute on one of the processing elements.

A software subsystem includes any task or code to be executed on a processing element that can use a separate metaphysical address space. As an illustrative example, four subsystems that may be associated with individual metaphysical address spaces include a transactional runtime subsystem, a garbage collection runtime subsystem, a memory protection subsystem and a software translation subsystem that can be executed on a single processing element. Herein, each software subsystem may have control of the processing element at different times. As another example, a software subsystem includes individual transactions executed in a single processing element. In fact, for nested transactions running on the same thread, it may be desirable to be connected to separate metaphysical address spaces. By way of illustration, if a filter test fails to access a data item in an outer transaction, it is still potentially advantageous to provide a second, different filter for accessing the same data item in an inner nested transaction that may succeed separately Accelerate access within the inner transaction. Moreover, to ensure that the metadata for the outer transaction is maintained when a nested inner transaction aborts, each nested transaction - subsystem - is associated with a different metadata space so that deleting the metadata of the inner nested transaction does not compromise the metadata of the outer Transaction impaired. However, a software subsystem is not limited in this way, as any task or code may be able to manage metadata.

In one embodiment, to ensure orthogonal metaphysical address spaces at the software subsystem level, the address is combined with the ID of the processing element (PEIPD), as discussed above, and additionally with a metadata ID (MDID) or context ID. Therefore, separate metadata can be uniquely identified for a subsystem in a processing element. Using an example from above, assume that the processing elements 301 - 304 Hardware threads are and that thread 302 executes an outer transaction and an inner transaction that is nested within the outer transaction. For the outer transaction, the metadata 317c with the data element 316 through a metaphysical translation 310 connected to the address data 300 of the data element 316 translated into an address including a thread ID (TID) and a metadata ID (MDID) for the outer transaction, which is based on the metadata 317c points.

As a purely illustrative example, metadata includes 317c four filter values - read filter value, write filter value, undo filter value and a mixed filter value, a pointer to another reference to a backup location for the data element 316 , a monitor value to indicate whether monitors are on the data item 316 lost, a transaction descriptor value, and a version of the data item 316 , Similar is the inner transaction with the metadata 317d for the data element 316 connected, the same metadata fields as those in the metadata 317c , includes. As above, the metaphysical translation translates 310 the data address 300 for the data element 316 to an address associated with the thread ID and metadata ID for the inner transaction to which the metadata 317d refer.

Here, the only difference between the metadata address, which is on the metadata 317c and the metadata address pointing to the metadata 317d Refers to be the metadata ID for the outer transaction and the inner transaction. However, this difference in address ensures that the address spaces are unconnected / orthogonal - accessing metadata from the inner transaction does not affect metadata from the outer transaction, since the MDID will be different from the outer transaction for accessing the inner transaction , As noted above, this may be beneficial for rolling back nested transactions or holding different metadata values for transactions of different levels. In particular, if the inner transaction is aborted, the backup data for the data item 316 that in the metadata 317 be kept, deleted or used to the data item 316 to an entry point in front of the inner transaction without deleting or affecting the backup data for the outer transaction contained in the metadata 317c be kept spinning back.

Note that the Metadata ID (MDID) to separate metaphysical address spaces from software subsystems can be any size and can come from a variety of sources. As a highly simplified illustrative example with four processing elements (PEs) 301 - 304 For example, a PEID may comprise a combination of two bits - 00, 01, 10, 11. Similarly, if four separate metaphysical address spaces are supported, a two-bit MDID - 00, 01, 10, 11 - will similarly be able to distinguish between four subsystems. By way of illustration, a value for representing the processing element comprises 302 and a subsystem 2 in the PE 302 0101 (where the first two bits 01 are for PE 302 and the two second bits are 01 for the second subsystem). In this example, metaphysical translation logic combines this value with the data address 300 or a translation of it to PE 302 MDID 01, which is the metadata location 317d is included.

However, both thread IDs and MDIDs can be more complex. For example, suppose that the threads 301 - 302 an access to the memory 315 share together while the threads 303 - 304 There are remote processing elements that access the memory 315 do not share. Additionally, suppose that the threads 301 - 302 two software subsystems each for a total of four orthogonal address spaces for the threads 301 - 302 support - PE 301 MD0, PE 301 MD1, PE 302 MD0 and PE 302 MD1 address spaces. In this case, a value for the combined thread ID and MDID used to obtain the metadata address may come from an opcode, a control register, or a combination thereof. By way of illustration, an opcode provides a bit for context / MDID, a control register provides a bit for an ID of a processing element (PEID) - assuming only two processing elements, and a metadata control register, such as MDCR 320 , provides four bits to identify a specific software subsystem / context for greater granularity. Thus, if a metadata access operation is performed on the address 300 for the data element 316 refers, front second thread is received - PE 302 , then the one bit of the opcode - the first bit including a 1 to indicate a second context and a second bit of a control register for the processing element 302 The second bit includes a 1 to the processing element 302 to display with an MDID from the metadata control register (MDCR) 320 combined, which is connected to the second thread; the MDCR previously updated by the MDID of the current subsystem controlling the second thread - 0010 - to identify the proper subsystem associated with the received operation. The metaphysical translation logic takes the combined value, such as 110010, and further combines it with the referenced data address 300 or a translation thereof to obtain a metadata address. However, the metadata address portion 110010 is unique to the subsystem from which the address operation originated, so that it only contains the metadata address 317d In the storage room 315 meets or modifies without the metadata addresses 317a , b, c, e, f, g, h - the orthogonal metaphysical address spaces for other subsystems, both in the second and other threads.

Tabelle A. Beispielhafte Ausführungsform von Bits für MDCR As a particular illustrative example, a discussion of a specific form of MDCR is included. In some embodiments, an ISA may be extended with a per-thread metadata identifier register (MDID register) that populates an MDID with MDID-sensitive metadata load / store / test / set instructions. In some embodiments, it is convenient to have a plurality of such registers. For example, MDCR: metadata control register is a 32-bit read-write register containing the current metadata context ID (MDID). It can be updated by a CR MOV. Exemplary bit field definitions are as follows:

Table A. Exemplary embodiment of bits for MDCR

MDID 0 and MDID 1 are the metadata IDs that can be accessed simultaneously by the instruction set. The number of bits actually used from these fields is MDID_SIZE, which in one embodiment is merely read at a privilege level specified by the processor design. However, in other embodiments, privilege levels of different levels may be able to modify the size. It is conceivable that then there are no hardware checks that will ensure that the MDID fits into the bit size allocation. In one embodiment, MDID 0 and MDID 1 are arranged to be written and read at each privilege level. It is also possible to use special MDID values to designate special metadata spaces that are always read as 0 or 1.

This may be used by software in a similar manner as the explanation of a register with reference to 6 and 7 to force a metadata value to force all metadata tests in a block to be true or false.

However, in another example, discussed above, is a metaphysical translation logic 310 in conjunction with decoders (not shown) configured to execute metadata access operations from the thread 302 to detect metadata from the metadata address space of the thread 301 to access and allow access for these specific instructions / operations to the metadata of the thread 301 to read or modify.

Compress metadata to data

Above, a one-to-one mapping of data to metadata - uncompressed metadata - was discussed. However, under some circumstances, it is more efficient to use a lower amount of metadata compared to data-a compression of metadata, where the size of the metadata is less than that of the data. Note that the metaphysical address translation logic 210 and 310 on the 2 - 3 compression may be considered when performing translation and modification of an address to refer to compressed metadata. With reference to below 4 For example, an embodiment for modifying an address to obtain compression of metadata is illustrated. In particular, an embodiment of a compression ratio of 8 for data in metadata is shown. A control logic, such as metaphysical address translation logic 210 and 310 out 2 - 3 is intended to be a data address 400 receive, which is referenced by a metadata access operation. An example includes compression, shifting or removing a number of log ₂ (N) bits in or out of an address 400 where N is the compression ratio of data to metadata. In the example shown, for a compression ratio of 8, three bits for the metadata address 405 moved down and removed. In essence, the address 400 that includes 64 bits to refer to a specific data byte in memory, truncated to three bits, to the metadata byte address 405 which is used to refer to metadata in memory on a byte granularity. From this, one bit of metadata is selected using the three bits previously removed from the address to form the metadata byte address. The shifted / removed bits are replaced by other bits according to one embodiment. As has been shown, the higher order bits are replaced by zeros after the address 400 was moved. However, the removed / shifted bits may be replaced by other data or information, such as a processing element ID, context identifier (ID), and / or metadata ID (MDID) associated with the metadata access operation. Although in this example the least significant bits are removed, each position can be bit-removed and based on any number of factors, such as cache organization, cache scheduling, metadata-to-data locality, and conflict minimization removed and replaced between data and metadata.

For example, a data address could not be shifted by log ₂ (N), but address bits 0: 2 could be set to 0. As a result, bits of the physical address and the virtual address that are the same are not shifted as in the example shown above, thereby preselecting a group and a bank of unmodified bits, such as bits 11: 3. is possible.

Note that the discussion of translation can be combined with compression. In other words, a compression ratio may be an input to the metaphysical address translation logic 210 and 310 out 2 - 3 and the translation logic uses the compression ratio in conjunction with a PEID, CD, MDID, metaphysical value, or other information to translate a data address into a metadata address. The metadata address is then used to access memory that holds the metadata. As explained above, since the metadata is a local construct - lossy, failures to memory are handled quickly and efficiently based on the metadata addresses - assignment of a storage location without generating an external failure handling request and without waiting for them handling external request. Here, an entry is assigned in the normal way for the metadata. For example, an entry such as an entry 217 out 2 selected, assigned and to the metadata default value based on a metadata address 405 and a cache replacement algorithm, such as a least-recently-used (LRU) algorithm. As a result, the metadata potentially contends for space with regular data, but remains compressed and separated from other software subsystems / processing elements.

Note that a compression ratio of eight has been given purely illustrative and any compression ratio can be used. As another example, a compression ratio of 512: 1 is used - one bit of metadata corresponds to 64 bytes of data. Similar to the above, a data address is translated / modified to be shifted by shifting the data address by log ₂ (512). Bits - 9 bits down to form a metadata address. Here, bits 6: 8 are still used instead of bits 0: 2 to select a bit, effectively producing the compression by selection at a granularity of 512 bits. Since the data address has been shifted by 9 bits, the higher order part of the data address has nine open bit positions to obtain information. In one embodiment, the 9 bits are provided to obtain identifiers, such as a context ID, thread ID, and / or MDID. In addition, values of the metaphysical space can also be kept in these bits, or the address can be extended by the metaphysical value.

In one embodiment, multiple concurrent compression ratios are supported by hardware. Herein, a representation of a compression ratio as part of a metaphysical value combined with a data address is held to obtain a metadata address. As a result, during a search of a memory with the data address, the compression ratio is taken into account and does not match with addresses of different compression ratios. In addition, the software may be capable of relying on hardware so as not to send memory information to charges of a different compression ratio.

In one embodiment, hardware is implemented using a single compression ratio, but includes different hardware support to expose software to multiple compression ratios. As an example, assume that a cache hardware is implemented using a compression ratio of 8: 1, as in FIG 4 is shown. However, a metadata access operation to access metadata at different granularities is decoded so that it includes a micro-operation to read a default amount of metadata and a test micro-operation to an appropriate part to test the metadata reading. As an example, the default amount of read metadata comprises 32 bits. However, another 8: 1 granularity / compression test operation tests the correct bits of the 32 bits of the read metadata that are based on a particular number of bits of an address, such as a number of LSBs of a metadata address and / or context ID can.

As an illustration, in a scheme supporting metadata for unaligned data for one bit of metadata per byte of data, a single bit is selected from the least significant eight bits of the 32 read bits of metadata based on the three LSBs of a metadata address. For a data word, two consecutive metadata bits are selected from the least significant 16 bits of the 32 bits of read metadata based on the three LSBs of the address, and this continues for up to 16 bits for a metadata size of 128 bits.

Metadata access instructions / operations

The following is with reference to 5 a flow chart for a method for accessing metadata associated with data shown. Although the rivers are off 5 are shown in a substantially serial fashion, the flows may be performed at least partially in parallel, as well as potentially in a different order.

At the river 505 There is a metadata operation that references a data address for a given data element. In the above discussion, it has been mentioned that hardware metadata instructions / operations may be assisted to read, modify, and / or delete metadata. In other words, instructions in an instruction set architecture (ISA) of a processor may be supported so that processor decoders recognize opcodes of instructions to access data and logic to perform the accesses accordingly. Note that the use of an instruction can also refer to an operation. Some processors use the idea of a macro instruction that is capable of being decoded into a plurality of micro-operations to perform individual tasks, such as a test and set metadata macro instruction, which is used in a metadata test Operation / micro-operation is decoded to test the metadata and, if the correct Boolean value is obtained as a result of the test operation, a set operation updates the metadata to a specific value.

However, the metadata access operations are not limited to explicit software instructions for accessing metadata, but may also include implicit micro-operations that are decoded as part of a larger, more complex instruction that includes access to a data item that includes Metadata is connected. Here, the data access instruction may be decoded into a plurality of operations such as access to the data item and an implicit update of the associated metadata.

As previously discussed, in one embodiment, the physical mapping of metadata to data in hardware is not directly visible to software. As a result, in this example metadata access operations point to data addresses and rely on the hardware to perform the correct translations, i. H. Mapping to properly access the metadata. However, metadata access operations may individually refer to separate metaphysical address spaces, depending on which thread, context, and / or software subsystem they originate from. Therefore, a memory may hold metadata for data items in a software transparent manner. If the hardware detects either an explicit operation code (opcode of an instruction) or by decoding an instruction into a metadata access micro-operations) an access operation on metadata, the hardware performs the required translation of the data address pointed to by the Access operation was referenced to access the metadata accordingly.

As this example illustrates, a program may include separate operations, such as a data access operation or a metadata access operation, that reference the same address of a data item, such as data items 216 and 316 out 2 - 3 and the hardware can map these accesses to other address spaces, such as physical address space and metaphysical address space. In some embodiments, the ISA may be extended by metadata load / store / test / set instructions for a given virtual address, MDID, compression ratio, and operant width. Any of these parameters may be explicit instruction operands, may be coded in opcode, or may be obtained from a separate control register. Instructions may combine the metadata load / store operation with other operations, such as loading some data, testing a few bits thereof, and setting a conditional branch condition code. Instructions can also empty all metadata or just metadata for a particular MDID. A number of illustrative metadata access operations are listed below. Note that some of the example instructions are related to specific 64X compression ratio instructions, but similar instructions for other compression ratios as well as uncompressed metadata may be used, even if not specific. were revealed.

Metadata Bit Test and Set (MDLT)

The metadata load and test instruction (MDLT) has two arguments: the data address to which the metadata is associated as a source operand and a register (destination operand) into which the byte, word, dword, qword or another size of metadata that contains the bit is written. The value of the tested metadata bit is written to the register. The programmer should not assume any knowledge of the data stored in the destination register of the MDLT instruction and should not manipulate that register. This register is to be used solely as a source operand for a Metadata Store and Set Instruction (MDSS) to the same address. In one embodiment, the MDLT instruction will combine the test and set operations, but will suppress the set operation if the test is successful.

Metadata Store and Set (MSS)

The Metadata Store and Set Instruction (MDSS) has two arguments: the metadata address to which the metadata is associated and a register (source operand) from which the byte, word, dWord, qWord, or any other size of Metadata containing the bit should be stored for storage. The MDSS instruction will set the correct bit in value out of its source operand.

Metadata Storage and Reset Instruction (MDSR)

The MDSR instruction has two source arguments: the data address to which the metadata is associated, as a source operand, and a register (source operand) that makes up the byte, word, dWord, qWord, or any other size of metadata contain the bit to reset. The MDSR instruction will reset the correct bit in value from its source operand.

A metadata address is determined from the referenced data address. Examples of a metadata address determination are in the metaphysical address translation sections above contain the multiple metaphysical address spaces. However, it should be noted that the translation may include, ie, be based on, a compression ratio of data to metadata to separately store metadata for each compression ratio.

Test Metadata (CMDT)

Tabelle B: Erläuternde Ausführungsform einer Test-Metadaten-Operation

Table B: Illustrative Embodiment of a Test Metadata Operation

The CMDT instruction is to convert the memory data address to a memory metadata address having a compressed mapping function that is implementation-dependent and to test whether a metadata bit corresponding to the memory metadata address is set. As an example, the compression ratio CR is one bit for eight bytes. The metadata address calculation includes one of the MDCR register context IDs to ensure uniquely setting MD for each individual context ID, addressing MDBLK [CR] [MDCR.MDID [MDID number]]. META. The instruction aligns the address "mem" with the specified data size, thus enhancing alignment. The instruction tests if metadata is set.

The following is an exemplary pseudo code related to CDMT (The IF flag is set to represent a zero metadata value, all other flags are cleared):

Memory for compressed metadata (CMDS)

Tabelle C: Erläuternde Ausführungsform einer Metadaten-Speicher-Operation

Table C: Illustrative Embodiment of a Metadata Store Operation

The CMDS instruction converts the memory data address into a memory metadata address with a compressed mapping function that is implementation-dependent. The compression ratio is one bit for 8 bytes of data. The coding of the imm8 value is as follows: 0 → MD_Value; Save value in MD and 7: 1 → Reserved; Not Used Below is an exemplary pseudo-code associated with CMDS.

Delete Compressed Metadata (CMDCLR)

Tabelle D: Erläuternde Ausführungsform der Lösche-Metadaten-Operation

Table D: Illustrative Embodiment of the Delete Metadata Operation

The CMDCLR instruction sets all MDBLK [CR] [MDCR.MDID [MDID number]]. META will match any data in the range that spans MBLK (mem). An exemplary pseudo code related to CMDCLR is inserted below:

Next is in the river 510 determines a metadata address from the data address referenced in the metadata access operation based on a compression ratio, processing element ID, context ID, MDID, metaphysical value, operator size and / or another metaphysical address space translation related Value. Any of the methods described above, such as a combination of ID values without a data address translation, a normal data address translation, or a separate metaphysical address translation of the data address, may be used to obtain the appropriate metadata address.

Additionally, in some examples, as discussed above, a version of the test, set, clear, or other instructions is provided to allow a thread or metadata context to test, set, or test metadata of other threads or metadata contexts to delete. As a result, the translation into a metadata address may include a modification of the address, such as an application of a mask to allow access from a thread or context ID to access another thread or context ID.

In the river 515 the metadata referenced by the metadata address is accessed. Normally, the separate location for the metadata associated with the local requesting thread or context ID is accessed and the appropriate operations, such as Test, Set, and Clear, are performed. However, in the second case described above, metadata for other threads or context IDs in that flow may also be accessed.

abstractions

One embodiment of abstractions for software is included herein. A given CR is a power of two that indicates how many bits of data map to one bit of metadata. The implementation defines which CRs values, if any, can be used. CR> 1 refers to compressed metadata. CR = 1 denotes uncompressed metadata.

MDBLK [CR] [*] s are ceil (CR / 8) bytes in size and are naturally aligned. MDBLKs are connected to physical data rather than their linear virtual addresses. All valid physical addresses A with the same value floor (A / MDBLK [CR] [*] _ SIZE) denote the same sets of MDBLKs.

For a given CR, there can be any number of different MDIDs, each designating a unique metadata instance. The metadata for a given CR and MDID is different from the metadata for any other CR or MDID. For example, for Thd # 0, assuming that addr is QWORD aligned, the metadata block referred to by MDBLK [CR = 64] [MDID = 3] (addr) is the same as MDBLK [CR = 64] [MDID = 3] (addr + 7), but is certainly different from MDBLK [CR = 64] [MDID = 4] (addr) and from MDBLK [CR = 512] [MDID = 3] (addr).

A given implementation may support multiple matching contexts, with the number of contexts depending on the CR and certain configuration information associated with the specific system whose parts are the processor. For uncompressed metadata, there is a QWORD of metadata for each QWORD of physical data.

Metadata are interpreted exclusively by software. Software may set, reset, or test META for a particular MDBLK [CR] [MDID], or reset META for all MDBLK [*] [*] s of the thread, or reset META for all MDBLKs [CR] [MDID] of the thread can cross a given MBLK (addr).

Metadata loss. Any META property of the thread can spontaneously reset to 0, creating a metadata loss event.

Forced metadata value

With reference to 6 An embodiment for providing hardware support for a forced metadata value is illustrated. STMs usually ensure consistency between memory access operations using access barriers. For example, prior to a memory access to a data item, a metadata location or an interlock location associated with the data item is checked to determine if the data item is available. Other potential barrier operations include obtaining a lock, such as a read lock, write lock, or other lock on the data item at the metadata or lock location, logging / storing a version for the data item in a read or write record for a transaction, determining whether a read set for a transaction is still valid at that point, buffering or backing up a value of the data item, setting monitors, updating a filter value, and any other transactional operations.

Often, however, subsequent accesses to the same data item in a transaction each time the access to the data item is encountered causes the overhead of executing an associated transactional barrier. By way of illustration, three writes to address A are performed in one transaction, resulting in a write-barrier three times apart in this scenario to obtain a write lock for address A. However, the lock for address A has already been obtained by performing a write barrier on the first transactional write, and the subsequent two executions of write barriers prior to the last two transactional writes are redundant - the lock on address A need not be recovered.

Thus, in one embodiment, the hardware maintains a filter value to speed up an implementation associated with these barriers. The filter value may be included in a cache, such as the read and write monitors, as an annotation bit, or may be held at a metadata location in a metaphysical address space, as previously described. Using the example above, the first time the write barrier encounters, a write filter value is updated from an un-accessed value to an accessed value to indicate that a write barrier to address A has already been encountered within the transaction. Therefore, in the subsequent two transactional writes within the transaction, the write filter value is checked before vectoring to the write barrier for address A. Here, the filter value includes an accessed value indicating that the write barrier does not need to be executed - the write barrier has already been executed within the transaction. As a result, the execution is not vectored to the write barrier for at least the last two write operations. In other words, the filter value speeds up the transactional execution - omits or does not include execution of the write barrier for the at least two accesses compared to the previous example without using a filter.

Note that read / write filters, undo filters for undo operations, and other filters for generic filter operations can be used in the same way as the write filter above was used for write / store operations.

Concepts also associated with transactional barriers are the strong and weak atomics that deal with the isolation of transactional operations from non-transactional operations. Herein, as well as transactional writing to a transactionally-loaded location represents a potential conflict, a transactional write to a non-transactionally-loaded location represents a potential conflict that results in the non-transactional use of invalid data Loading operation leads. In weak atomic systems, no or minimal barriers are included in non-transactional operations, so the weak atomic systems are at risk of invalid execution. In contrast, in systems with strong atomicity, transactional barriers are also included in non-transactional operations. This ensures protection and isolation between transactional and non-transactional operations, but at a cost - the cost of executing a transactional barrier for each non-transactional operation.

Thus, in one embodiment, the above-described filters in combination with strong atomic barrier may be effectively employed in non-transactional operations to support various high and low atomicity modes of operation. To illustrate, a simplified exemplary embodiment is shown in FIG 6 shown. This will be metadata 610 in hardware for data 605 held as explained above. A metadata access 600 is received to on metadata 610 access. In one embodiment, the metadata access includes a test metadata operation to test a filter, such as a read filter, write filter, undo filter, or other filter.

A test metadata operation to test a filter may be from a transactional or non-transactional access operation. In one embodiment, when compiling an application code, a compiler inserts the test-filter operation inline into the application code as a condition to execute a transactional barrier call on transactional and non-transactional accesses. Therefore, in a transaction, the filter operation is performed prior to a call to a barrier, and if it successfully returns, the call to the transactional barrier is not executed, thereby achieving the acceleration discussed above.

Even in non-transactional operations, in one embodiment, the hardware is capable of operating in a low atomic mode, where transactional barriers are not performed in non-transactional operations, and in a strong atomic mode, where transactional barriers are executed.

The operating mode or controller 625 can in metadata control register (MDCR) 615 which can be combined with the version of MDCR as described above to hold MDIDs or may be a separate control register. In another embodiment, the controller may 625 for the operating mode in a general transactional control register or status register. Herein, a first mode of execution includes a strong atomic mode where transactional barriers are to be performed in non-transactional operations. In this case, the controller represents 625 a first value, such as 00, to indicate a strong atomic and non-transactional operating mode. In the reaction to it chooses the logic 620 listed as an exemplary multiplexer, the metadata value from metadata 610 which are held by hardware and which are connected to data address A, which is for metadata access 600 to the destination register 650 to deliver. In essence, barriers are accelerated in a strong atomic mode based on the current hardware-held metadata. Alternatively, during a second execution mode, such as a non-transactional mode with weak atomicity, in response to a metadata access 600 instead of the hardware metadata 610 a fixed or forced value from the MDCR to the destination register 650 delivered as by control 625 is displayed, which represents a second value, such as 01.

In essence, in a low atomicity mode, a forced value becomes the destination register 650 in response to a test filter operation 600 to ensure that the filter value test is always successful and the transactional barrier call is not executed before non-transactional memory access. Note that this description assumes that the test filter operation returns a Boolean value to indicate whether the filter test is successful (the barrier is not running) or fails (the barrier is to be executed). As a result, the same filter software construct is used to accelerate transactions by ignoring barriers based on the filter value, to provide an operational mode in which all barriers are ignored in non-transactional operations - shaky atomicity mode, and provide a second mode of operation in the barrier non-transactional operations are performed or accelerated based on metadata maintained by hardware - strong atomicity. In another embodiment, different enforced values may be provided for each mode. Here, in a high atomicity mode, the forced value would ensure that the test filter operation fails so that the barrier will always be executed while in the weak atomic mode the forced value would ensure that the test filter operation succeeds, so that the barrier is not executed.

Although providing a forced or fixed value from a control register, such as MDCR 615 based on control information, such as the controller 625 , has been described in connection with providing a fixed / forced value or a metadata value based on a mode operation, providing a forced or fixed value may be used for any generic use of metadata, such as allowing for data-invariant behavior associated with a metadata Debugging and generic memory access monitoring is used, which can be activated on demand.

With reference to 7 For example, one embodiment of a flowchart for accelerating non-transactional operations while maintaining atomicity in a transactional environment is shown. In the river 705 is encountered a metadata (MD) access operation pointing to a data address. As a specific illustrative example, the MD access operation includes a test operation previously inserted by a compiler in-line with application code to override a transactional barrier in a non-transactional memory access if the test returns a value (success) and execute the barrier if the test returns a second value (fail). However, a test MD operation is not so limited since it can include any test operation for returning a Boolean hit or miss value.

In the river 710 an operating mode is determined. Here, examples of a mode of operation may be transactional or non-transactional in connection with strong atomicity or weak atomicity. Therefore, one or two separate registers may hold a first bit to indicate a transactional or non-transactional mode of operation and a second bit for a high or low atomicity mode of operation.

If the mode of operation is transactional or non-transactional and has strong atomicity, the metadata value maintained by hardware is provided to the metadata access operation - the hardware maintained value is placed in a destination register specified by the MD access operation. In contrast, if the mode of operation is not transactional and has weak atomicity, the enforced fixed MDCR value is supplied to the MD access operation instead of the hardware-maintained MD value. Thus, during the high atomicity mode, barriers are accelerated or are not based on a hardware-maintained MD value, while in the low-atomic mode, barriers based on the forced MDCR value are accelerated.

Effective transition in a buffered and monitored state

The following is with reference to 8th an embodiment of a flowchart for a method for effectively transferring a data block into a buffered and monitored state before a transaction is committed. As described above, memory blocks, such as a cache line holding a data item or metadata, may be buffered and / or monitored. For example, coherence bits for a cache line include a representation of a buffered state, and attribute bits for a cache line indicate whether the cache line is not monitored, read-monitored, or write-monitored.

In some embodiments, a cache line is buffered, but not monitored, which means that the data held in the cache line is lossy and that conflicts concerning the cache line are not detected because there is no dedicated monitoring. For example, data that is local to a transaction and need not be committed, such as metadata, may be kept in a buffered and unmonitored state.

When conflicts between buffered data and writes to the same address are to be detected, read-only monitoring is applied to the data. The cache line is then put into a buffered and read-monitored state. However, to get into this state, a read request is sent to external processing elements which forces all other copies to transition to a common state. These external read requests may conflict with another processing element that maintains a write monitor for the same block / same cache line.

Similarly, write monitoring is applied to the cache line when conflicts between the buffered data and reads at the same memory blocks are to be detected. The line is then placed in a buffered and read-only state, obtained by sending a read-for-ownership request to another processing element, all others Copies force you to enter an invalid state. Similarly, a conflict is detected on any processing element that maintains either read or write control for the same memory block.

However, to minimize transactional conflicts, a block of memory which the transaction may update, but may not commit, may be maintained in the buffered but unsupervised state, as described above. However, if it is determined for a block being held in the buffered but unsupervised state that it needs to be committed, then according to one embodiment, an effective path from the buffered and unsupervised state to a commitable state is provided, as in FIG 8th is shown.

As an example, a buffered update for a memory block - a cache line to hold the block - will flow 805 receive. Either before the buffered update or simultaneously with it, a read-only watch is applied to the block. For example, a read attribute for the cache line is set to a read monitor value to indicate that the block is read-monitored. However, to read-monitor, first, a read request to other processing elements in flow 815 sent. In response to receiving the read request, the other processing elements either already conflict because of maintaining the line in a write monitor state or transfer their copies to a common state in the flow 820 , In the river 825 For example, if there are no conflicts, the cache line is transferred to a buffered and read-monitored state - the cache line coherency bits are updated to a buffered coherency state and the read monitor attribute is set.

In the river 830 conflicting writes to the cache line are detected based on the read monitoring. In one embodiment, the read attributes are coupled to a snoop logic such that an external read-for-ownership request to the cache line detects a conflict with the read watch set on the cache line.

Later, the read monitoring is in flux 840 applied when the block is to be committed as part of a state of a transaction in flow 835 , In doing so, a read-for-ownership request flows to the other processing elements 845 which either detects a conflict in response to holding the cache line in a read or write monitored state, or copies its copy to an invalid state in the flow 850 transferred. As a result, detecting the conflicts for the read for ownership request enables detection of arbitrary conflicts at that point, thereby essentially rendering the row into a commitable state.

Thus, transferring the buffered and unmonitored block to a commitable state is in two stages - flow 810 and river 840 - potentially advantageous. Delaying owner acquisition via the tiered acquisition of read and write monitors allows multiple concurrent transactions to update the same bucket while reducing conflicts between these transactions. If, for some reason, a transaction does not get to the commit level, updating the block in a buffered and read-monitored manner will not cause another transaction to commit to terminate unnecessarily. In addition, delaying the acquisition of exclusive ownership of the block to the commit level is thus a way to achieve higher concurrency between threads without sacrificing the validity of data.

Tabelle E: eine Ausführungsform sich entgegenstehender Zustände zwischen zwei Verarbeitungselementen Table E below illustrates an embodiment of conflicting states between two processing elements: P0 and P1. For example, a row held by P1 in a buffered read-supervised state identified by the RB column and any state of P0 where the cache line is maintained with write-monitoring, such as -W, RW, WB, RWB is displayed, as represented by the x in the intersecting cells.

Table E: an embodiment of conflicting states between two processing elements

Tabelle E: eine Ausführungsform eines Verlustes von Attributen als Ergebnis einer Operation In addition, Table F below shows loss of associated ownership in processing element P1 in response to the operation listed under P0. For example, if P1 holds a row in a buffered read-supervised state, as indicated by column RB, and either a memory or set-write monitoring operation on P0 occurs, P1 loses both read-monitoring and buffering of the row, as indicated by xx in FIG the intersection of the memory / set WM rows and the RB column is displayed.

Table E: an embodiment of a loss of attributes as a result of an operation

Branch instruction (JLOSS) for a conflict or loss of transactional data

With reference to 9 For example, one embodiment of hardware for assisting a loss instruction to hop to a target based on a status value in a transaction status register is shown. In one embodiment, hardware provides an accelerated way to verify the consistency of a transaction. For example, hardware can be tracked by providing a mechanism that checks for loss of monitored or buffered data from the cache, consistency checking - clearing buffered or monitored lines, or potentially conflicting access to such data - monitors for detecting conflicting snoops, such as a Read for ownership request on a watched line.

Additionally, in one embodiment, hardware provides architectural interfaces to enable software to access these mechanisms based on the status of monitored or buffered data. Two such interfaces include the following: (1) instructions for reading or writing a status register that allow software to explicitly query the register during execution; (2) an interface that allows software to set up a handler that is invoked whenever the status register indicates a potential loss of consistency.

In another embodiment, hardware supports a new JLOSS-designated instruction that performs conditional branching based on the status of HW-monitored or buffered data. The JLOSS instruction branches to a tag if the hardware detects a potential loss of any monitored or buffered data from the cache, or it detects potential conflicts for any such data. A tag includes any destination, such as an address of a handler or other code to be executed as a result of data loss or detection of a conflict.

As an illustrative embodiment 9 decoder 910 , which recognize JLOSS as part of a processor ISA, and decode the instruction to allow processor logic to execute the conditional branch based on the status of a transaction. As an example, the status of a transaction in a transaction status register 915 held. The transaction status register may represent the status of transactions, such as when hardware detects a conflict or loss of data - which is referred to herein as a loss event. By way of illustration, a conflict flag in TSR 915 is set when a monitor indicates that an address is being monitored in combination with a snoop to the monitored address, with the conflict flag in TSR 912 indicates that a conflict has been detected. Similarly, a loss flag is set on data loss, such as emptying a line that includes transactional data or metadata.

Therefore, herein JLOSS, when detected and executed, tests the status register flags and, if there is a miss event - a loss and / or conflict, provides the logic 925 the trademark referenced by JLOSS to the execution resources 930 as a jump destination address. As a result, software with a single instruction will be able to determine the status of a transaction and, based on the status, will be able to vector an execution to a mark specified by the single instruction. Because JLOSS checks for consistency, reporting false conflicts is acceptable - JLOSS can conservatively report that a conflict has occurred.

According to one embodiment, software, such as a compiler, inserts JLOSS instructions into the program code to query for consistency. Although JLOSS can be used inline with the main application code, JLOSS instructions are often used in read and write barriers to determine on demand the consistency that is often provided in libraries; therefore, execution of a program code may include a compiler to insert JLOSS into code, or execution of JLOSS from the program code, or any other form of inserting or executing an instruction. It is expected that querying through JLOSS is much faster than explicitly reading the status register because the JLOSS instruction does not require additional registers - there is no need for a destination register to receive the explicit read status information. There are several embodiments of this instruction in which the conditions for checking for consistency are either explicitly provided in the instruction or implicitly in a separate control register.

For example, the transaction history register holds 915 or another memory element has special conflict and loss status information, such as whether a read-monitored location has been written by another agent - read conflict, read-write location, or one other agents described - write conflict, a loss of physical transactional data or a loss of metadata has occurred. Therefore, different versions of the JLOSS instruction can be used. For example, a JLOSS.rm <label> instruction branches to its tag if any read-monitored location has been described by another agent. A hardware accelerated STM (HASTM) is able to use its JLOSS.rm instruction to speed up a consistency check - quickly check for conflicting updates to a read set by using JLOSS.rm whenever a read set consistency for example, after each transactional load in a Native Code TM system. In this case, a read set can be verified using JLOSS in a read barrier so that the JLOSS instruction is inserted into the barrier in a library or after the load operation inline with the main application code. Similar to the JLOSS instruction to capture writes to read-monitored locations, a JLOSS.wm instruction can be used to capture any read or write to read-only locations. As yet another example, in a processor that can buffer locations, a JLOSS.buf instruction may be used to determine if buffered data has been lost and to subsequently hop to a specified mark.

The following pseudo code, called Pseudocode A, shows a Native Code STM read barrier that provides a consistent read set and uses JLOSS. The setrm (void * address) function sets the read monitor to the given address and the JLOSS_rm0 function is an intrinsic function for the JLOSS instruction that returns "true" if conflicting accesses to read-monitored locations have occurred. This pseudocode monitors the loaded data, but it is also possible to monitor the transaction records (owner records) instead. It is possible to use an instruction that combines setting the read monitor to load the data - e.g. A movxm instruction that both loads and monitors the data. Likewise, it is possible to use this in a read barrier that performs a filter in addition to monitoring, as well as to use in an STM system that only uses hardware monitoring for read set validation - an STM system that is not software Read-only and no SW validation. Pseudo code A: an in-situ update STM, optimistic reading, native code barrier

Similarly, an STM system that does not maintain read set consistency, such as a managed code STM, infinite loops, or other incorrect control flow, can avoid exceptions due to inconsistency by inserting a JLOSS instruction at the return loop. Borders or other critical control flow points, such as instructions that may cause exceptions.

The following pseudo-code, called pseudocode B, shows another native-code read barrier that ensures consistency. The TM system of this release uses cacheresidentes writing sets using buffered updates for writing within transactions. Reading from a previously buffered and then lost location causes an inconsistency and, to maintain consistency, this read barrier avoids reading from any lost buffered location. The COMMIT_LOCKING flag is true if the STM uses a buffered-location commit time-out. The JLOSS_buf0 check is used for reads from a previously locked location if no commit time lock is used. Otherwise, it will be used in all reads. Pseudo-code B: in situ update, native code STM reading barrier

TM systems may combine read monitoring with buffering and write monitoring, as discussed above, and thus may include checking for conflicts on either monitored or buffered lines to maintain consistency. To accommodate such systems, various embodiments may also provide JLOSS variants that branch to logical combinations of various monitoring and buffering events, such as JLOSS.rm.buf (conflicts at read-monitored or buffered locations), JLOSS. rm.wm (conflicts at read or write-monitored locations) or JLOSS. * (conflict at a read-only, read-only, or buffered location).

In another embodiment, the architectural interface decouples the JLOSS instruction from the conditions under which it branches by allowing software to set conditions - conflict on read / write-monitored rows or buffered rows - in a separate control register. In this embodiment, only a single JLOSS instruction is required, which may support future extensions of the group of events at which JLOSS is to branch.

In reference to 10 For example, one embodiment of a flowchart for a method of executing a loss instruction to jump to a target based on a conflict or loss of specific information is shown. In one embodiment, a JLOSS instruction is in flow 1005 receive. As discussed above, the JLOSS instruction may be inserted by a programmer or compiler into either main codes, such as a load operation to ensure read-set consistency, or within a barrier such as within a read or write barrier. The JLOSS instruction and its variants explained above are at one Embodiment recognizable as part of the ISA of the processor. Here decoders are able to decode the opcodes for the JLOSS instruction.

In the river 1010 determines if a conflict or loss of information has occurred. In one embodiment, the type of conflict or loss depends on the variant of the JLOSS instruction. For example, if the received JLOSS instruction is a JLOSS.rm instruction, it is determined if a read-supervised row was accessed by an external write in a conflicting manner. However, as described above, any variation of JLOSS may be received, including a JLOSS instruction that allows the user to specify conditions in a control register.

Therefore, once the conditions are set, either by the control register or by a type of JLOSS instruction, it is determined if these conditions have been met. As a first example, information in a transaction status register, such as TSR 915 , used to determine if the conditions have been met. Here is the TSR 915 a read-monitoring status flag set by default to a no-conflict value and updated to a conflict value to indicate that a conflict has occurred. However, a status register is not the only way to determine if a conflict has occurred and, in fact, any known method of determining a loss or conflict may be used.

In response to no conflict being detected, such as when a read conflict conflict flag is still at a default value in TSR 915 is set, a false value becomes in flux 1025 returned and the execution continued normally. However, if a conflict or loss has been detected, such as by setting the read-guard conflict flag, JLOSS returns "true" in flow 1015 back and redirects the execution to jump to a mark, which flows through the received JLOSS instruction 1020 was received.

Hardware support for transactional storage commit

As discussed above, hardware-assisted transactions can speed the management of a version of the software by buffering transactional writes in the cache without making them globally visible. In this case, a simple commit instruction can be used that makes the buffered values visible to all processors, but fails if any buffered lines are lost. However, the ability of hardware to hold metadata that software may use for acceleration, such as a filter to remove / filter redundant barriers, may require a commit instruction to fail if hardware has detected any conflicts. Additionally, at commit, it may be desirable to delete various combinations of information held in hardware for a transaction, such as metadata, monitors, and buffered rows.

Thus, in one embodiment, the hardware supports multiple forms of a commit instruction to allow the commit instruction to determine both the commit conditions and the information to be deleted at commit. With reference to 11 For example, one embodiment of a general case in which hardware supports definition of commit conditions and delete controls in a commit instruction is shown.

As shown, includes a commit instruction 1105 an opcode 1110 , which is recognizable as part of the ISA of a processor - decoder 1115 are capable of the opcode 1110 to decode. In the illustrated example, the opcode includes 1110 two parts: commit conditions 1111 and an erase control 1112 , The commit conditions 1111 specify the conditions for committing a transaction while the commit deletion control 1112 sets the information to be deleted when a transaction is committed.

In one embodiment, both parts include four values: read monitoring (RM), write monitoring (WM), buffering (Buf), and metadata (MD). Essentially, if any of the four values in the section 1111 is set - including a value to indicate that the associated attribute / property is a commit condition, the corresponding property is a condition for the commit. In other words, if the first bit of conditions 1111 according to read monitoring information, the loss of any read monitoring data from the monitors 1135 aborted - no commit because a specified condition of the commit instruction has failed. Similarly, the corresponding property is deleted on commit, if a value in 1112 is set. To continue the example, the read monitoring information is displayed in the monitors 1135 cleared for the transaction if the transaction is committed, if RM is in the part 1112 is set. Therefore, in this example, there is a possibility of four conditions for commit and four delete controls, resulting in 256 possible combinations as modifications to a commit instruction. In one embodiment, by allowing the commit conditions in the opcode to be specified, the hardware is able to support all variations. However, a few modifications are described below for further understanding of the various types of commit instructions and how to use them.

TXCOMWM

As a first example, a Txcomwm instruction is discussed. This instruction terminates the transaction and makes all write-monitored buffered data generally visible if no read-only data has been lost (success); On the other hand, it has no success if write-monitored data is lost. Txcomwm sets (or resets) a flag to indicate success (or failure). If successful, Txcomwm clears the buffered state of all read-only data. Txcomwm does not affect a read-only or write-monitored state, which allows software to reuse this state in subsequent transactions. It also does not affect the state of locations that are buffered but not write-monitored, allowing software to continue to hold information held in such locations. The pseudocode marked below as Pseudocode C illustrates an algorithmic description of Txcomwm. If TSR.LOSS_WM is 0, the BF property of all write-monitored buffered BBLKs is atomically cleared and all such buffered data becomes visible to other agents. TCR.IN_TX is deleted. Buffered blocks that have no WM are not affected and remain buffered. The CF flag is set on completion. If TSR.LOSS_WM is 1, the CF flag is cleared and TCR.IN_TX is cleared. The CF flag is set to 1 if the operation was successful and 0 in the case of a failure. The OF, SF, ZF, AF and PF flags are set to 0. Pseudocode C: Embodiment of an algorithm for a Txcomwm operation

The pseudocode, hereafter referred to as Pseudocode D, shows how a HASTM system is able to use the Txcomwm instruction to commit a transaction that uses a hardware write buffer to perform an undo logging in an in-situ to avoid updated STM. The CACHE-RESIDENT-WRITES flag indicates this execution mode. illustrates an embodiment, such as a HASTM Pseudocode D: Embodiment of a Pseudocode for Using a TXCOMWM Instruction

TXCOMWMRM

According to one variant, txcomwmrm extends the Txcomwm instruction so that it fails if any read-monitored locations are also lost. This variant is useful for transactions that only use hardware to capture read conflicts. The pseudocode marked pseudo-code E below illustrates an algorithmic description of Txcomwmrm. If TSR.LOSS_WM and TSR.LOSS_RM are 0, the BF property of all write-monitored buffered BBLKs is atomically cleared, and all such buffered data becomes visible to other agents. TCR.IN_TX is deleted. Buffered blocks that have no WM are not affected and remain buffered. The CF flag is set upon completion. If TSR.LOSS_WM or TSR.LOSS_RM is 1, the CF flag is cleared and TCR.IN_TX is cleared. The flag is set to 1 if the operation was successful and cleared to 0 on failure. The OF, SF, ZF, AF and PF flags are set to 0. Pseudocode E: An embodiment of an algorithmic description of Txcomwmrm

The next pseudocode, pseudocode F, shows the commit algorithm using the Txcomwmrm instruction for an STM system that uses hardware both to buffer transactional writes and to detect read set conflicts. The HW_READ_MONITORING flag indicates whether the algorithm uses only hardware for a read-set conflict detection. Pseudocode F: An embodiment of a pseudocode that uses the Txcomwmrm instruction

TXCOMWMIRMC

A third variant is shown below in the description of the algorithm of the pseudocode F. If TSR.LOSS_WM and TSR.LOSS_IRM are 0, the BF property of all write-monitored buffered BBLKs is atomically cleared, and all such buffered data becomes visible to other agents. RM, WM and IRM and TCR.IN_TX are deleted. Buffered blocks that have no WM are not affected and remain buffered. The CF flag is set at completion. If TSR_LOSS_WM or TSR.LOSS_IRM is 1, the CF flag is cleared and TCR.IN_TX is cleared. The CF flag is set to 1 if the operation was successful and cleared to 0 on failure. The OF, SF, ZF, AF and PF flags are set to 0. Pseudocode F: An embodiment of an algorithmic description for a TX-COMWMIRMC instruction

With reference to 12 "An embodiment of a flowchart for a method of executing a commit instruction that defines commit conditions and delete controls is shown. In the river 1205 a commit instruction is received. As explained above, a compiler can insert a commit instruction into a program code. As a specific illustrative example, a call to a commit function is inserted into a main code, and the commit function, such as that encompassed above by the pseudo-code, is provided in a library; a compiler can also insert the commit instruction into the commit function in the library.

After the commit instruction has been received, decoders are able to decode the commit instruction. From the decoded information will flow 1210 set the conditions determined by the op code of the commit instruction. As explained above, the op code may set some flags and reset others to indicate which conditions to commit. If the conditions are not met, an error (false) is returned and the transaction can be aborted separately. However, if the commit conditions, such as any combination of no loss of read monitoring, write monitoring, metadata, and / or buffers, are in flux 1215 the cancellation conditions / control determined. As an example, any combination of read monitors, write monitors, metadata, and / or buffers for the transaction is designated for deletion. As a result, the information intended for deletion will be in flux 1225 deleted.

Optimized memory management for UTM

As discussed above, the Unlimited Transactional Memory Architecture (UTM) and its hardware implementation extend the processor architecture by introducing the following properties: monitoring, buffering, and metadata. Combined, they provide the software with the necessary tools to implement a variety of advanced algorithms, including a wide range of transactional memory designs. Each property can be implemented either by extending the existing cache protocols in the cache implementation or by allocating independent new hardware resources as hardware.

When the UTM properties are implemented with HW, the UTM architecture and its hardware implementations potentially provide a performance boost to transactions through a software-only solution, if it is possible to effectively avoid and facilitate disruptions such as UTM transaction aborts and subsequent transaction retry operations minimize. One of the main causes of hardware transaction aborts was a frequent ring transition caused by external interrupts, system call events, and page faults.

A suspension mechanism based on a current privilege level (CPL) enables a hardware transaction (enables a hardware-accelerated transaction with UTM properties, such as buffering and monitoring, and enables the eject mechanism), while the processor at privilege level 3 (FIG. User mode) works. Ring transitions from Ring 3 cause automatic suspension of the currently active transactions (stopping the generation of UTM properties and disabling the ejection mechanism). Similarly, ring transitions back to ring 3 automatically resume the previously suspended hardware transaction as if it were active. The potential disadvantage of this approach is that the use of hardware transactional memory resources in kernel code or on any other ring layer except ring 3 is mostly excluded.

In another approach, duplicate TM control resources, such as a transaction control register (TxCR) for ring 0, are introduced so that the hardware transactions for the ring 0 code can still be enabled with these separate TM resources. However, this approach still potentially lacks an effective solution for handling nested interrupts and exceptions during Ring-0 transaction operations.

As a result, illustrated 13 an embodiment of hardware to support privileged-level handle handling during the execution of transactions, which enables Ring 0 transactions on the user-mode (Ring 3) transactions, but also ensures that the OS and a hypervisor such as For example, a virtual machine monitor (VMM) handles unrestricted levels of nested interrupts and NMI cases in the presence of Ring 0 transactions, a storage element such as an EFLAGS register 1310 includes a transaction activation field (TEF) 1311 , If the TEF 1311 holds an active value, it indicates that a transaction is currently active and enabled while indicating that a transaction has been suspended if TEF 1311 holds an inactive value.

In one embodiment, a transaction start operation or other operation sets the TEF field at the beginning of a transaction 1311 to the active value. In a ring level transaction event in the flow 1300 , such as an interrupt, an exception, a system call, a virtual machine exit, or the entry of a virtual machine, becomes the state of the PE-0 flag register 1310 on the kernel pile 1320 in the river 1301 pushed. At the river 302 becomes the TEF field 1311 deleted / updated to the inactive value to suspend the transaction. The ring level transition event is appropriately handled or serviced while the transaction is suspended. When detecting a return event on the flow 1303 becomes the state of the Eflags register 1310 that at the river 1301 was pushed on the pile, by the river 1304 brought to Eflags 1310 restore to the previous state. The restoration of the previous state brings TEF 1311 back to the active value and takes the transaction as active and reactivated.

Specific examples of the process for illustrative ring-level transition events are listed below. For interrupts and exceptions, the processor shifts the eflags register into the kernel stack and clears the "Transaction Enable" bit if set, thereby suspending the previously activated transaction. With IRET, the processor sets the entire eflags register state for the interrupted one Thread, including the "Transaction Enable" bit, from the kernel stack, which will suspend the transaction if it was previously enabled.

At SYSCALL, the processor shifts the eflags register and clears the transaction enable bit if set, thereby suspending the previously activated transaction. In SYSRET, the processor recovers the entire eflags register state for the interrupted thread, including the transaction enable bit from the kernel stack, thereby suspending the transaction if it was previously enabled.

At VM exit, the processor stores the guest's Eflags register including the Transaction Enable bit state in the virtual machine control structure (VMCS) and loads the host's Eflags register state, which is the "Transaction Enable" bit Status, which suspends the guest's previously activated transaction, if enabled.

At VM entry, the processor recovers the guest's Eflags register, including the "Transaction Enable" bit state from the VMCS, with the guest's previously activated transaction being suspended if it was activated.

This activates kernel mode hardware-accelerated (ring 0) UTM transactions on the user mode hardware-accelerated UTM transactions (ring 3), but also provides paths for both the OS and the VMM to provide unlimited levels of interleaved interrupts and NMIs. Treat cases in presence of Ring 0 transactions. Such mechanisms are not provided in any prior art.

A module used herein refers to any hardware, software, firmware or combination thereof. Module boundaries shown separately may generally vary frequently and potentially overlap. For example, a first and a second module may share hardware, software, firmware, or a combination thereof, while potentially retaining a portion of independent hardware, software, or firmware. In one embodiment, use of the term includes logic hardware, such as transistors, registers, or other hardware, such as programmable logic devices. However, in another embodiment, logic includes software or code integrated into hardware, such as firmware or microcode.

A value used herein may include any known representation of a number, state, logic state, or binary logic state. Often, the use of logic levels, logic values, or logic values is also referred to as 1s, 0s, which simply represents binary logic states. For example, a 1 refers to a high logic level and 0 to a low logic level. In one embodiment, a memory cell, such as a transistor or a flash cell, may be configured to hold a single value or multiple logical values. However, other representations of values in computer systems have also been used. For example, the decimal number 10 may also be represented as a binary value of 1010 and a hexadecimal letter A. Therefore, a value may include any representation of information that is suitable for being held in a computer system.

In addition, states can be represented by values or parts of values. As an example, a first value, such as a logical one, may represent a default state or initial state, while a second value, such as a logical zero, may represent a non-default state. Additionally, in one embodiment, the terms reset and set refer to a default value or state, or an updated value or state. For example, a default value potentially includes a high logical value, i. H. a reset, while an updated value potentially has a low logical value, i. H. Put, includes. Note that any combination of values can be used to represent any number of states.

The embodiments of methods, hardware, software, firmware or code set forth above may be implemented via instructions or code stored on a machine-accessible or machine-readable medium executable by a processing element. A machine accessible / readable medium includes any mechanism that provides information (i.e., stores and / or transfers) of information in a form that is readable by a machine, such as a computer or electronic system. For example, a machine-accessible medium includes random access memory (RAM) such as static RAM (SRAM) or dynamic RAM (DRAM); ROME; a magnetic or optical storage medium, flash memory devices, an electrical storage device, optical storage devices, acoustic storage devices, or other form of propagating signal (e.g., carrier waves, infrared signals, digital signals), storage device, etc. For example, a machine may be mounted on a storage device by receiving a propagating signal, such as a carrier wave, from a medium capable of holding the information to be transmitted on the propagating signal.

Throughout this description, reference to "a single embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the places where the terms "in a single embodiment" or "in one embodiment" appear in this specification are not necessarily all the same embodiment. Moreover, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

In the foregoing description, a detailed description has been given with reference to specific exemplary embodiments. It is, however, to be understood that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. Accordingly, the description and drawings are to be considered in an illustrative sense and not in a limiting sense. Moreover, the foregoing use of an embodiment or other exemplary language does not necessarily contemplate the same embodiment or example, but may refer to other and different embodiments as well as potentially to the same embodiment.

Claims (130)

Apparatus comprising: a plurality of processing elements, wherein a processing element of the plurality of processing elements is to be associated with a plurality of software subsystems; a metaphysical logic to associate a metadata access operation to be associated with a current software subsystem of the plurality of software subsystems and reference a data address to a metaphysical address space associated with the current software subsystem based on at least the data address and a metadata identifier (MDID) corresponding to the current one Software subsystem is assigned. The apparatus of claim 1, wherein the metaphysical address space associated with the current software subsystem is to be orthogonal to a data address space comprising the data address and at least one other metaphysical address space subordinate to the second software subsystem of the plurality of software subsystems. The apparatus of claim 2, wherein each of the plurality of software subsystems is individually selected from a group consisting of a transactional runtime subsystem, a garbage collection runtime subsystem, a memory protection subsystem, a software translation subsystem, an outer transaction of a nested set of transactions, and an inner transaction of a nested group of transactions. The apparatus of claim 1, further comprising decoding logic for decoding the metadata access operation, wherein the metadata access operation comprises an opcode that is recognized as one of the plurality of supported operations within the decode logic. The apparatus of claim 1, wherein the metaphysical logic comprises metaphysical translation logic to translate the data address into a metadata address in the metaphysical address space associated with the current software subsystem based on at least the MDID. The apparatus of claim 5, wherein the metaphysical translation logic for translating the data address into a metadata address within the metaphysical address space associated with the current software subsystem is further based on a processing element identifier (PEID) connected to the processing element. The apparatus of claim 6, wherein the metaphysical translation logic for translating the data address into a metadata address within the metaphysical address space associated with the current software subsystem is further based on a compression ratio of data to metadata. The apparatus of claim 6, further comprising a register that is modifiable by the current software subsystem, the register being configured to hold the MDID in response to a write from the current software subsystem to indicate that the current software subsystem is currently on the processing element and wherein the metaphysical translation logic is based on the PEID for translating the data address into a metadata address within the metaphysical address space associated with the current software subsystem, and wherein the MDID includes the metaphysical translation logic to provide a representation of the data address with the PEID and the Combine MDID. The apparatus of claim 8, wherein the metaphysical translation logic for combining a representation of the data address with the PEID and the MDID is based on a combination algorithm selected from a group consisting of an algorithm for adding the PEID and the MDID to the data address at the data address an algorithm for translating the data address into a translated data address using normal data translation tables and adding the PEID and MDID to the translated address to form the metadata address and an algorithm for translating the data address into a translated metadata address using metaphysical translation tables are separate from normal data translation tables, and adding the PEID and MDID to the translated metadata address to form the metadata address. Method, comprising: Finding a metadata operation that references a data address located within a data address space and associated with a data item held in a data entry of a cache memory; Determining a metadata address in a metaphysical address space separate from the data address space based on the data address, a processing element identifier (PEID) of a processing element associated with the metadata operation, and a metadata identifier (MDID) for a software subsystem associated with the processing element connected is; Accessing a metadata entry of the cache memory based on the metadata address. The method of claim 10, wherein the metaphysical address space is also separated from an additional metaphysical address space associated with an additional software subsystem also connected to the processing element. The method of claim 10, wherein the software subsystem is selected from a group consisting of a transactional runtime subsystem, a garbage collection runtime subsystem, a storage protection subsystem, a software translation subsystem, an outer transaction of a nested set of transactions, and an inner transaction a nested set of transactions. The method of claim 10, further comprising: Writing the MDID into a control register associated with the processing element in response to finding a write operation to the control register from the software subsystem in response to the software subsystem currently executing on the processing element; and Determine the MDID from the control register. The method of claim 13, further comprising: Determine the PEID from a part of an opcode for the metadata operation. The method of claim 13, wherein determining the metadata address from the data address, the PEID, and the MDID comprises: combining the data address, the PEID, and the MDID with an algorithm selected from a group consisting of an algorithm to obtain the PEID and add the MDID to the data address to form the metadata address, an algorithm to translate the data address into a translated data address using normal data translation tables, and add the PEID and the MDID to the translated data address to form the metadata address, and a Algorithm to the There is a translation of data address into a translated metadata address using metaphysical translation tables that are separate from normal data translation tables, and to add the PEID and MDID to the translated metadata address to form the metadata address. Apparatus comprising: Decoding logic for decoding a metadata access instruction to reference a data address of a data item, the metadata access instruction comprising an op code recognizable as part of an instruction set capable of being properly decoded by the decode logic; and metadata logic for translating the data address into a different metadata address, transparent to software, and for accessing metadata referenced by the different metadata address in response to the decoding logic decoding the metadata access instruction. The apparatus of claim 16, wherein the metadata access instruction is selected from a group of instructions consisting of a Metadata Bit Test and Set (MDLT) Instruction, a Metadata Store and Set (MSS) Instruction, and a Metadata Store and Reset Instruction (MDSR). The apparatus of claim 16, wherein the metadata access instruction is selected from a group of instructions consisting of a compressed metadata testing (CMDT) instruction, a compressed metadata storage (CMS) instruction, and a compressed metadata clearing instruction (CMDCLR). The apparatus of claim 16, wherein the metadata logic for translating the data address into a different metadata address, transparent to software, comprises translating the data address based at least on a metadata identifier (MDID) specified in a control register by a software subsystem associated with the Metadata access instruction. The apparatus of claim 16, wherein the metadata access instruction also includes a reference to a destination register and wherein the metadata logic for accessing metadata referenced by the different metadata address comprises the metadata logic for loading the metadata at the referenced different metadata address into the destination register. The apparatus of claim 20, wherein the op code comprises a thread identifier field for identifying the thread from which the metadata access instruction originated. The apparatus of claim 20, wherein the metadata logic for accessing metadata referenced by the different metadata address further comprises the metadata logic for setting the metadata at the referenced different metadata address to a set value in response to the Destination register loaded metadata are an unset value. The apparatus of claim 22, wherein the set and unset values are specified in the metadata access instruction. Machine-readable medium holding a program code which, when executed by a machine, causes the machine to perform the following operations: In response to a data access operation that refers to a data address: generating a metadata access operation to freeze on the data address during the data access operation, the metadata access operation, when executed by the machine, causing the machine to: To translate the data address into a metadata address that is separate from the data address, and to access metadata for a data item at the data address based on the metadata address. The machine readable medium of claim 24, wherein the metadata access operation is selected from a group of instructions consisting of a metadata bit test and set (MDLT) instruction, a metadata storage and set (MSS) instruction, and a Metadata Store and Reset Instruction (MDSR). The machine-readable medium of claim 24, wherein the metadata access operation is selected from a group of compression instructions consisting of a compressed metadata testing (CMDT) instruction, a compressed metadata storage (CMS) instruction, and a compressed metadata delete instruction (CMDCLR). The machine readable medium of claim 26, wherein the metadata access operation, when executed by the machine to cause the machine to translate the data address into a metadata address, comprises causing the metadata access operation, when executed by the machine, to cause the machine to do so to combine the data address with a processing element identifier (PEID) associated with the metadata access operation and a metadata data identifier (MDID) associated with the metadata access operation based on a compression ratio of data to metadata. The machine readable medium of claim 27, wherein the data address is also adapted to be translated by logic to translate a virtual to a physical address in the machine to refer to the data item. The machine-readable medium of claim 24, wherein the metadata access operation also refers to an operand register and wherein the metadata access operation, when executed by the machine to cause the machine to access metadata for the data item, comprises metadata access operation as performed by the machine is running causes the machine to update the metadata for the data item with a value held in the operand register. The machine readable medium of claim 24, wherein the program code comprises a compiler code and wherein the compiler code is for compiling application code including the data access operation, and wherein generating the metadata access operation on the data access operation comprises generating the metadata access operation in a compiled version of the application code. A machine-readable medium holding program code which, when executed by a machine, causes the machine to perform the following operations: translating a data address referenced by a metadata access instruction in the program code into a metadata address based on a A metadata identifier (MDID) associated with a software subsystem currently active on a processing element associated with the metadata access instruction; and accessing metadata based on the metadata address. The machine readable medium of claim 31, wherein the metadata access instruction is selected from a group of instructions consisting of a metadata loading metadata load instruction, a metadata store instruction for storing the metadata, and a metadata delete instruction for resetting the metadata. The machine readable medium of claim 31, wherein the software subsystem is selected from the group consisting of a transactional runtime subsystem, a garbage collection runtime subsystem, a storage protection subsystem, a software translation subsystem, an outer transaction of a nested set of transactions, and an inner transaction a nested set of transactions. The machine-readable medium of claim 31, wherein translating a data address referenced by a metadata access instruction in the program code into a metadata address based on a metadata identifier (MDID) associated with a software system currently active on a processing element associated with the metadata access instruction comprises combining the data address with the MDID based on a combination algorithm selected from a group consisting of an algorithm to add the MDID to the data address to form the metadata address, an algorithm the data address into a translated data address using normal transactional data tables and adding the MDID to the translated address to form the metadata address and an algorithm to convert the data address into a translated metadata address using metaphysical translation tables, This is separate from normal data translation tables and adds the MDID to the translated metadata address to form the metadata address. The machine readable medium of claim 34, wherein adding the MDID comprises an algorithm for adding the MDID selected from a group consisting of an algorithm for appending the MDID in an MSB position, an algorithm for appending the MDID in an LSB position, and an algorithm for replacing address bits in the MDID. The machine-readable medium of claim 34, wherein the program code, when executed by the machine, further causes the machine to perform the following operations: determining the MDID from a control register for the processing element that is to represent the current software subsystem; currently active on the processing element. System comprising: A memory for holding a program code including a metadata access instruction that refers to a data storage address associated with a data item; A processor coupled to the memory, the processor being a processing element of a plurality of processing elements associated with execution of the metadata access instruction; fetch logic for fetching the metadata access instruction from the memory, a decode logic for decoding the metadata access instruction into at least one metadata access operation, a control register for holding a metadata identifier (MDID) associated with an active context on the processing element, a data cache to include a data entry for holding the data item, and execution logic for performing the metadata access operation, wherein the execution logic for performing the metadata access operation comprises metaphysical address translation logic in the processor to translate the data memory address into a metadata memory address based on the MDID held in the memory register and comprises a cache control logic coupled to the data cache to perform the metadata access operation on a separate entry of the data cache based on the metadata storage address a uszuführen. The system of claim 37, wherein the metadata access instruction is selected from a group of instructions consisting of a metadata loading metadata load instruction, a metadata storage instruction for storing the metadata, and a metadata delete instruction for resetting the metadata. The system of claim 37, wherein the active context is selected from a group consisting of a transactional runtime subsystem, a garbage collection runtime subsystem, a storage protection subsystem, an outer transaction of a nested set of transactions, and an inner transaction of a nested set of transactions. The system of claim 37, wherein the metaphysical address translation logic in the processor for translating the data memory address into a metadata memory address is further based on a processing element identifier (PEID) for the processing element and wherein the metaphysical address translation logic in the processor translates the data memory address into a metadata memory address based on the MDID, is held in the control register, and the PEID comprises combining the data address with the MDID and the PEID based on a combination algorithm selected from a group consisting of an algorithm for adding the MDID and the PEID to the data address to form the metadata address an algorithm for translating the data address into a translated data address using normal transactional data tables and adding the MDID and the PEID to the translated address to form the metadata address, and an A Algorithm for translating the data address into a translated metadata address using metaphysical translation tables separate from normal data translation tables and adding the MDID and PEID to the translated metadata address to form the metadata address. Processor comprising: An execution module for executing a metadata load operation that refers to an address; A strength module for providing in response to a metadata load operation a metadata value associated with an address in response to the processor operating in a first mode and providing a fixed value in response to the processor being in a second Mode works. The processor of claim 41, wherein the first mode comprises a strong atomic mode and the second mode comprises a weak atomic mode. The processor of claim 42, further comprising a first register for holding the fixed value. The processor of claim 43 including a second register for holding a mode value, the mode value having a first value for indicating that the processor is operating in the strong atomic mode. and the mode value represents a second value to indicate that the processor is operating in the weak atomic mode. The processor of claim 44, wherein the first and second registers are the same metadata control register. The processor of claim 44, wherein the strength module for providing a metadata value associated with an address in response to the processor operating in the strong atomic mode and providing a fixed value in response to the processor being in the mode weak atom, includes that the strength module loads the metadata value into a destination register specified by the metadata load operation in response to the mode value held in the second register representing the first value to indicate that the processor is in strong mode Atomic operates and loads the fixed value from the first register into the destination register in response to the mode value held in the second register representing the second value to indicate that the processor is operating in the weak atomic mode. Traversing include: Finding a metadata access operation that references an address; Determining a mode of processor execution; Providing a metadata value associated with the metadata access operation address in response to determining that the processor execution mode is a first execution mode; and Providing a fixed value from a register for the metadata access operation in response to determining that the processor execution mode is a second execution mode. The method of claim 47, wherein determining a mode of processor execution comprises reading a mode flag from a first control register, wherein the mode flag is to hold a first value to indicate that the processor execution mode is a first execution mode and hold a second value to indicate that the processor execution mode is a second execution mode. The method of claim 47, wherein providing a metadata value associated with the address for the metadata access operation comprises loading the metadata value from a storage location associated with the address into a destination register referenced by the metadata access operation. The method of claim 49, wherein providing a fixed value from a register for the metadata access operation comprises loading the fixed value from the register into the destination register. System comprising: A memory for holding a metadata load operation to reference an address and a destination register; A processor associated with the memory, wherein the processor includes execution logic to perform the metadata load operation, a metadata register to hold a forced value, a cache memory to hold a metadata value associated with the address, and strength logic to respond in that the execution logic executes the metadata load operation to supply the metadata value to the destination register in response to the processor operating in a first mode and to provide the forced value from the metadata register to the destination register in response to the processor in a second Operating mode works. The system of claim 51, wherein the strength logic is further configured to determine whether the processor is operating in the first mode or the second mode. The system of claim 52, wherein the first mode comprises a strong atomic mode and the second mode comprises a weak atomic mode. The system of claim 52, wherein the metadata register is further configured to hold a mode value, the mode value representing a first value when the processor is operating in the first mode and representing a second value when the processor is operating in the second mode, wherein the strength value is Logic is further configured to determine whether the processor is operating in the first mode or the second mode, comprising the strength logic interpreting the mode value from the metadata register. The system of claim 52, further comprising a control register for billing a mode value, the mode value representing a first value when the processor is operating in the first mode and representing a second value when the processor is operating in the second mode, and wherein the strength logic is further configured to determine whether the processor is operating in the first mode or the second mode, comprising the strength logic interpreting the mode value from the control register. The system of claim 51, wherein the memory is selected from a group consisting of dynamic random access memory (DRAM), static random access memory (SRAM), and nonvolatile memory. Apparatus comprising: A data cache array to hold a cache entry; A cache control logic coupled to the data cache array, the data control logic configured to transfer the cache entry from an unsupervised state to a buffered coherency and read-monitored state in a buffered update to the cache entry, and subsequently transferring the cache entry to a buffered coherency and write supervised state prior to transition of the cache entry to a modified state to commit the buffered update. The apparatus of claim 57, wherein the buffered update to the cache entry comprises an update selected from a group consisting of a transactional memory access to a data address for a data item to be held in the cache entry, a metadata access to a data address, the is associated with metadata to be cached, and there is a local update to the cache entry. The apparatus of claim 57, wherein the cache control logic for transferring the cache entry from an unsupervised state to a buffered coherency and read-supervised state comprises the cache control logic integrating coherency bits associated with the cache entry into one buffered value is updated to represent the buffered coherency state, and a read monitor attribute bit associated with the cache entry is updated to a read-monitored value to represent the read-monitored state. The apparatus of claim 59, wherein the cache control logic for subsequently transferring the cache entry to a buffered coherency and write-monitored state prior to transitioning the cache entry to a modified state to commit the buffered update comprises the cache memory. Control logic maintains the coherency bits associated with the cache entry at the buffered value to reflect the buffered coherency state and updates a write monitor attribute bit associated with the cache entry to a read-only value to update the buffered coherency state read-write state. The apparatus of claim 60, wherein the cache control logic for transferring the cache entry to the modified state comprises the cache control logic updating the coherency bits associated with the cache entry to a modified value to provide the modified coherency state represent. The apparatus of claim 57, further comprising execution logic for performing the buffered update and subsequently performing a commit operation, the cache control logic subsequently placing the cache entry in a buffered coherency and write-monitored state prior to transition of the cache entry in a modified state to commit the buffered update in response to the execution logic performing the commit operation. Method, comprising: Finding a buffered update to a block of a cache memory; Applying a read monitor to the block when finding the buffered update to the block of the cache; and Subsequently, apply write monitoring to the block before committing the block. The method of claim 63, wherein the buffered update to the block of the cache comprises a transactional write to the block of the cache. The method of claim 63, further comprising performing the buffered update to the block of the cache simultaneously with the application of a read monitor, wherein the block is held in a buffered coherency state after performing the buffered update. The method of claim 62, further comprising performing the buffered update to the block of the cache memory after applying read monitoring, wherein the block is maintained in a buffered coherency state after performing the buffered update. The method of claim 63, wherein applying read monitoring on the block when the buffered update is found to the block of the cache comprises: Generating a read request for the block to processing elements that are external to a cache domain of the cache memory; and Updating the read monitor attribute associated with the block of cache memory to a read monitor value to apply read monitoring to the block in response to detecting no conflicts from the processing elements that are external to the cache domain in response to the Read request for the block. The method of claim 67, wherein subsequently applying a write monitor to the block prior to committing comprises: Generating a read for a possession request for the block to the processing elements located outside the cache's cache domain; and Updating a write monitor attribute associated with the block of cache memory to a write monitor value to write-monitor the block in response to detecting no conflicts from the processing elements that are external to the cache domain in response to the reading to apply for a possession request for the block. The method of claim 68, wherein committing the block comprises: transitioning a cache coherency state of the block from a buffered coherency state to a modified coherency state. Machine-accessible medium holding program code which, when executed by a machine, causes the machine to perform the following operations: Applying a read monitor to a block of a cache on a buffered write to the block; Performing the buffered writing to the block; and Apply a write monitor to the block after applying the read monitor and before committing the block. The machine-accessible medium of claim 70, wherein applying read-monitoring to the block in a buffered write to the block of the cache comprises: Generating a read request for the block to processing elements that are external to a cache domain of the cache memory; and Updating a read monitor attribute associated with the block of cache memory to a read monitor value to provide read monitoring to the block in response to detecting no conflicts from the processing elements residing outside the cache domain in response to the read request to apply for the block. The machine-accessible medium of claim 71, wherein applying write-monitoring to the block after applying the read-monitoring and before committing the block comprises: Generating a read-for-ownership request for the block to the processing elements located outside of the cache's cache domain; and Updating a write monitor attribute associated with the block of cache memory to a write monitor value to write monitoring the block in response to writing no conflicts from the processing elements residing outside the cache domain in response to the reading apply for ownership request for the block. The machine-accessible medium of claim 70, wherein applying write-monitoring to the block occurs after applying the read-monitoring and before committing the block in response to finding a commit operation. The machine-accessible medium of claim 70, wherein committing the block comprises: translating a cache coherency state of the block into a modified coherency state. System comprising: A system memory to hold a transactional write referencing a memory address and a commit operation; A processor associated with the system memory, the processor comprising a cache to generate a read request for a cache line associated with the memory address in response to receiving the transactional write; Transitioning the cache line to a buffered and read-monitored state in response to detecting no conflicts based on the read request; Generating a read-for-ownership request in response to receiving the commit operation; Transmitting the cache line in a buffered and read-monitored state in response to no conflicts being detected based on the read-for-ownership request; and transitioning the cache line to a modified state in response to the transfer of the cell to the buffered and read-only state. The system of claim 75, wherein the cache memory for transitioning the cache line to a buffered and read-monitored state comprises the cache updating coherency bits associated with the cache line to a buffered value to the cache represent a buffered portion of the buffered and read-monitored state, and update a read monitor attribute bit associated with a cache line into a read-only value to represent the read-monitored portion of the buffered and read-monitored state. The system of claim 76, wherein the cache memory for transitioning the cache line to a buffered and read-only state includes the cache memory maintaining the coherency bits associated with the cache line at the buffered value to represent the buffered and read-only state buffered portion, and updating a write monitor attribute bit associated with the cache line to a read-only value to represent the read-only portion of the buffered and read-only state. The system of claim 77, wherein the cache memory for transitioning the cache line to a modified state in response to transitioning the line to the buffered and read-only state comprises: updating the coherency bits to a modified value to provide the modified state represent. The system of claim 75, wherein the memory is selected from a group consisting of Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), and non-volatile memory. Apparatus comprising: A decode logic for decoding a loss instruction to provide a decoded item, the loss instruction referencing a mark and comprising an opcode that is part of an instruction set recognizable by the decode logic; A status storage element comprising a loss field to hold a loss value, the loss value indicating that a loss event has been detected; and a jump logic coupled to the status memory element to transmit control to the marker based on the decoded element and the loss value to indicate that the loss event has been detected. The apparatus of claim 80, wherein the tag comprises a hop destination address, and wherein a miss event is selected from a group consisting of a read monitor conflict indicating that a write to a read-monitored cache line may have occurred, a write monitor conflict indicating that access to a write-monitored cache line might have occurred and a loss of a buffered cache line. The apparatus of claim 80, wherein the status storage element comprises a register, and wherein the loss field to hold a loss value, a first bit to be set if a read monitor conflict was detected, a second bit to set if a write monitor conflict is detected became, a third bit, to be set when a loss of buffered physical data has been detected, and a fourth bit to be set if a loss of buffered metadata has been detected. The apparatus of claim 80, wherein the loss instruction comprises a read monitor loss instruction and the op code is to specify a read monitor loss event type and wherein the jump logic for transferring control to the tag based on the decoded item and the loss value for indicating that the loss event was detected comprises the jump logic executes in response to the loss field holding the loss value indicating that the loss event that occurred was from the read monitor loss event type specified by the op code of the read monitor loss instruction to the jump label. The apparatus of claim 80, wherein the loss instruction comprises a write monitor loss instruction and the op code specifies a write monitor loss event type and wherein the jump logic for transferring the control to the mark based on the decoded item and the loss field holding the loss value for indicating that the loss event is detected , in response to the loss field holding the loss value indicating that the loss event that occurred has been of the write monitor loss event type specified by the op code of the write monitor loss instruction causes the jump logic to cause execution to occur Brand jumps The apparatus of claim 80, wherein the loss instruction has a buffered loss instruction and the op code specifies a buffered loss event type, and wherein the jump logic for rendering the control to the tag is indicative based on the decoded item and the loss field holding the loss value in that the loss event has been detected comprises the jump logic responsive to the loss field holding the loss value indicating that the loss event that has occurred is of the buffered loss event type specified by the op code of the buffered loss instruction specified, causes the execution to jump to the mark. Machine-accessible medium holding a program code that, when executed by a machine, causes the machine to perform the following operations: in response to a loss instruction: Determining a status of a transaction held in a transactional status register specified by the loss instruction and residing in the machine; and conducting execution to a mark specified by the loss instruction in response to the status of the transaction indicating that a loss event associated with the loss instruction has been detected. The machine-accessible medium of claim 86, wherein the tag includes a hop destination address and wherein a miss event is selected from a group consisting of a read monitor conflict indicating that a write to a read-monitored cache line may have occurred, a write monitor conflict indicating that An access to a read-only cache line may have occurred and there is a loss of a buffered cache line. The machine-accessible medium of claim 86, wherein the loss instruction comprises a read monitor hop loss (JLOSS) instruction intended to specify that the loss event is a read monitor conflict, wherein determining a status of a transaction held in the transactional status register comprises determining a status of a read monitor conflict bit which is held in the transaction status register, and wherein directing the execution to a mark by the loss instruction is specified in response to the status of the transaction indicating that a loss event associated with the loss instruction has been detected, directing the execution to a tag specified by the loss instruction in response to the status the read monitor conflict bit held in the transaction status register indicating that a read monitor conflict has been detected. The machine-accessible medium of claim 86, wherein the loss instruction comprises a write monitor hop loss (JLOSS) instruction intended to specify that the loss event is a write monitor conflict, wherein determining a status of a transaction held in the transactional status register comprises determining a status of a write monitor contention bit comprising, held in the transaction status register, and directing execution to a token specified by the loss instruction, in response to the status of the transaction indicating that a loss event associated with the loss instruction has been detected, comprises directing the execution to a tag specified by the loss instruction in response to the status of the write monitor conflict bit held in the transaction status register indicating that a write monitor conflict has been detected. The machine-accessible medium of claim 86, wherein the loss instruction comprises a buffered monitor hop loss (JLOSS) instruction intended to specify that the loss event is a buffered monitor conflict, wherein determining a status of a transaction held in the transactional status register comprises determining a status a buffered monitor conflict bit held in the transaction status register and wherein directing execution to a flag specified by the loss instruction in response to the status of the transaction indicating that a loss event associated with the loss instruction is detected , comprising directing the execution to a tag specified by the loss instruction in response to the status of the buffered monitor conflict bit held in the transaction status register indicating that a buffered monitor conflict has been detected. Method, comprising: Finding a loss instruction in a processor; Determining whether a loss event associated with the loss instruction has been detected in the processor in response to locating the loss instruction; and Branch to a tag referenced by the loss instruction in response to locating the loss instruction and determining that the loss event associated with the loss instruction has been detected in the processor. The method of claim 91, wherein the tag comprises a jump address. The method of claim 91, wherein the loss instruction comprises a read monitor loss instruction, and wherein the loss event associated with the read monitor loss instruction comprises writing to a read-supervised cache line. The method of claim 91, wherein the loss instruction comprises a write monitor loss instruction, and wherein the loss event associated with the write monitor loss instruction comprises access to a write-monitored cache line. The method of claim 91, wherein the loss instruction comprises a buffered loss instruction, and wherein the loss event associated with the buffered loss instruction comprises flushing a buffered cache line. The method of claim 95, wherein determining whether a buffered cache line flush has been detected in the processor comprises checking a buffered loss status bit in a transaction status register and determining that a buffered cache line flush has been detected in response to the buffered loss status bit is set to a loss value. Apparatus comprising: Decoding logic for decoding a commit instruction for a transaction to provide a decoded item, wherein the commit instruction specifies a commit condition and comprises an opcode that is part of an instruction set recognizable by the decode logic ; and Commit logic for determining whether the commit condition to be specified by the commit instruction is satisfied for the transaction in response to the decoded item. The apparatus of claim 97, wherein the commit condition includes any specified combination of no loss of read-monitored data, no loss of read-only data, no loss of buffered data, and no loss of metadata, and wherein the commit logic for determining whether the commit Condition, includes determining that the specified combination of no loss of read-monitored data, no loss of read-only data, no loss of buffered data, and no loss of metadata has occurred. The apparatus of claim 97, wherein the commit instruction for specifying a commit condition comprises the commit instruction holding four bits: a first bit, if set, for indicating that any loss of read-monitored data is a condition to commit That is, a second bit, if set, indicating that any loss of write-monitored data is a condition to commit, a third bit, if set, to indicate that any loss of buffered data is a condition is to commit, and a fourth bit, if set, to indicate that any loss of metadata is a condition to commit. The apparatus of claim 99, wherein the four bits are to be included in the op code. The apparatus of claim 99, wherein the commit logic for determining whether the commit condition to be specified by the commit instruction is satisfied for the transaction comprises the commit logic having corresponding status bits in a transaction status register for checks each of the four bits set in the commit instruction and determines that the commit condition is met if none of the corresponding status bits are set in the checked transaction register to indicate an associated loss. The apparatus of claim 97, wherein the commit instruction is further to specify clear controls to indicate a combination of read-monitored data, read-monitored data, buffered data, and metadata to be deleted at commit, and wherein the commit logic is the specified combination of read-monitored Data, read-only data, buffered data, and metadata is deleted after the transaction has been committed in response to determining that the commit condition to be specified by the commit instruction is satisfied for the transaction. Machine readable medium holding a program code which, when executed by a machine, causes the machine to perform the following operations: Finding a commit instruction for a transaction from the program code, the commit instruction specifying at least one commit error condition; Determining if the at least one commit error condition specified by the commit instruction has been captured during a pending transaction; Provide a value to indicate that the at least one commit error condition specified by the commit instruction has been detected during the pendency of the transaction, in response to determining that at least one commit error condition set by the commit Instruction is specified while pending the transaction. The machine-readable medium of claim 103, wherein the at least one commit error condition is selected from a group consisting of a loss of read-monitored data, a loss of write-monitored data, a loss of buffered data, and a loss of metadata. The machine-readable medium of claim 103, wherein providing a value to indicate that the at least one commit error condition specified by the commit instruction has been detected during the pendency of the transaction comprises loading the value into a destination register indicate that the at least one commit error condition specified by the commit instruction has been captured during the pendency of the transaction. The machine-readable medium of claim 103, wherein determining whether the at least one commit error condition specified by the commit instruction has been detected during a pending transaction includes checking a status bit in a transaction status register that is at least one commit Error condition is connected; Determining that the at least one commit error condition specified by the commit instruction has been detected during pending of the transaction in response to the status bit associated with the at least one commit error condition being set to indicate that the one or more commit errors at least one commit error condition was detected during the pendency of the transaction; Determining that the at least one commit error condition specified by the commit instruction has not been captured during a pending transaction in response to the status bit associated with the at least one commit error condition being reset; to indicate that the at least one commit error condition was not captured during the pendency of the transaction. The machine-readable medium of claim 106, further comprising committing the transaction in response to determining that the at least one commit error condition specified by the commit instruction was not captured during a pending transaction. A method, comprising: finding a commit instruction in a transaction, wherein the commit instruction comprises an opcode that specifies the commit error conditions for the transaction; Determining that no commit error conditions for the transaction specified in the op code of the commit instruction were captured during a pending transaction; and committing the transaction in response to determining that no commit error conditions have been detected for the transaction specified in the op code of the commit instruction during the pendency of the transaction. The method of claim 108, wherein the op code specifying commit error conditions for the transaction includes a first bit of the op code that, when set, specifies that a loss of read-monitored data is a commit error condition second bit of Op code, which, when set, specifies that a loss of write-monitored data is a commit error condition, a third bit of Op code, which, when set, specifies a loss of buffered Data is a commit error condition, and includes a fourth bit of op code that, when set, specifies that a loss of metadata is a commit error condition. The method of claim 109, wherein determining that transaction commit commit conditions specified in the op code of the commit instruction have been detected during a pending transaction, determining that a transaction state register read monitor bit is not set. to indicate no loss of read-monitored data in response to the first bit of the op-code being set, determining that a write monitor bit of the transaction status register is not set to indicate no loss of read-monitored data in response to the second bit of the opcode being set; determining that a buffered bit of the transaction status register is not set to indicate no loss of buffered data in response to the third bit of the opcode being set, and determining that a metadata bit of the transaction status register is not set to indicate no loss of metadata in response to the fourth bit of the opcode being set. The method of claim 109, wherein the op code further specifies erase controls, and wherein the erase control specifying op code specifies a fifth bit of the op code that, when set, specifies that read-monitored data be erased at commit of the Op code, which, when set, specifies that the read-monitored data is to be erased at commit, a seventh bit of the Op code which, when set, specifies to clear the buffered data at commit and includes an eighth bit of the opcode that, when set, specifies that metadata should be deleted on commit. The method of claim 111, wherein committing the transaction is deleting read-monitored data if the fifth bit is set, clearing read-monitored data if the sixth bit is set, clearing buffered data if the seventh bit is set, and deleting metadata if the eighth bit is set. System comprising: a memory for holding a program code including a commit instruction for a transaction; wherein the commit instruction comprises an op code specifying transaction commit error conditions and deletion control information; a processor having decode logic for decoding the op code of the commit instruction; and a commit logic for determining whether none of the error-to-commit conditions to be specified in the op-code has been captured during a pendency of the transaction, and to commit the transaction in response to the commit being committed Logic determines that the error-to-commit condition was not captured during the pendency of the transaction, where the commit logic for committing the transaction includes the commit logic having transactional information based on the erase control information that is present in the op-server. Code of the commit instruction to be deleted. The system of claim 113, wherein the error-to-commit condition is based on a combination of loss of read-monitored data, loss of write-monitored data, loss of buffered data, and loss of metadata. The system of claim 114, wherein the error-to-commit condition is selected from a group consisting of a loss of write-monitored data, a loss of read-monitored data or a loss of write-monitored data, a loss of write-monitored data, or a loss of buffered data Dates; a loss of read-only data or a loss of metadata and one Loss of read-only data, loss of read-monitored data, loss of buffered data or loss of metadata. The system of claim 113, wherein the op code for specifying erasure control information comprises the op code specifying which of read monitors, write monitors, buffered coherency, and metadata to erase at commit, and wherein the commit logic is to erase transactional information based on the deletion control information to be specified in the op code of the commit instruction, the commit logic deletes the read monitors, write monitors, buffered coherency, and metadata specified by the op code as being to be deleted. Apparatus comprising: a memory element comprising a transaction enable field (TEF), the TEF, if it holds an active value, indicating that an associated transaction is active and enabled and, if it holds an inactive value, indicating that an associated transaction is suspended; and Logic to store a state of at least the TEF in a memory structure in response to a ring level transition event and to restore the state of at least the TEF from the memory structure to the memory element in response to a return event. The apparatus of claim 117, wherein the ring level transition event comprises an event selected from a group consisting of an interrupt, an exception, a system call, a virtual machine entry, and a virtual machine exit. The apparatus of claim 117, wherein the retum event comprises an event selected from a group consisting of an interrupt return (IRET), a system return (SYSRET), a virtual machine entry (VM), and a virtual exit Machine (VM). The apparatus of claim 117, wherein the storage element comprises a flag register and wherein the TEF comprises a transaction release flag. The apparatus of claim 117, wherein the memory structure comprises a stack, wherein the logic for storing the state of at least the TEF in the stack comprises a shift logic to push the state of at least the TEF onto the stack, and wherein the logic for restoring the state is at least the TEF from the stack to the memory element comprises a pop logic to retrieve the state of at least the TEF from the stack and to restore the TEF in the memory element. System comprising: a memory for holding code which, when executed, generates a ring level transition event; and a processor that includes a register that includes a transaction enable field (TEF) to hold an active value to indicate that an associated transaction is active; and stack logic to shift a previous state of the register to a stack in response to the ring level transition event, clear the TEF to an inactive value to indicate that the associated transaction is suspended, and return the previous state of the register from the stack to the register Response to a return event. The system of claim 122, wherein the ring level transition event comprises an event selected from a group consisting of an interrupt, an exception, a system call, a virtual machine entry, and a virtual machine exit. The system of claim 122, wherein the return event comprises an event selected from a group consisting of an interrupt return (IRET), a system return (SYSRET), a virtual machine entry (VM) and an exit a virtual machine (VM). The system of claim 122, wherein the register comprises a flag register, the TEF comprises a transaction enable field, the active value comprises a high logical value of the flag, and the inactive value comprises a low logical value of the flag. A method, comprising: detecting a ring level transition event from a current ring level; Storing a previous state of a register including a transaction enable field in a memory structure; Clearing the transaction release field to indicate that an associated transaction is suspended; Detecting a return to the current ring level event; Restoring the previous state of the register from the memory structure in response to detecting the return to the current ring level event. The method of claim 126, wherein the memory structure comprises a kernel stack, wherein backing up the previous state of the register in the kernel stack comprises shifting the previous state of the register to the kernel stack and restoring the previous state of the register from the kernel. Stack includes fetching the previous state of the register from the kernel stack and restoring the previous state of the register. The method of claim 126, wherein the current ring level comprises a user ring level. The method of claim 128, wherein the ring level transition event comprises an event selected from a group consisting of an interrupt, an exception, a system call and a virtual machine entry. The method of claim 129, wherein the return to the current privilege level event comprises an event selected from a group consisting of an interrupt return (IRET), a system return (SYSRET) and a virtual machine exit (VM).

Images