Ah, I think I see it.
In my old System V days, I think we used to call this "your process is eating up all my 'SWAP' ..." ... which of course was *precious* and the entire basis for demand-paged Virtual Memory process internals.
So when you say my SHM can grow to 137GB virtual capacity (even on a 7.7GB physical capacity) it is because you are consuming ‘SWAP’ … correct?
I see I’ve got 2 new from you in my Inbox. Probably the answers.
(Even if I’ve in fact solved this puzzle, I think I should spin again! Or buy a vowel?) :-)
From: Ben Cotton [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Saturday, March 8, 2014 7:53 PM
To: 'Peter Lawrey'
Cc: 'Ben Cotton'; 'Justin P Dildy'; 'Dmitry Gordeev'; [hidden email]; [hidden email]
Subject: RE: [infinispan-dev] Infinispan embedded off-heap cache
Ø 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 [[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: