Thank you Galder, I will talk with Tristan, regards.. On 10 January 2013 11:32, Galder Zamarreño <galder(a)redhat.com&gt; wrote:

Yavuz, shall we catch up on this tomorrow on IRC? irc://irc.freenode.org/infinispan On 10 Jan 2013, at 12:04, Manik Surtani wrote: Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org)

Hi Yavuz, Tristan, et. al. I am extremely interested to learn if anything materialized from the https://issues.jboss.org/browse/ISPN-871 effort. If nothing materialized, I would like to take a stab at doing this, specifically by doing the following: 0. Use Peter Lawrey's openHFT HugeCollections project (https://github.com/OpenHFT/HugeCollections) as the off-Heap Cache implementation provider. 1. Start with Peter's net.openhft.collections.HugeHashMap<K,V> implementation Class as a highly optimized off-Heap basis and a potential Cache<K,V> candidate 2. Confirm from ISPN-dev team that the ambition to use org.infinispan.container.DataContainer interface as a bridge to provide potential non-ISPN built CacheImpl<K,V> candidates is sound/complete (and intended) 3. Modify HugheHashMap<K,V> so that it explicitly implements org.infinispan.container.DataContainer interface. 4. Confirm that modified my net.openhft.collections..HugeHashMap<K,V> can interoperate with the full ISPN 5.3/6.x APIs, exactly as if it were a default ISPN-provided org.infinispan.CacheImpl<K,V> Could any one from the ISPN-dev team comment if this ambition has merit and a liklihood of "working" as outlined above (effectively resuming the work started at https://issues.jboss.org/browse/ISPN-871)? Is there any in-place ISPN documentation that advocates the use of DataContainer for taking on this type of effort? Thanks, Ben -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infi... Sent from the Infinispan Developer List mailing list archive at Nabble.com.

Hi, another option is to use the off-heap allocator from Netty project. It's just an allocator, so it would require extra work when compared with HugeCollections. I tried this approach approach with Hazelcast: https://github.com/jerrinot/hugecast Cheers, Jaromir On Wed, Jan 15, 2014 at 11:44 AM, Tristan Tarrant <ttarrant(a)redhat.com&gt;wrote: -- “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” Antoine de Saint Exupéry

Reading that, it isn't clear what I meant: A Java port of jemalloc (which the Netty off-heap allocator is) is exactly what I had in mind. Tristan On 01/15/2014 01:02 PM, Tristan Tarrant wrote:

FYI. Some results from a Test that Peter just wrote wrt to comparing Netty allocater vs. OpenHFT's direct invoke of Unsafe malloc/free. Indeed, Netty's use of a PooledHeap approach does result in a 100% speed improvement (wrt to allocation events). However, OpenHFT has a huge advantage wrt its underlying BytesMarshallable capability to blazing serialize/deserialize 'back to the heap!' value object COPY transports (that could then be viewed as NIO-operable ByteBuffer). Interesting. Moral of the story? Both Netty and OpenHFT should likely both be significant contributors to this ambition to deliver a compelling off-heap Cache<K,V> capability to ISPN. ---peter.lawrey(a)higherfrequencytrading.com wrote: -------------------- The first thing I noticed is that allocating using the Pooled Heap is twice as fast on my machine, Netty creating/freeing 256 bytes is 11 million vs DirectStore 5.6 million per second. Note: HHM avoids doing this at all and I suspect this difference is not important for HHM. I re-wrote one of their tests as a performance test. Given they don't appear to performance test their object serialization is a worry ;) but it also means I probably didn't do it as optimally as it could be. In the following test I serialize and deserialize an object with four fields String, int, double, Enum using the same writeExternalizable/readExternalizble code. Netty: Serialization/Deserialization latency: 327,499 us avg Netty: Serialization/Deserialization latency: 97,419 us avg Netty: Serialization/Deserialization latency: 54,232 us avg Netty: Serialization/Deserialization latency: 58,950 us avg Netty: Serialization/Deserialization latency: 53,177 us avg Netty: Serialization/Deserialization latency: 53,189 us avg Netty: Serialization/Deserialization latency: 53,672 us avg Netty: Serialization/Deserialization latency: 52,871 us avg Netty: Serialization/Deserialization latency: 52,211 us avg Netty: Serialization/Deserialization latency: 51,924 us avg DirectStore: Externalizable latency: 6,899 us avg DirectStore: Externalizable latency: 825 us avg DirectStore: Externalizable latency: 496 us avg DirectStore: Externalizable latency: 494 us avg DirectStore: Externalizable latency: 385 us avg DirectStore: Externalizable latency: 212 us avg DirectStore: Externalizable latency: 201 us avg DirectStore: Externalizable latency: 197 us avg DirectStore: Externalizable latency: 199 us avg DirectStore: Externalizable latency: 203 us avg The code is /* * Copyright 2012 The Netty Project * * The Netty Project licenses this file to you under the Apache License, * version 2.0 (the "License"); you may not use this file except in compliance * with the License. You may obtain a copy of the License at: * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the * License for the specific language governing permissions and limitations * under the License. */ package io.netty.handler.codec.marshalling; import io.netty.buffer.ByteBuf; import io.netty.channel.ChannelHandler; import io.netty.channel.embedded.EmbeddedChannel; import net.openhft.lang.io.Bytes; import net.openhft.lang.io.DirectBytes; import net.openhft.lang.io.DirectStore; import net.openhft.lang.io.serialization.BytesMarshallable; import org.jboss.marshalling.MarshallerFactory; import org.jboss.marshalling.Marshalling; import org.jboss.marshalling.MarshallingConfiguration; import org.jboss.marshalling.Unmarshaller; import org.jetbrains.annotations.NotNull; import org.junit.Test; import java.io.Externalizable; import java.io.IOException; import java.io.ObjectInput; import java.io.ObjectOutput; import java.lang.annotation.RetentionPolicy; import static org.junit.Assert.assertEquals; import static org.junit.Assert.assertNull; import static org.junit.Assert.assertTrue; public class SerialMarshallingEncoderTest extends SerialCompatibleMarshallingEncoderTest { @Override protected ByteBuf truncate(ByteBuf buf) { buf.readInt(); return buf; } @Override protected ChannelHandler createEncoder() { return new MarshallingEncoder(createProvider()); } @Test public void testMarshallingPerf() throws Exception { MyData testObject = new MyData("Hello World", 1, 2.0, RetentionPolicy.RUNTIME); final MarshallerFactory marshallerFactory = createMarshallerFactory(); final MarshallingConfiguration configuration = createMarshallingConfig(); Unmarshaller unmarshaller = marshallerFactory.createUnmarshaller(configuration); for (int t = 0; t < 10; t++) { long start = System.nanoTime(); int RUNS = 10000; for (int i = 0; i < RUNS; i++) { EmbeddedChannel ch = new EmbeddedChannel(createEncoder()); ch.writeOutbound(testObject); assertTrue(ch.finish()); ByteBuf buffer = ch.readOutbound(); unmarshaller.start(Marshalling.createByteInput(truncate(buffer).nioBuffer())); MyData read = (MyData) unmarshaller.readObject(); assertEquals(testObject, read); assertEquals(-1, unmarshaller.read()); assertNull(ch.readOutbound()); buffer.release(); } long average = (System.nanoTime() - start) / RUNS; System.out.printf("Netty: Serialization/Deserialization latency: %,d us avg%n", average); } unmarshaller.finish(); unmarshaller.close(); } @Test public void testMarshallingPerfDirectStore() throws Exception { MyData testObject = new MyData("Hello World", 1, 2.0, RetentionPolicy.RUNTIME); MyData testObject2 = new MyData("test", 12, 222.0, RetentionPolicy.CLASS); DirectStore ds = DirectStore.allocateLazy(256); DirectBytes db = ds.createSlice(); for (int t = 0; t < 10; t++) { long start = System.nanoTime(); int RUNS = 10000; for (int i = 0; i < RUNS; i++) { db.reset(); testObject.writeExternal(db); long position = db.position(); db.reset(); testObject2.readExternal(db); assertEquals(testObject, testObject2); assertEquals(position, db.position()); } long average = (System.nanoTime() - start) / RUNS; System.out.printf("DirectStore: Externalizable latency: %,d us avg%n", average); } ds.free(); } public static class MyData implements Externalizable { String text; int value; double number; RetentionPolicy policy; public MyData() { } public MyData(String text, int value, double number, RetentionPolicy policy) { this.text = text; this.value = value; this.number = number; this.policy = policy; } @Override public void writeExternal(ObjectOutput out) throws IOException { out.writeUTF(text); out.writeInt(value); out.writeDouble(number); out.writeUTF(policy.name()); } @Override public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException { text = in.readUTF(); value = in.readInt(); number = in.readDouble(); policy = RetentionPolicy.valueOf(in.readUTF()); } @Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; MyData myData = (MyData) o; if (Double.compare(myData.number, number) != 0) return false; if (value != myData.value) return false; if (policy != myData.policy) return false; if (text != null ? !text.equals(myData.text) : myData.text != null) return false; return true; } } } On 15 January 2014 16:59, Peter Lawrey <peter.lawrey(a)gmail.com&gt; wrote: Good question. I suspect there is a bunch of things it is not doing, but I will investigate. On 15 January 2014 16:50, Ben Cotton <bendcotton(a)gmail.com&gt; wrote: Simplifying my question, is there something that Netty's jemalloc() like off-heap allocation management does that is somehow different (advantageous?) when compared with straightforward usage of Unsafe malloc/free ? -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infi... Sent from the Infinispan Developer List mailing list archive at Nabble.com.

I thought this JEP was (sort of) relevant to this discussion: http://openjdk.java.net/jeps/189 Cheers, Jaromir On Thu, Jan 16, 2014 at 10:10 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt;wrote: -- “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” Antoine de Saint Exupéry

Hi everybody. We are getting started with our POC design/build of this post's ambition. Currently at an ISPN build-from-scratch newbie roadblock. I know I should be patient, but if any of you have time could one of you hook me up with the official "How 2 Fork/Clone/Extend/Build your own ISPN Master from GIT " wiki link? ROADBLOCK details here --> https://community.jboss.org/thread/236848 Thx, Ben -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infi... Sent from the Infinispan Developer List mailing list archive at Nabble.com.

FYI, we've got all the "can we build thisfrom w/in JPM.com?" plumbing concerns 100% resolved. So now it is "Heap No! Heap No! It's off to work we go ...." https://github.com/Cotton-Ben/infinispan Will share musings/fears/roadblocks/triumphs/etc here and at https://issues.jboss.org/browse/ISPN-871 Thx, Ben -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infi... Sent from the Infinispan Developer List mailing list archive at Nabble.com.

Quick Update: It is my understandng that Peter Lawrey will make available an OpenHFT HC Alpha Release in Maven Central next weekend. At that time, Dmitry Gordeev and I will take the OpenHFT dependency tag and proceed to build a branch of Red Hat's ISPN 7 that will treat net.openhft.collections.SharedHashMap as a Red Hat Infinispan 7 default impl of a fully JSR-107 interoperable off-heap javax.cache.Cache ... A diagram of this build effort can be found here: https://raw.github.com/Cotton-Ben/OpenHFT/master/doc/AdaptingOpenHFT-SHM-... ... The Red Hat view of his effort will be tracked here: https://issues.jboss.org/browse/ISPN-871 ... The code that defines the Impl will be here https://github.com/Cotton-Ben/infinispan ... -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infi... Sent from the Infinispan Developer List mailing list archive at Nabble.com.

I imagine that you plan to contribute this back to ISPN? (which would be awesome, btw) How do you plan to organize your source code, btw? I think an new mvn module under infinispan, at the same level with core, would be a good idea, as we try to keep core's dependencies at a min. On Mar 6, 2014, at 6:24 PM, cotton-ben <ben.cotton(a)ALUMNI.RUTGERS.EDU&gt; wrote: Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org)

Hi Ben, In the diagram provided, the CacheImpl (your class) extends both from javax.cache.Cache and org.infinispan.container.DataContainer. The Cache and DataContainer interfaces are quite different and I anticipate an single class implementing both to be hard to follow and potentially not very efficient. Another way to do it is to have CacheImpl implement the DataContainer only, and then configure Infinispan's JCache implementation to use that custom DataContainer. On Mar 3, 2014, at 3:46 PM, cotton-ben <ben.cotton(a)ALUMNI.RUTGERS.EDU&gt; wrote: Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org)

Thank you for this insight Mircea ... Ultimately ... I want the OpenHFT SHM off-heap operand to behave *exactly* like a JCACHE ... Amenable to being soundly/completely operated upon by any/all parts of ISPN7's Impl of the JSR-107 API . Musing openly: Won't that (eventually) necessitate me physically implementing javax.cache.Cache ? /> Another way to do it is to have CacheImpl implement the DataContainer only, and then configure Infinispan's JCache implementation to use that custom DataContainer. / I see what you mean. OK, for sure, this sounds much simpler than what I have put on my initial TODO list. Question: Will doing it this way in any manner suggest that my JSR-107 specific operators are being transitively "brokered" by the ISPN config onto my OpenHFT SHM operand? If possible, I want everything to be direct -- no API bridge. Thanks again, Mircea. -Ben and Dmitry -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infi... Sent from the Infinispan Developer List mailing list archive at Nabble.com.

We have established the following at my ISPN 7 fork ( https://github.com/Cotton-Ben/infinispan ): 1. Created a new [jcache-off-heap] module and bound it to master ISPN 7 pom.xml 2. Within [jcache-off-heap] created a pom.xml that successfully joins OpenHFT 3.0a and ISPN 7.0.0 APIs. 3. Created an org.infinispan.jcache.JCacheOffHeapImpl place-holder Class that both extends net.openhft.collections.VanillaSharedHashMap and implements org.infinispan.container.DataContainer 4. Created an org.infinispan.jcache.JCacheOffHeapImplTest place-holder that will drive the tests to demonstrate that we have rendered a sound/complete [3]. 5. Confirmed that we can build [3][4] from the ISPN 7 master maven invoke. Before proceeding further, Dmitry and I need to establish from Mircea and RedHat that this module, in this form, will adapt (without concern) into the existing RedHat ISPN 7 root build environment. Ben D. Cotton III J.P.Morgan Liquidity Risk Technology 277 Park Ave Desk 08-GG64 New York, NY 10172-0003 212.622.5010 ben.cotton(a)jpmorgan.com -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infi... Sent from the Infinispan Developer List mailing list archive at Nabble.com.

/> Ben, at this stage you already have an JCache implementation backed by the DataContainer, by using the JCache implementation provided by ISPN an configuring Infinispan with the new custom data container. / *Thanks Mircea. We now "see it" and are proceeding accordingly. We have removed all ambition to directly implement JCACHE (in any form) from our Fork. (see newly documented goals at https://github.com/Cotton-Ben/infinispan <https://github.com/Cotton-Ben/infinispan> ) We have also simply re-named the new module [off-heap]. Thanks for your support. We are in full gear to adapt/test/contribute this Fork. Stay tuned.* /> configuring Infinispan with the new custom data container / *Looking forward to learning from you guys exactly how to do this! Thanks!* -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infi... Sent from the Infinispan Developer List mailing list archive at Nabble.com.

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:bendcotton@gmail.com] On Behalf Of ben.cotton(a)alumni.rutgers.edu Sent: Saturday, March 8, 2014 7:53 PM To: 'Peter Lawrey' Cc: 'Ben Cotton'; 'Justin P Dildy'; 'Dmitry Gordeev'; ml-node+s980875n4028967h94(a)n3.nabble.com; ben.cotton(a)alumni.rutgers.edu 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 [mailto:peter.lawrey@higherfrequencytrading.com] Sent: Saturday, March 8, 2014 7:41 PM To: ben.cotton(a)alumni.rutgers.edu Cc: Ben Cotton; Justin P Dildy; Dmitry Gordeev; ml-node+s980875n4028967h94(a)n3.nabble.com 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. https://github.com/OpenHFT/HugeCollections/blob/master/collections/src/test/ java/net/openhft/collections/OSResizesMain.java 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 <ben.cotton(a)alumni.rutgers.edu&gt; 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: In the medium term I would see SHM supporting a DataContainer. If a Cache were supported I would do it as a layered class so those who don't need the functionality of a Cache don't incur an overhead. On 8 Mar 2014 03:35, "Ben Cotton" <ben.cotton(a)alumni.rutgers.edu&gt; wrote: Thank you for this insight Mircea ... Ultimately ... I want the OpenHFT SHM off-heap operand to behave *exactly* like a JCACHE ... Amenable to being soundly/completely operated upon by any/all parts of ISPN7's Impl of the JSR-107 API . Musing openly: Won't that (eventually) necessitate me physically implementing javax.cache.Cache ? only, and then configure Infinispan's JCache implementation to use that custom DataContainer. I see what you mean. OK, for sure, this sounds much simpler than what I have put on my initial TODO list. Question: Will doing it this way in any manner suggest that my JSR-107 specific operators are being transitively "brokered" by the ISPN config onto my OpenHFT SHM operand? If possible, I want everything to be direct -- no API bridge. Thanks again, Mircea. -Ben and Dmitry Sent from my iPhone On 03/07/2014 09:45 AM, Mircea Markus-2 [via Infinispan Developer List] wrote: Hi Ben, In the diagram provided, the CacheImpl (your class) extends both from javax.cache.Cache and org.infinispan.container.DataContainer. The Cache and DataContainer interfaces are quite different and I anticipate an single class implementing both to be hard to follow and potentially not very efficient. Another way to do it is to have CacheImpl implement the DataContainer only, and then configure Infinispan's JCache implementation to use that custom DataContainer. On Mar 3, 2014, at 3:46 PM, cotton-ben <[hidden email] <http://user/SendEmail.jtp?type=node&node=4028967&i=0> > wrote: of a off-heap https://raw.github.com/Cotton-Ben/OpenHFT/master/doc/AdaptingOpenHFT-SHM-as- JCACHE-Impl.jpg http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infinis pan-embedded-off-heap-cache-tp4026102p4028931.html Nabble.com. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list [hidden email] <http://user/SendEmail.jtp?type=node&node=4028967&i=2> https://lists.jboss.org/mailman/listinfo/infinispan-dev _____ If you reply to this email, your message will be added to the discussion below: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infinis pan-embedded-off-heap-cache-tp4026102p4028967.html To start a new topic under Infinispan Developer List, email ml-node+s980875n2085493h0(a)n3.nabble.com To unsubscribe from [infinispan-dev] Infinispan embedded off-heap cache, click here <http://infinispan-developer-list.980875.n3.nabble.com/template/NamlServlet. jtp?macro=unsubscribe_by_code&node=4026102&code=YmVuLmNvdHRvbkBBTFVNTkkuUlVU R0VSUy5FRFV8NDAyNjEwMnwtMTU2ODA0NTc1OA==> . <http://infinispan-developer-list.980875.n3.nabble.com/template/NamlServlet. jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.nam l.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble. view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aem ail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3A email.naml> NAML -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infi... Sent from the Infinispan Developer List mailing list archive at Nabble.com.

upgraded to OpenHFT 3.0b, stubbed out JCacheOffHeapImpl with 'super.XXX()' invokes onto Peter's VanillaSharedHashMap impl. TODO: morph get()/peek()/remove() to return RedHat ICE TODO: confirm from Mircea/RedHat that the [jcache-off-heap] build module is appropriate ISPN 7 join point. Cotton-Ben/infinispan@d9f408d <https://github.com/Cotton-Ben/infinispan/commit/d9f408db051499b5d80dbc966... -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infi... Sent from the Infinispan Developer List mailing list archive at Nabble.com.

Minor update: Dmitry and I have established an initital bridge connecting OpenHFT's off heap SharedHashMap to an ISPN7 DataContainer API view. https://github.com/Cotton-Ben/infinispan (details found in [offheap] module) TODO: tests. -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infi... Sent from the Infinispan Developer List mailing list archive at Nabble.com.