Pre-Grant Publication Number: 20070118712
Collaborate on the process of community review for this application. Posting will not be forwarded to the USPTO.
Flagging a post as an ACTION ITEM signals further research. Flagging SPAM and ABUSE helps to manage discussion.
Placing double brackets around a reference to a claim or prior art will create a hyperlink to the original
ex. [[claim 1]] and [[prior art 2]].
Please review the Community Code of Conduct prior to posting
Facilitator's Comment 
Action Item Show without Noise
0 days left
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 Reference 45 anticipates this claim.
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.
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.
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.
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