Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of pre-AIA 35 U.S.C. 112, second paragraph::
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 16 and 20 are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 16 discloses “wherein the first processor and second processor access the same memory”. The claim previously discloses “a pool of a memory.” There is no antecedent basis for “the same memory.” For the purpose of examination, it is interpreted as “the memory” or “the pool of the memory.”
Claim 20 discloses “a state data structure” and later discloses “wherein the same state structure is accessible and updated”. The same state structure” lacks proper antecedent basis because the element was disclosed as “a state data structure.” For the purpose of examination, it is interpreted as “the state data structure”.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless -
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 4, 6, 11, 12 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Volos et al. (WO 2017/142525, hereinafter Volos).
Regarding claim 1, Volos discloses
A computer implemented method of allocation of memory, comprising:
issuing an allocation operation for allocation of a region of a pool of a memory by a first process of a plurality of first processes executed in parallel on a first processor (paragraph [0011]: A memory heap (or more simply, heap) refers to a pool of memory that can be allocated for use; paragraph [0012]: Multiple processes can execute on a compute node; paragraph [0029]: A method to allocate a block of the shared memory region 106 can be a malloc() method … In response to invocation of the malloc() method, the requested memory block of the specified size is allocated for the requesting process);
sending a message to a second processor indicating the allocation of the region of the pool of the memory (paragraph [0029]: This pointer can also be communicated from the allocating process to a second process, for the second process to use the pointer in accessing the allocated memory block; paragraph [0059]: a first process allocates a block, passes a pointer to the allocated block to a second process; Note: Passing the pointer from the first process to the second process constitutes sending a message indicating the allocation of the memory region),
wherein the first processor and the second processor access the region of the pool of the memory (paragraph [0019]: the zone is accessible concurrently by multiple processes that execute on the corresponding compute nodes, such that data stored in the zone can be shared by the multiple processes);
issuing a free operation for release of the allocated region of the pool of the memory by a second process of a plurality of second processes executed in parallel on a second processor (paragraph [0059]: the second process attempts to free (or de-allocate) the allocated block after the second process is done with processing the content of the allocated block … the second process has to ask, such as by using an inter-process communication or other communication mechanism, the first (owner) process to de-allocate the block; Note: The second process asking the first process to de-allocate the block via inter-process communication constitutes the second process issuing a free operation); and
releasing, by the first processor, the allocated region of the pool of the memory as indicated in the free operation (paragraph [0021]: A zone is owned by a process if the process requested allocation of the zone and that has the ability to de-allocate (free) the zone; paragraph [0059]: the second process has to ask… the first (owner) process to de-allocate the block; Note: The first process, acting as the owner with the ability to free the zone, releases the memory block upon receiving the request/free operation from the second process),
wherein the region of the pool of the memory allocated by the first process executed on the first processor and released by the second process executed on the second processor is a same region of memory (paragraph [0059]: a first process allocates a block, passes a pointer to the allocated block to a second process, and then the second process attempts to free (or de-allocate) the allocated block… the second process has to ask … the first (owner) process to de-allocate the block; Note: The passage explicitly tracks the exact same “allocated block” being allocated by the first process, used by the second process, and subsequently requested to be released),
wherein the plurality of first processes are concurrently attempting to issue the allocation operation and the plurality of second processes are concurrently attempting to issue the free operation (paragraph [0054]: concurrently allocating, by multiple processes executing on multiple compute nodes, respective zones of a shared memory region; Note: Volos explicitly discloses multiple processes concurrently allocating memory. In a distributed system where multiple processes are concurrently allocating and sharing memory blocks, it is inherent that multiple processes will also be concurrently attempting to issue free operations as they finish processing their respective blocks).
Regarding claim 4, Volos discloses
creating an object comprising mutual exclusion lock or semaphore, the object associated with a state data structure indicating a state of allocation of the pool (paragraph [0036]: The shared heap includes (1) metadata describing which regions of the heap are allocated and which are free (for allocation); paragraph [0044]: To acquire ownership of a zone, the HEAP_OPEN method locks the zone by atomically writing the unique generation identifier. The unique generation identifier can be written into the metadata of the zone; Note: The metadata describing which regions are allocated and free constitutes the state data structure indicating the state of allocation of the pool. The atomic writing to this metadata to lock the zone constitutes an object comprising a mutual exclusion lock); and
and prior to issuing the allocation operation, locking the object (paragraph [0044]: the HEAP_OPEN method locks the zone by atomically writing the unique generation identifier; paragraph [0045]: After the shared memory 312-A has been opened by the user process 302-A, the user process 302-A can make a call 314 (as shown in Fig. 3B) to allocate a block from the shared heap 312-A; Note: Volos explicitly discloses that the locking of the zone occurs during the HEAP_OPEN method, which happens prior to the process making the call to allocate a block from the heap).
Regarding claim 6, Volos discloses
wherein the object is accessible and lockable from the first processor and the second processor (paragraph [0014]: The shared memory region 106 is directly accessible by each compute node 102-1 to 102-4; paragraph [0036]: The shared heap includes (1) metadata describing which regions of the heap are allocated and which are free; paragraph [0044]: locks the zone by atomically writing the unique generation identifier. The unique generation identifier can be written into the metadata of the zone; Note: The metadata object used for locking resides in the shared memory region, which is directly accessible by all compute nodes/processors).
Regarding claim 11, Volos discloses
wherein at least one of (i) the allocation of the region of the memory, (ii) deallocation of the region of memory, and (iii) the release of the allocation of the region of the memory, is performed on an atomic variable in a single atomic operation, wherein a private instance of the atomic variable is defined for each of the plurality of first processes and/or second processes (paragraph [0044]: To acquire ownership of a zone, the HEAP_OPEN method locks the zone by atomically writing the unique generation identifier; Note: The atomic writing of the generation identifier to acquire ownership constitutes an allocation/locking action performed in a single atomic operation).
Regarding claim 12, Volos discloses
wherein the first process that generates the allocation operation and the second process that generates the free operation are a plurality of different instances of a same set of code (paragraph [0012]: Each instance of a program code executed on a compute node can be referred to as a process; paragraph [0034]: Two user processes 302-A and 302-B are depicted, where each user process corresponds to an executed instance of application code).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made
Claims 2, 3, and 13-17 are rejected under 35 U.S.C. 103 as being unpatentable over Volos et al. (WO 2017/142525, hereinafter Volos) in view of Duluk, Jr. et al. (US 2021/0157651, hereinafter Duluk).
Regarding claim 2, Volos does not disclose wherein the first processor and the second processor are of a plurality of heterogeneous processors, wherein the first processor is of a first type of architecture and the second processor is of a second type of architecture that is different from the first type of architecture type of the first processor. Duluk discloses wherein the first processor and the second processor are of a plurality of heterogeneous processors, wherein the first processor is of a first type of architecture and the second processor is of a second type of architecture that is different from the first type of architecture type of the first processor (paragraph [0003]: A conventional central processing unit (CPU) typically includes a relatively small number of processing cores… In contrast, a conventional graphics processing unit (GPU) typically includes hundreds of processing cores; paragraph [0004]: a CPU process executing on a CPU can offload a given processing task to a GPU; paragraph [0416]: permitting different types of processors to share system resources more effectively via hardware features; Note: The CPU represents the first processor of a first architecture type, and the GPU represents the second processor of a second, different architecture type, operating together as heterogeneous processors). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the distributed memory allocation system of Volos to include heterogeneous processors having different types of architectures, as taught by Duluk. The motivation for this modification would have been to allow a process to offload specific processing tasks to specialized processors (such as a GPU) in order to have those processing tasks performed faster and more effectively (Duluk, paragraph [0004]), and to create a flexible, shared pool of processor resources across the computing environment (Duluk, paragraph [0339]).
Regarding claim 3, Volos does not disclose one of: (i) wherein the first type of architecture comprises a data-flow processing architecture, and the second type of architecture comprises a non-data-flow processing architecture, and (ii) wherein the first type of architecture comprises a non-data-flow processing architecture, and the second type of architecture comprises a data-flow processing architecture. Duluk discloses one of: (i) wherein the first type of architecture comprises a data-flow processing architecture, and the second type of architecture comprises a non-data-flow processing architecture, and (ii) wherein the first type of architecture comprises a non-data-flow processing architecture, and the second type of architecture comprises a data-flow processing architecture (paragraph [0003]: A conventional central processing unit (CPU) typically includes a relatively small number of processing cores that can execute a relatively small number of CPU processes; paragraph [0065]: Parallel processing subsystem 130 includes one or more parallel processing units (PPUs) that are configured to execute multiple operations simultaneously via a highly parallel processing architecture; paragraph [0324]: Processor 4002 may be the PPU of FIG. 2, a central processing unit (CPU), a graphics processing unit (GPU), a field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), tensor processing unit (TPU), digital signal processor (DSP), asynchronous processor, or another type of hardware accelerator or programmable logic device; Note: A traditional CPU represents a non-data-flow (i.e., control-flow) processing architecture, while a GPU, TPU, or FPGA configured for highly parallel operations on streams of data represents a data-flow processing architecture. Thus, the heterogeneous combination of a CPU and a GPU/TPU/FPGA satisfies the limitation of combining a non-data-flow architecture with a data-flow architecture). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to configure the heterogeneous processors of the combined system such that one is a non-data-flow architecture (e.g., a CPU) and the other is a data-flow architecture (e.g., a GPU or TPU), as taught by Duluk. The motivation would have been to allow a CPU process to offload a given processing task to a GPU in order to have that processing task performed faster (Duluk, paragraph [0004]).
Regarding claim 13, Volos discloses
wherein the first process comprises a first instance of the code that generates the allocation operation and the second process comprises a second instance of the code that generates the free operation (paragraph [0034]: each user process corresponds to an executed instance of application code; paragraph [0059]: a first process allocates a block… the second process attempts to free (or de-allocate) the allocated block).
Volos does not disclose wherein a single instance of the plurality of different instances is executed at any given time. Duluk discloses wherein a single instance of the plurality of different instances is executed at any given time (paragraph [0114]: Each SMC engine 700 can be configured to independently execute processing tasks associated with one processing context at any given time; paragraph [0214]: each SMC engine 700 executes one processing context for one VM at any given time; paragraph [0215]: SMC engines 700 switch from executing a particular processing context for a VM to executing a different processing context… This process is referred to herein as ‘time-slicing’; Note: Duluk’s disclosure of executing exactly one processing context at any given time on a processing engine via time-slicing satisfies the limitation of executing a single instance at any given time). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the execution of the process instances in Volos to execute a single instance at any given time on a given processing engine, as taught by Duluk. The motivation would have been to allow multiple processing contexts to share the same hardware resources efficiently by time-slicing the execution time among multiple processing contexts (Duluk, paragraphs [0214] and [0215]).
Regarding claim 14, Volos discloses
a third process of a plurality of third processors executing in parallel on a third processor, the third process uses the allocated region of memory allocated by the first process (paragraph [0013]: process 104-3 can execute on the compute node 102-2, a process 104-4 can execute on the compute node 102-3; paragraph [0019]: the zone is accessible concurrently by multiple processes that execute on the corresponding compute nodes, such that data stored in the zone can be shared by the multiple processes; Note: Volos explicitly discloses more than two compute nodes/processors and more than two processes sharing the same allocated memory zones).
Volos does not disclose wherein the third processor is of a third type of architecture that is different from a second type of architecture of the second processor and different from a first type of architecture of the first processor. Duluk discloses wherein the third processor is of a third type of architecture that is different from a second type of architecture of the second processor and different from a first type of architecture of the first processor (paragraph [0324]: Processor 4002 may be the PPU of FIG. 2, a central processing unit (CPU), a graphics processing unit (GPU), a field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), tensor processing unit (TPU), digital signal processor (DSP), asynchronous processor, or another type of hardware accelerator or programmable logic device; paragraph [0416]: permitting different types of processors to share system resources more effectively via hardware features; Note: Duluk discloses a system that can include a CPU (first architecture type), a GPU (second architecture type), and an FPGA or TPU (third architecture type), all sharing resources). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the distributed, multi-processor shared memory system of Volos to include a third processor having a third, distinct type of architecture, as taught by Duluk. The motivation for this modification would have been to provide a highly heterogeneous computing environment that creates a “pool of processor resources” (Duluk, paragraph [0339]) to allow processes to offload highly specific processing tasks to the specific type of hardware accelerator (e.g., GPU, TPU, or FPGA) best suited for that task, thereby enabling better performance, efficiency, and utilization of system resources (Duluk, paragraph [0320]).
Regarding claim 15, Volos discloses
wherein the first process allocates memory and passes access to the second process, which subsequently generates the free operation (paragraph [0059]: a first process allocates a block, passes a pointer to the allocated block to a second process, and then the second process attempts to free (or de-allocate) the allocated block).
Volos does not disclose migrating the allocated memory from the first process to the second process. Duluk discloses migrating the allocated memory from the first process to the second process (paragraph [0110]: A given processing context could include hardware settings… and/or register contents associated with threads; paragraph [0164]: dynamically migrate processing contexts 1400 between SMC engines 700; paragraph [0169]: migrates a processing context 1400 between different SMC engines 700 that reside on different PPUs 200). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the shared memory allocation method of Volos to include migrating the processing contexts and their allocated memory between processes/processors, as taught by Duluk. The motivation would have been to perform load balancing, consolidate virtual machines for better utilization, or prepare for system maintenance by moving workloads and their associated memory across different hardware resources (Duluk, paragraph [0243]: VMs may be migrated from one PPU 200 to another PPU 200 due to various reasons, including, without limitation, preparing for system maintenance, consolidating VMs on fewer PPUs 200 for better utilization or power savings).
Regarding claim 16, Volos discloses
issuing an allocation operation for allocation of a region of a pool of a memory by a first process of a plurality of first processes executed in parallel on a first processor (paragraph [0034]: Two user processes 302-A and 302-B are depicted; paragraph [0045]: the user process 302-A can make a call 314 (as shown in Fig. 3B) to allocate a block from the shared heap 312-A);
sending a message to a second processor indicating the allocation of the region of the pool of the memory (paragraph [0059]: a first process allocates a block, passes a pointer to the allocated block to a second process; Note: Passing a pointer to a second process executing on a second compute node/processor constitutes sending a message to a second processor indicating the allocation of the memory region);
issuing a free operation for release of the allocated region of the pool of the memory by a second process of a plurality of second processes executed in parallel on a second processor (paragraph [0059]: … and then the second process attempts to free (or de-allocate) the allocated block);
wherein the first processor and second processor access the same memory (paragraph [0014]: The shared memory region 106 is directly accessible by each compute node 102-1 to 102-4);
wherein the plurality of first processes are concurrently attempting to issue the allocation operation and the plurality of second processes are concurrently attempting to issue the free operation (paragraph [0019]: the zone is accessible concurrently by multiple processes that execute on the corresponding compute nodes; Note: Concurrent access to the shared memory zone by multiple processes to allocate and free blocks satisfies the limitation of concurrently attempting to issue allocation and free operations).
Volos does not explicitly disclose converting format of a code segment that deallocates memory, from a format of the first processor to a format of the second processor; and running the converted code segment by the second processor for releasing the region of the pool of the memory allocated by the first processor as indicated in the free operation.
Duluk discloses converting format of a code segment that deallocates memory, from a format of the first processor to a format of the second processor; and running the converted code segment by the second processor for releasing the region of the pool of the memory allocated by the first processor as indicated in the free operation (paragraph [0004]: offloading a processing task from a CPU to a GPU; paragraph [0335]: prior to transmitting the request to Driver 4132, Interception Layer 4130 translates the request to API calls supported by Driver 4132; Note: Translating a requested processing task (such as a memory deallocation task) from the format of the first processor (CPU) to the API/instruction format supported by the second processor’s driver (GPU) constitutes converting the format of the code segment, which is then run by the second processor. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the shared memory allocation method of Volos to include converting the format of the code segment that deallocates memory from the format of the first processor to the format of the second processor, and running the converted code segment on the second processor, as taught by Duluk. The motivation would have been to ensure that the offloaded processing task can be properly understood and executed by the target processor’s specific instruction set and drivers (Duluk, paragraph [0335]), thereby allowing a CPU process to successfully offload tasks to a GPU to have them performed faster (Duluk, paragraph [0004]) and enabling different types of processors to share system resources effectively in a pooled environment (Duluk, paragraph [0339]).
Regarding claim 17, Volos does not disclose wherein converting format comprises translating the code segment, wherein the code segment is translated when an architecture type of the first processor is different from an architecture type of a second processor. Duluk discloses wherein converting format comprises translating the code segment, wherein the code segment is translated when an architecture type of the first processor is different from an architecture type of a second processor (paragraph [0004]: offloading a processing task from a CPU to a GPU; paragraph [0335]: prior to transmitting the request to Driver 4132, Interception Layer 4130 translates the request to API calls supported by Driver 4132; Note: Translating the requested processing task into the API calls supported by the target processor’s driver when the task is offloaded from a CPU to a GPU constitutes translating the code segment when the architecture type of the first processor is different from the architecture type of the second processor). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Volos to include translating the code segment when the architecture type of the first processor is different from the architecture type of the second processor, as taught by Duluk. The motivation would have been to ensure that the offloaded or migrated processing task can be properly understood and executed by the target processor’s specific instruction set and hardware drivers (Duluk, paragraph [0335]), thereby enabling different types of processors to effectively share system resources in a heterogeneous pooled environment (Duluk, paragraph [0339]).
Claims 5 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Volos et al. (WO 2017/142525, hereinafter Volos) in view of Schreter et al. (US 2013/0117519, hereinafter Schreter).
Regarding claim 5, Volos discloses
creating a locking object and locking it prior to allocation (paragraph [0044]: the HEAP_OPEN method locks the zone by atomically writing the unique generation identifier)
However, Volos does not explicilty discloses further comprising: in response to the allocation operation, releasing the lock on the object; and prior to the issuing the free operation, locking the object. Schreter discloses a multi-processor memory management system where memory allocation and deallocation operations are explicitly performed under a lock that is acquired prior to the operation and released afterward. Specifically, Schreter discloses that an allocator “can be associated with a mutual object exclusion list (mutex), which in turn can be locked during actual memory allocation” and that “Inside locked scope… the allocation itself is executed” (paragraph [0015]). Furthermore, Schreter discloses that a memory block is “directly deallocated under the lock of this CPU-specific allocator” (paragraph [0018]). Note: Executing an allocation “inside locked scope” implicitly requires releasing the lock in response to completing the allocation operation so the thread can continue executing. Similarly, deallocating a memory block “under the lock” inherently requires locking the object prior to issuing the free/deallocation operation.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the locking mechanism of Volos to release the lock in response to the allocation operation, and to lock the object prior to issuing the free operation, as taught by Schreter. The motivation for this modification would be to protect against preemption inside of allocation code (Schreter, paragraph [0015]) and to enable more rapid memory management in a multi-CPU environment in which many concurrent threads are running (Schreter, paragraph [0009]).
Regarding claim 19, Volos discloses
issuing an allocation operation for allocation of a region of a pool of a memory by a first process of a plurality of first processes executed in parallel on a first processor (paragraph [0034]: Two user processes 302-A and 302-B are depicted; paragraph [0045]: the user process 302-A can make a call 314 (as shown in Fig. 3B) to allocate a block from the shared heap 312-A);
sending a message to a second processor indicating the allocation of the region of the pool of the memory (paragraph [0059]: a first process allocates a block, passes a pointer to the allocated block to a second process; Note: Passing a pointer to a second process executing on a second processor constitutes sending a message indicating the allocation);
wherein the first processor and the second processor access the region of the pool of the memory (paragraph [0014]: The shared memory region 106 is directly accessible by each compute node 102-1 to 102-4);
issuing a free operation for release of the allocated region of the pool of the memory by a second process of a plurality of second processes executed in parallel on a second processor (paragraph [0059]: … and then the second process attempts to free (or de-allocate) the allocated block);
wherein the plurality of first processes are concurrently attempting to issue the allocation operation and the plurality of second processes are concurrently attempting to issue the free operation (paragraph [0019]: the zone is accessible concurrently by multiple processes that execute on the corresponding compute nodes).
However, Volos does not explicitly disclose marking, by the second processor, a garbage-collection data structure with an indication of the allocated region of the pool of the memory as indicated in the free operation; and removing, by the first processor, the allocated region of the pool of the memory as indicated by the marking on the garbage-collection data structure.
Schreter discloses a multi-processor memory management system where a second processor marks a data structure for delayed deallocation by the first processor that originally allocated the memory (paragraph [0018]: In a second case, the memory block was allocated by a different CPU-specific allocator … In this situation, the memory block is not directly deallocated, but it can be put into a lock-free freelist of ‘delayed deallocate’ blocks (attached to the CPU-specific allocator 210.i…n which allocated this memory block); paragraph [0019]: The actual deallocation (‘cleaning up’) of blocks of a particular CPU-specific allocator 210.i…n can be done when… a garbage collection is explicitly requested; Note: The second processor putting the block into the lock-free freelist of delayed deallocate blocks constitutes marking a garbage-collection data structure, and the first processor performing the actual deallocation/cleaning up when garbage collection is requested constitutes removing the allocated region as indicated by the marking).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the inter-process deallocation method of Volos to include the second processor marking a garbage-collection data structure (freelist) and the first processor removing the allocated region, as taught by Schreter. The motivation for this modification would be so that no locking takes place during deallocation (Schreter, paragraph [0018]) and to enable more rapid memory management in a multi-CPU environment in which many concurrent threads are running (Schreter, paragraph [0009]).
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Volos et al. (WO 2017/142525, hereinafter Volos) in view of Gschwind et al. (US 2019/0138219, hereinafter Gschwind).
Regarding claim 7, Volos does not disclose wherein issuing the free operation for release of the allocated region of the memory comprises: locking, by the second process of the second processor, a shared garbage-collection data structure; marking, by the second process of the second processor, the shared garbage-collection data structure with an indication of the allocated region of the pool of the memory as indicated in the free operation; unlocking, by the second process of the second processor, the shared garbage-collection data structure; and removing, by the first process, the allocated region of the pool of the memory as indicated by the marking on the garbage-collection data structure. Gschwind discloses a shared garbage-collection data structure (paragraph [0077]: a unified (or global) work queue, such as depicted in FIG. 5A, may be used with affinitized garbage collection processing; Note: A global work queue accessible by multiple processors constitutes a shared garbage-collection data structure); marking, by the second process of the second processor, the shared garbage-collection data structure with an indication of the allocated region of the pool of the memory as indicated in the free operation (paragraph [0078]: code enqueue(work_item, global_GC_queue); Note: The second process enqueuing a work item representing the memory region into the global queue constitutes marking the shared garbage-collection data structure); removing, by the first process, the allocated region of the pool of the memory as indicated by the marking on the garbage-collection data structure (paragraph [0078]: code while (element = dequeue(global_GC_queue)) { ... mark_and_sweep(element); }; Note: The first process dequeuing the element and executing the mark_and_sweep garbage collection constitutes removing the allocated region as indicated by the marking). However, regarding the steps of locking, by the second process of the second processor, a shared garbage-collection data structure and unlocking, by the second process of the second processor, the shared garbage-collection data structure, IBM does not explicitly describe the low-level thread-synchronization operations used during the enqueue operation.
It is notoriously well known in the art of concurrent programming and operating system design that when a shared data structure, such as a global work queue, is accessed and modified by multiple processes executing in parallel, the data structure must be protected using thread-safe synchronization mechanisms. The standard, fundamental method to achieve this is for the modifying process to acquire a mutual exclusion lock (mutex) on the shared data structure prior to modification (i.e., locking), and to release the lock immediately after the modification is complete (i.e., unlocking).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the unified (or global) work queue of Gschwind within the system of Volos using standard locking and unlocking steps performed by the second process when enqueuing (i.e., marking) the shared garbage-collection data structure. The motivation for this modification would be that because the global work queue is accessed by multiple processors in the system’ that ‘share the garbage collection workload (Gschwind, paragraphs [0061], [0079]), a person of ordinary skill in the art would recognize the inherent need to apply standard thread-safe synchronization (mutex locking/unlocking). This standard locking prevents race conditions, memory corruption, and concurrent modification errors that occur when multiple parallel processors simultaneously attempt to read or write to a shared global queue, thereby ensuring reliable inter-process communication.
Regarding claim 8, Volos does not discloses wherein issuing the free operation for release of the allocated region of the memory comprises: creating a first private garbage-collection data structure associated with the first process; creating a second private garbage-collection data structure associated with the second process; wherein the first private garbage-collection data structure is different from the second private garbage-collection data structure, wherein the first private garbage-collection data structure is non-accessible by the second process and the second private garbage-collection data structure is non-accessible by the first process; marking, by the second process, the second private garbage-collection data structure with an indication of the allocated region of the pool of the memory as indicated in the free operation; and removing, by the first process, the allocated region of the pool of the memory as indicated by a marking on the first private garbage-collection data structure. Gschwind discloses wherein issuing the free operation for release of the allocated region of the memory comprises: creating a first private garbage-collection data structure associated with the first process; creating a second private garbage-collection data structure associated with the second process; wherein the first private garbage-collection data structure is different from the second private garbage-collection data structure (paragraph [0081]: Any number of work queues may be utilized depending upon the desired number of locality domains within the architecture. For instance, locality domains at the CPU chip level… could be utilized; Note: Utilizing a distinct work queue for each CPU chip/processor domain constitutes creating different first and second garbage-collection data structures associated with the respective first and second processes/processors), wherein the first private garbage-collection data structure is non-accessible by the second process and the second private garbage-collection data structure is non-accessible by the first process (paragraph [0081]: In this approach, the GC processing is simplified in that the processor is only working on memory in the associated (i.e., localized) work queue structure; Note: A processor “only working” on its associated localized work queue means it does not access the work queues of other processors, rendering them non-accessible to each other); marking, by the second process, the second private garbage-collection data structure with an indication of the allocated region of the pool of the memory as indicated in the free operation (paragraph [0083]: code enqueue(work_item, GC_queue[domain]); Note: The second process enqueuing a work item (indication of the memory region) into its own localized domain queue constitutes marking the second private garbage-collection data structure); and removing, by the first process, the allocated region of the pool of the memory as indicated by a marking on the first private garbage-collection data structure (paragraph [0081]: code while (element = dequeue(GC_queue[local_domain])) { mark_and_sweep(element); }; Note: The first process dequeuing an element from its own localized queue and performing the mark_and_sweep garbage collection constitutes removing the allocated region as indicated by the marking on the first private garbage-collection data structure). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the inter-process deallocation method of Volos to utilize private, non-accessible garbage-collection data structures (work queues) for each process, where each process marks and removes from its respective private structure, as taught by Gschwind. The motivation for this modification would be because the GC processing is simplified in that the processor is only working on memory in the associated (i.e., localized) work queue structure” (Gschwind, paragraph [0081]).
Claims 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Volos et al. (WO 2017/142525, hereinafter Volos).
Regarding claim 9, Volos discloses
in association with creation of the first process, creating a first private state data structure; in association with creation of the second process, creating a second private state data structure; wherein the first private state data structure is different from the second private state data structure, wherein the first private state data structure is non-accessible by the second process and the second private state data structure is non-accessible by the first process (paragraph [0034]: Each user process 302-A, 302-B has a respective private memory region 304-A, 304-B… The private memory regions 304-A, 304-B are accessible only by the respective user processes 302-A, 302-B; Note: Providing distinct private memory regions that are strictly accessible only by their respective processes constitutes creating different, non-accessible private state data structures);
in response to the allocation operation, sending a first message to the second process … (paragraph [0059]: a first process allocates a block, passes a pointer to the allocated block to a second process; Note: Passing the pointer to the allocated block constitutes sending a first message to the second process indicating the allocation)
in response to the free operation, sending a second message to the first process … (paragraph [0059]: … and then the second process attempts to free (or de-allocate) the allocated block… the second process must ask the first process to de-allocate the block; Note: Asking the first process to de-allocate the block constitutes sending a second message to the first process indicating the release);
However, Volos does not explicitly use the exact phrase that the processes are “updating… the private state data structure for indicating the allocation/release” upon sending and receiving these messages.
It is notoriously well known in the art of computer science and inter-process communication that when a process allocates memory or receives a pointer to memory from another process, it must store that pointer (and its status) in its own local, private memory (i.e., updating its private state data structure). Similarly, when a process frees memory or is asked to free memory, it must remove or nullify that pointer in its local memory to avoid “dangling pointers” or memory leaks (i.e., updating its private state data structure indicating the release).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the pointer-passing and deallocation-request messaging of Volos such that the first and second processes update their respective private memory regions (i.e., state data structures) to indicate the allocation and release of the memory block. The motivation would have been to keep accurate local track of valid memory references, thereby preventing fatal application errors such as dereferencing invalid pointers or causing memory leaks during concurrent execution.
Regarding claim 10, Volos discloses
wherein each of the first private state data structure and the second private state data structure is accessible from the first processor and the second processor (paragraph [0014]: The shared memory region 106 is directly accessible by each compute node 102-1 to 102-4; paragraph [0019]: the zone is accessible concurrently by multiple processes that execute on the corresponding compute nodes; Note: While Volos teaches that the private memory regions (state data structures) are logically isolated such that they are “accessible only by the respective user processes” (Claim 9; Volos [0034]), Volos also teaches that the underlying hardware processors (compute nodes) have direct physical access to the memory space (Claim 10). Therefore, Volos discloses that the data structures are accessible from the first and second processors).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Volos et al. (WO 2017/142525, hereinafter Volos) in view of Duluk, Jr. et al. (US 2021/0157651, hereinafter Duluk) as applied to claim 18, and further in view of Kubala et al. (US 2018/0150417, hereinafter Kubala).
Regarding claim 18, Volos does not disclose the second processor running the converted code segment. Duluk discloses the second processor running the converted code segment (paragraph [0004]: offloading a processing task from a CPU to a GPU; paragraph [0335]: prior to transmitting the request to Driver 4132, Interception Layer 4130 translates the request to API calls supported by Driver 4132; paragraph [0336]: Driver 4132 uses Processor 4140 to process the request received from Interception Layer 4130. Subsequently; Note: The target processor (Processor 4140) processing the translated API calls constitutes the second processor running the converted code segment). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the distributed memory management method of Volos such that the second processor requesting the release of the allocated memory is running a converted code segment, as taught by Duluk. The motivation for this modification would have been to allow Volos’s shared memory system to leverage heterogeneous hardware accelerators (like GPUs) for specific tasks (Duluk, paragraph [0004]), which requires translating the code into a format supported by the second processor’s architecture and drivers so that it can be successfully executed (Duluk, paragraphs [0335]-[0336]), while still utilizing Volos’s owner-managed state data structure to safely handle memory de-allocation across the different processors.
Kubala discloses wherein a second processor … accesses a state data structure managed by the first processor for updating the state data structure to indicate the release of the allocated region of the pool of the memory (paragraph [0027]: the second processing unit P-2 122 frees the buffer… a technical problem arises regarding how to update the metadata bitmap 321 of a buffer that was allocated by the first processing unit 121; paragraphs [0034]-[0035]: the processing unit P-2 122 implements the operations… identifies the bit-Y in the bitmap 321B… in the P-1 121… [and] updates the bit-Y in response to a free/remove command; Note: The metadata bitmap in the local memory of P-1 constitutes the state data structure managed by the first processor, which is directly accessed and updated by the second processor (P-2) to indicate the release of the memory. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the distributed memory management method of Volos and Duluk to include the second processor accessing and updating the first processor’s state data structure to indicate memory release, as taught by Kubala. The motivation for this modification would have been to eliminate the overhead of memory transfers and inter-process communication delays when a second processor takes over a work-item and frees a buffer (Kubala, paragraph [0036]), thereby creating a highly efficient, heterogeneous shared memory system.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Volos et al. (WO 2017/142525, hereinafter Volos) in view of Kubala et al. (US 2018/0150417, hereinafter Kubala).
Regarding claim 20, Volos discloses
issuing an allocation operation for allocation of a region of a pool of a memory by a first process of a plurality of first processes executed in parallel on a first processor (paragraph [0034]: Two user processes 302-A and 302-B are depicted; paragraph [0045]: the user process 302-A can make a call 314 (as shown in Fig. 3B) to allocate a block from the shared heap 312-A);
updating by the first processor, a state data structure for indicating the allocation (paragraph [0036]: The shared heap includes (1) metadata describing which regions of the heap are allocated and which are free; Note: The metadata describing allocated/free regions constitutes a state data structure, which is updated upon allocation)
sending a message to a second processor indicating the allocation of the region of the pool of the memory (paragraph [0059]: a first process allocates a block, passes a pointer to the allocated block to a second process; Note: Passing a pointer to a second process executing on a second compute node/processor constitutes sending a message to a second processor indicating the allocation of the memory region);
wherein the first processor and the second processor access the region of the pool of the memory (paragraph [0014]: The shared memory region 106 is directly accessible by each compute node 102-1 to 102-4)
issuing a free operation for release of the allocated region of the pool of the memory by a second process of a plurality of second processes executed in parallel on a second processor (paragraph [0059]: … and then the second process attempts to free (or de-allocate) the allocated block);
wherein the first processor and second processor access the same memory (paragraph [0014]: The shared memory region 106 is directly accessible by each compute node 102-1 to 102-4);
wherein the region of the pool of the memory allocated by the plurality of first processes executed on the first processor and released by the plurality of second processes executed on the second processor is a same region of memory (paragraph [0059]: allocating a block and the second process attempting to free the allocated block);
wherein the plurality of first processes are concurrently attempting to issue the allocation operation and the plurality of second processes are concurrently attempting to issue the free operation (paragraph [0019]: the zone is accessible concurrently by multiple processes that execute on the corresponding compute nodes).
However, Volos does not explicitly discloses releasing the allocated region of the pool of the memory by the second processor according to the free operation; and updating by the second processor, the state data structure for indicating the release, wherein the same state structure is accessible and updated by the first processor and the second processor, Instead, Volos discloses that the second process must “ask, such as by using an inter-process communication… the first (owner) process to de-allocate the block” (Volos, paragraph [0059]).
Kubala discloses releasing the allocated region of the pool of the memory by the second processor according to the free operation; and updating by the second processor, the state data structure for indicating the release, wherein the same state structure is accessible and updated by the first processor and the second processor (paragraph [0027]: a technical problem arises regarding how to update the metadata bitmap 321 of a buffer that was allocated by the first processing unit 121; paragraphs [0034]-[0035]: the processing unit P-2 122 implements the operations… identifies the bit-Y in the bitmap 321B… in the P-1 121… updates the bit-Y… atomically; Note: Kubala teaches that when a second processing unit (P-2) frees a buffer allocated by a first processing unit (P-1), the second processor directly accesses and atomically updates the metadata bitmap (state data structure) located in the first processor’s memory to indicate the buffer is free). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Volos to allow the second processor to directly release the allocated region and update the shared state data structure to indicate the release, as taught by Kubala. The motivation for this modification would have been to eliminate the computational overhead and latency associated with using inter-process communication to ask an owner process to free memory (Volos, paragraph [0059]), thereby allowing multiple processing units to assign and free buffers without the overhead of memory transfers or communication delays when a processing unit takes over the execution of a work-item from another processing unit (Kubala, paragraph [0036]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Krishnaswamy et al. (US 2013/0305024) discloses computer architectures that support transactional memory systems, specifically disclosing the execution of instructions where a retirement unit may commit and retire instructions by de-allocating registers or updating the processor state (paragraph [0023]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SISLEY N. KIM whose telephone number is (571)270-7832. The examiner can normally be reached M-F 11:30AM -7:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y. Blair can be reached on (571)270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SISLEY N KIM/Primary Examiner, Art Unit 2196 9/14/2026
