Mailing-List: contact dev-help@directmemory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@directmemory.apache.org
Message-ID: <51F5635E.3050808@apache.org>
Date: Sun, 28 Jul 2013 20:30:54 +0200
From: Christoph Engelbert <noctarius@apache.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: =?windows-1254?Q?serkan_=F6zal?= <serkanozal86@hotmail.com>,
 dev@directmemory.apache.org
Subject: Re: Jillegal, Java OffHeap Memory Solution
References: 
 <1335534360.7434092.1375031065824.JavaMail.app@ela4-app3202.prod>,<84f97524-fd6f-4a7c-acc2-1e83ca8025d0@email.android.com>
 <DUB120-W1091A6A2DDE6140237DABDD9540@phx.gbl>,<bd67b4dc-f544-4b3a-aeb9-88502696466e@email.android.com>
 <DUB120-W52ADD43BE6E7C20DCF750CD9540@phx.gbl>
In-Reply-To: <DUB120-W52ADD43BE6E7C20DCF750CD9540@phx.gbl>
Content-Type: text/plain; charset=windows-1254
Content-Transfer-Encoding: 8bit

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: me@noctarius.com Date: Sun, 28 Jul 2013 20:01:01 +0200 
> To: serkanozal86@hotmail.com
> 
> 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" <serkanozal86@hotmail.com> 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: me@noctarius.com Date: Sun, 28 Jul 2013 19:07:25 +0200 
> To: serkanozal86@hotmail.com
> 
> 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" <member@linkedin.com> 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/%3C517C24CA.2090509@apache.org%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: noctarius@jabber.ccc.de