Hi Serkan I move the conversation back to the mailinglist :-)
See comments inline. Am 28.07.2013 20:19, schrieb serkan özal: > Hi Chris, > > In my offheap pool solution, objects are allocated outside heap > and there is no serialization/deserialization need. So you reallocate all member accesses? That's sounds very interesting! I haven't had time for taking a look at the code but I definately will! > Because original object is created on offheap and it is not > tracked by GC. Objects are allocated with Unsafe by using some > direct memory access and low level Java tricks. If you are > interested in, maybe this solution can be a subproject of > "Apache DirectMemory". DirectMemory is designed as a cache but not for allocating complete objects but maybe it could be a nice optional feature. My problem is: I found out that direct memory access for very short pieces of data are to costly so I ended up buffering 1K of bytes before firing them to the native memory location - how do you deal with this? > > In addition, I am thinking of writing byte code generation > based object mapper and serializer/deserializer. Because of it > is not reflection based there will be no performance overhead > and it will be as fast as implemented as manual. I implemented > similar thing for Spring Row Mapper > (https://github.com/serkan-ozal/spring-jdbc-roma) > This sounds pretty similar to what DM - Lightning does. At the moment the development of it is a bit fallen asleep but if you're interested count me :-) Cheers Chris > Cheers, > > -- > > Serkan > > -------------------------------------------------------------------- > > Subject: RE: Jillegal, Java OffHeap Memory Solution > From: [email protected] Date: Sun, 28 Jul 2013 20:01:01 +0200 > To: [email protected] > > Hi Serkan > > It's not yet in the trunk since some more unittests are missing > but you can have a look here > https://github.com/noctarius/directmemory/tree/buffer/directmemory-buffer > > It is Bytebuffer or Unsafe based and heavily uses partitioning > for high throughput in high concurrent environments. It's not > an automatic object mapper but offers a rich, growing buffer > interface. > > Chris > > > > "serkan özal" <[email protected]> schrieb: > > Hi Chris, I have not look at source of the new buffer backend > yet. Is it ByteBuffer based or does it user > serialization/deserialization? > > -------------------------------------------------------------------- > > Subject: Re: Jillegal, Java OffHeap Memory Solution > From: [email protected] Date: Sun, 28 Jul 2013 19:07:25 +0200 > To: [email protected] > > Hi Serrano, I saw the mail on my apache account :-) Do you had > a look at the source of the new buffer backend? > > Cheers Chris > > > > "Serkan Özal über LinkedIn" <[email protected]> schrieb: > > > > <http://www.linkedin.com> > > > > > > > > > <http://www.linkedin.com/e/-b9y35-hjohzsns-1z/fpg/63170783/eml-comm_mebc-b-photo-1to1email/?hs=false&tok=2Qwe3fMyR0I5Q1> > > > > Serkan zal > <http://www.linkedin.com/e/-b9y35-hjohzsns-1z/fpg/63170783/eml-comm_mebc-b-name-1to1email/?hs=false&tok=3vbn7MHc90I5Q1> > > Senior Software Engineer at T2 > > > > > > > > > > > > > > > > > > Hi Christoph, > > I am so sorry for my late response about Project PROPOSAL named > Jillegal. > http://mail-archives.apache.org/mod_mbox/directmemory-dev/201304.mbox/%[email protected]%3E > > > > Here is GitHub URL of my project about Off Heap Pool. > https://github.com/serkan-ozal/jillegal In addition, it > includes support for on the fly instrumentation. This is the > draft version of my project. I am currently working on > splitting it into sub-project named jillegal-core, > jillegal-offheap, jillegal-instrument, ... > > Cheers, > > -- > > Serkan ÖZAL > > > > > > > Serkan zal antworten > <http://www.linkedin.com/e/-b9y35-hjohzsns-1z/pWgfgsf2Scue-j8HCcCxwSBhrLB/mbd/I265643520_195/eml-comm_mebc-b-reply-1to1email/?hs=false&tok=2iaqc4YHx0I5Q1> > > > > > > > > > Tipp Sie können diese Nachricht direkt beantworten, indem Sie > auf den Button klicken. > > > > > > > Sie erhalten folgende E-Mails: Nachricht von LinkedIn. > Abbestellen > <https://www.linkedin.com/e/-b9y35-hjohzsns-1z/pWgfgsf2Scue-j8HCcCxwSBhrLB/uns/20011/196321560/ueouop6svj4lfr7/me%40noctarius.com/-b9y35-hjohzsns-1z/eml-comm_mebc-f-unsub/?hs=false&tok=1GfxgrDll0I5Q1> > > > > > Diese E-Mail war an Christoph Engelbert gerichtet (Java > Gameserver / Backend Developer bei Ubisoft). Erfahren Sie, > warum wir dies hinzufügen > <http://www.linkedin.com/e/-b9y35-hjohzsns-1z/plh/http://linkedin-de.custhelp.com/app/answers/detail/a_id/4788/-QUG/?hs=false&tok=2khH1HmL90I5Q1>. > > © 2013, LinkedIn Corporation. 2029 Stierlin Ct., Mountain > View, CA 94043, USA > > > > > -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit > K-9 Mail gesendet. -- ############################## # A Digital's Life # ############################## Nickname: Noctarius Location: Germany Meet me at: Ohloh: http://www.ohloh.net/accounts/noctarius G+: https://plus.google.com/114622570438626215811 Web: http://www.noctarius.com LinkedIn: http://www.linkedin.com/in/noctarius Xing: https://www.xing.com/profile/Christoph_Engelbert Masterbranch: https://masterbranch.com/christoph.engelbert XMPP/Jabber: [email protected]
