Ø How you might wonder?
You got that right! Let me study this … Truth is my first, second nor third reads set off the “light bulb” in my head.
Ø This works because even though I only have 7.7 GB after the OS, I can create a SHM of 137 GB because this only uses 21 MB of actual disk space/memory.
Still wondering ‘How?’, Peter. LOL. I’m mean I’m sure it is true …. But I have no insight to how it is true.
Again, Let me study the code for this one.
From: Peter Lawrey [mailto:[hidden email]]
Sent: Saturday, March 8, 2014 7:41 PM
To: [hidden email]
Cc: Ben Cotton; Justin P Dildy; Dmitry Gordeev; [hidden email]
Subject: Re: [infinispan-dev] Infinispan embedded off-heap cache
You might find this example interesting.
While SHM is not expandable, this is not as much of a problem as it might seem. SHM uses virtual memory and leave the OS to map it to real memory as required. This means you can over allocate extents with a very low cost on Linux.
In the example above I create extents for an SHM which much larger than main memory and it takes a fraction of a second to do this. How you might wonder? It prints
System memory= 7.7 GB, Size of map is 137.5 GB, disk used= 21MB
This works because even though I only have 7.7 GB after the OS, I can create a SHM of 137 GB because this only uses 21 MB of actual disk space/memory.
You can freely over allocate the size on the basis that the system only uses the resources it needs.
On 8 March 2014 04:06, Ben Cotton <[hidden email]> wrote:
Thanks Peter. The plan is for Dmitry and I to at first extend VanillaSharedHashMap and groom it into an ISPN7 join via their DataContainer API bridge.
That ExtendedVSHM will be morphed into a fully inter-operable JCACHE operand will
- initially be brokered by the ISPN 7 config (JSR107 <----> VSHMExtendedDataContainer <----> VSHM)
- eventually, possibly, be rendered with ExtendedVSHM directly implementing javax.cache.Cache (in addititon to DataContainer)
On 03/07/2014 11:43 AM, Peter Lawrey wrote: