directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Engelbert <noctar...@apache.org>
Subject Re: Jillegal, Java OffHeap Memory Solution
Date Sun, 28 Jul 2013 20:25:07 GMT
Am 28.07.2013 22:22, schrieb serkan özal:
> It is an excellent question What says the GC if it finds
> references not ending in the onheap area? :)
> I will test it.
>
Hehe, waiting for your results. Test it with massive amount of data
and allocation rate to have much dc pressure.

> --------------------------------------------------------------------
> Date: Sun, 28 Jul 2013 22:14:57 +0200
> From: noctarius@apache.org
> To: serkanozal86@hotmail.com
> Subject: Re: Jillegal, Java OffHeap Memory Solution
>
> Am 28.07.2013 21:26, schrieb serkan özal:
>
>     Hi Chris,
>
>     Comments inline.
>
>     > 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!
>
>     Yes, I allocate a big chunk of memory for a specific class
>     from offheap by using Unsafe class.
>     This chunk of memory can be defined as an object pool. After
>     pool is allocated, while I getting an instance 
>     from this pool, object header and pointer to class definition
>     is initialized for current object block and returns its address.
>     This initialization phase can be done as lazy while getting
>     instance or eager after allocating pool.
>     Advantages of this method are:
>     * Objects are allocated and layout at memory as sequencial and
>     this increases CPU cache hit rate.
>     * There is need for serialization/deserialization, so this
>     helps us to increase performance.
>
>
> What says the GC if it finds references not ending in the onheap
> area? I saw that trick at some block but that was a question the
> author could not really answer and since I had no time to test it
> on my own I left it away for now.
>
>     > 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?
>
>     As I said above, there is no need for synchronizing data to
>     between heap and native memory location. Because original
>     objects are exist on native memory outside the heap. Developer
>     deals with offheap pool objects like other objects allocated
>     from heap like with "new" keyword or with
>     "Class.newInstance()" reflection call.
>
>     > 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 :-)
>
>     Sounds great. I definitely want to work on DM - Lightning
>     project. It is great opportunity for me. 
>
>
> I'm pretty sure it would be great for the project to have more
> than one dev. You can just clone it at github or by submitting
> patches for now. I'm pretty sure we will fid a better way later on
> :-) You may have a first look at it and hopefully you have great
> ideas in how to make it better!
>
>     Cheers,
>
>     --
>
>     Serkan
>
>
   

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message