The specification discloses a heap memory management system in which software streams remove and replace blocks of heap memory from the heap pile, managed in a linked list fashion, in a last-in/first-out fashion at the top of the list. A hardware device returns blocks of heap memory, and this return is to the end or bottom of the linked list. In this way, software streams may remove and return blocks of heap memory simultaneously with hardware devices returning blocks of heap memory.
The present invention is directed to a method and system for minimizing memory access latency during realtime processing. The method includes a mechanism for marking information that will be accessed during realtime processing. The marked information may include code, data, heaps, stacks, as well as other information. The method includes support for locking down all of the marked information so that it is present in a computing machine's physical memory so that no page faults will be incurred during realtime processing. The method additionally enables realtime processing code to allocate and free memory in a non-blocking manner. It does so by enabling the creation of heaps for use during realtime processing, wherein each heap supports allocating and freeing memory in a non-blocking fashion. Each heap tracks freed memory blocks using individual non-blocking tracking lists for each memory block size supported by that heap. If a memory allocation request to a heap can be satisfied by using a memory block available on one of the lists of freed memory blocks, the method includes allocating the available memory block by popping the memory block from the tracking list. If no freed memory blocks of the desired size are available, then the method includes traversing a separate set of source memory blocks for that heap, and making the allocation in a non-blocking fashion from one of those blocks.
Memory segments are allocated for a classloader to store class information, such as by selecting an allocation approach based on classloader type. In a first approach, in response to each request, a segment having a fixed size is allocated. In a second approach, in response to a first request, a first segment having a size equal to an amount of memory needed to store information related to the request is allocated. In response to a second request, a second segment having a second size is allocated, and in response to a third request, a third segment having a third size greater than the second size is allocated. In a third approach, in response to the first request, a first segment having a first size is allocated. In response to a second request, a second segment having a second size greater than the first size is allocated.
A shared memory technology where shared objects can be used by any of multiple users, applications, or program sessions with programming language support during development and at runtime. The developer can declare shared memory behaviors at design time to cause one or more area classes to be generated for use at runtime. A shared objects memory is managed by the runtime environment. Content is stored at runtime in an area instance of an area class. Class methods to be generated that include methods for attaching and detaching a running session to and from an area instance, and for detaching a session from a change request on an area instance with a commit or a rollback. The runtime environment manages locks for area instances. There are programming language constructs for creating area instances and for creating data objects of arbitrary data type within area instances.
We propose a new form of software transactional memory (STM) designed to support dynamic-sized data structures, and we describe a novel non-blocking implementation. The non-blocking property we consider is obstruction-freedom. Obstruction-freedom is weaker than lock-freedom; as a result, it admits substantially simpler and more efficient implementations. An interesting feature of our obstruction-free STM implementation is its ability to use of modular contention managers to ensure progress in practice.
The disclosed embodiments relate to a communication device for use in a node of a system having a plurality of nodes. Each of the plurality of nodes may include network interface controllers ("NICs") and each of the NICs may have an atomic operation logic device therewith. The atomic operation logic may receive from a requester a packet that contains a request to perform an atomic operation. Then the atomic operation logic may determine that the atomic operation is being requested from the information within the packet. The atomic operation logic may also respond to the requester to indicate whether the atomic operation has been performed.
