Here we need to define what’s meant under *fast enough*. Java is unmanageable in terms of memory and it’s unlikely that any custom memory manageable solution like the PageMemory will outperform it ever. Simply because the Java heap will still be an intermediate layer between an application and the PageMemory passing objects back and forth. Also the PageMemory manages data, as I understand, with JNI-based Unsafe that also brings performance hit, etc.
So, personally I share Vladimir’s point of view and would not discontinue the on-heap implementation. What I can’t is why the PageMemory so slower than the current *off*-heap based implementation? The latter has comparable performance with the on-heap impl and it’s not twice times slower for sure. Alex G., could you elaborate on this? — Denis > On Dec 31, 2016, at 8:29 AM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > > On Sat, Dec 31, 2016 at 7:07 AM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > > So my main concern is *what about current heap mode*? It must stay alive. >> Page-memory approach should be abstracted out and implemented in addition >> to current heap-approach, not instead of it. Have high-end machine and >> suffer from GC? Pick offheap mode. Have a commodity machine? Old good heap >> mode is your choice. >> > > Vova, disagree. I don't see a reason to maintain on-heap implementation, if > we can make the off-heap one work fast enough. Remember, this is the 1st > draft only. Once we optimize it, it will get a lot faster.
