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: [email protected] > To: [email protected] > 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 > >
