http://www.peertopatent.org/patent/20070118712/activity System, method and computer program product for allocating physical memory to processes. The method includes enabling a kernel to free memory in a physical memory space corresponding to arbitrarily sized memory allocations released by processes or applications in a virtual memory space. After freeing the memory, the system determines whether freed physical memory in the physical memory space spans one or more fixed size memory units (e.g., page frames). The method further includes designating a status of the one or more page frames as available for reuse; the freed page frames marked as available for reuse being available for backing a new process without requiring the kernel to delete data included in the freed memory released by the process. The kernel may organize pages marked as available for reuse in one or more local “pools” that is organized according to a variety of schemes which provide system efficiencies in that the kernel can eliminate the need for deleting of old data in those page frames without compromising data security. en-us Cooperative mechanism for efficient application memory allocation Regarding [[claim 00002]]: Again, see the paper entitled "Hoard: A Scalable Memory Allocator for Multithreaded Applications" (http://www.cs.umass.edu/~emery/hoard/asplos2000.pdf). This reference has already been associated with this patent application ([[prior art 45]]). Figure 1 & Section 3.2 shows how heaps (groups of memory blocks) are associated with threads, which in turn on UNIX systems (as noted in Section 5) are associated with applications. Therefore, [[prior art 45]] anticipates this claim. Thu, 06 Sep 2007 10:29:15 -0700 http://www.peertopatent.org/patent/20070118712/discussion Cooperative mechanism for efficient application memory allocation Regarding [[claim 00001]]: See the paper entitled "Hoard: A Scalable Memory Allocator for Multithreaded Applications" (http://www.cs.umass.edu/~emery/hoard/asplos2000.pdf). This reference has already been associated with this patent application. This was published in the ASPLOS 2000 conference (November 12-15 2000). A PDF may be found at http://www.cs.umass.edu/~emery/hoard/asplos2000.pdf Section 5: runs on computer system having operating system. Abstract: designates memory units. Figure 1 & Section 3.2: maintains per-thread heaps. Figure 2: data not deleted. Therefore, this reference anticipates this claim. Thu, 06 Sep 2007 10:18:55 -0700 http://www.peertopatent.org/patent/20070118712/discussion Cooperative mechanism for efficient application memory allocation Is there art within the collection which you see as clearly qualifying as prior art against claim 1? If so which art do you think discloses all of the features of claim 1? If not, do you have art that you wish to submit? Sun, 02 Sep 2007 07:12:29 -0700 http://www.peertopatent.org/patent/20070118712/discussion Cooperative mechanism for efficient application memory allocation [[Claim 1]], as written, seems to miss the point of the invention. Reallocating used memory without erasing it first is not, per se, new. "malloc," by definition, means "Give me memory--no need for initialization" (as opposed to "calloc," which zeroes out the memory). This is precisely what a single-process system (think Turbo C++ for DOS) would do. The point of this invention is that in a multi-process system, you ordinarily can't do what you would have done in DOS without posing a security risk. So instead, you usually make "malloc" work just like "calloc." This invention, however, finds a middle ground by splitting the "free pool" up into a global free pool and local "per-process" free pools: For the global free pool, malloc works like calloc, but if a process can be allocated memory out of its own pool, you can do malloc the old-fashioned way without worrying about security. Unfortunately, [[claim 1]] does not distinguish between different kinds of free pools, so as written, it simply reads on the old-fashioned DOS-style malloc. Tue, 14 Aug 2007 06:53:28 -0700 http://www.peertopatent.org/patent/20070118712/discussion Cooperative mechanism for efficient application memory allocation I agree with Michael. Claim 1, as written, does not disclose the whole idea of the invention. Moreover it'is quite broad and a bit unclear. Consequently, there are many documents which can be used against the novelty of claim 1. Thu, 16 Aug 2007 06:07:38 -0700 http://www.peertopatent.org/patent/20070118712/discussion Cooperative mechanism for efficient application memory allocation [[claim 00024]] I think has prior art with virtual machine technology. The Java Virtual Machine (JVM) Garbage Collector maintains free lists on a per thread basis and also VM-wide. Allocations are supplied from the per thread pool first so avoid lock contention, and failing that the thread can dip into the global (to the VM) memory pool. The step from this prior art to the claim in question seems trivial. Thu, 09 Aug 2007 08:10:17 -0700 http://www.peertopatent.org/patent/20070118712/discussion Cooperative mechanism for efficient application memory allocation We might be misinterpreting Claim 1. The body of the patent talks not about memory allocation within a single address space, but rather the operating system's handling of memory released from the application that is later needed once more. See the discussion of Figure 1B in the patent body -- the point seems to be that the operating system keeps a per-process pool of pages that were released by the corresponding process, and that thus don't need to be zeroed if given back to that same process. Mon, 18 Jun 2007 13:03:41 -0700 http://www.peertopatent.org/patent/20070118712/discussion Cooperative mechanism for efficient application memory allocation Are you suggesting that the reference cited by Ori falls outside of the scope of claim 1? Is the feature that you describe (the operating system's handling of memory released from the application that is later needed once more) a literal element of claim 1? Or of any claim? Mon, 18 Jun 2007 17:39:46 -0700 http://www.peertopatent.org/patent/20070118712/discussion Cooperative mechanism for efficient application memory allocation I am suggesting that the kneejerk reaction to the "GETMAIN" reference would be for the applicant to simply narrow the claim, possibly along the lines of claims 6 and 7. So it would be good to find a reference that anticipates the body of the patent, rather than just the wording of the claim itself. Tue, 19 Jun 2007 11:27:41 -0700 http://www.peertopatent.org/patent/20070118712/discussion Cooperative mechanism for efficient application memory allocation You make a good point Paul. Ideally, the prior art reference would accomplish both goals -discloses what is claimed and what is disclosed in the body. Do you know of a reference that discloses the feature you find lacking by the GETMAIN reference? Ori seems convinced that GETMAIN discloses claim 1. Do the other peers think that claims 1 is disclosed by GETMAIN in light of Figure 1B? Thu, 21 Jun 2007 16:47:07 -0700 http://www.peertopatent.org/patent/20070118712/discussion Cooperative mechanism for efficient application memory allocation The dependent claim 6&7 i would guess bring in this concept but not that crisply. Tue, 19 Jun 2007 07:53:47 -0700 http://www.peertopatent.org/patent/20070118712/discussion Cooperative mechanism for efficient application memory allocation I still think they're identical. In UNIX, each process has its own address space. What they're suggesting is that memory that is freed by the process and then reallocated to it again won't be zeroed out. In z/OS, an address space can be used by multipe processes. However, there is still a paging mechanism that determines which virtual address goes to which real address, and whether that real address is in primary or secondary storage (= swap). Physical memory is wiped only when transferred bet Tue, 19 Jun 2007 13:18:57 -0700 http://www.peertopatent.org/patent/20070118712/discussion Cooperative mechanism for efficient application memory allocation [[claim 1]] is something mainframes have been doing for a long time. See the description of the GETMAIN macro, which may or may not initialize memory http://mkt.neonsys.com/neon/sampdata/getmain.htm . Memory needs to be initialized at allocation because it is not wiped at deallocation. Fri, 15 Jun 2007 11:01:48 -0700 http://www.peertopatent.org/patent/20070118712/discussion Cooperative mechanism for efficient application memory allocation to make sure the relevant references get to the USPTO, and allow others to review/discuss, please UPLOAD into PRIOR ART (click "prior art/submit prior art") Fri, 15 Jun 2007 11:50:09 -0700 http://www.peertopatent.org/patent/20070118712/discussion Cooperative mechanism for efficient application memory allocation An "official IBM" version may be found at http://publib.boulder.ibm.com/infocenter/txformp/v6r0m0/topic/com.ibm.cics.te.doc/erziai00.pdf. See pages 106 and 108 of the PDF. I am uploading as Rahan requested, but is >6MB PDF... Fri, 15 Jun 2007 15:30:55 -0700 http://www.peertopatent.org/patent/20070118712/discussion