Agree with Dmitriy. We should avoid having multiple implementations of the same thing if possible. Lets put our efforts on fixing issues with PageMemory.
Sergi 2017-01-03 20:11 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > Vova, > > I would qualify the need for PageMemory as strategic for Apache Ignite. > With addition of SQL Grid component, Ignite can now also satisfy in-memory > database use cases, which are very space consuming and require a new memory > management approach. Basic distributed hash map is not going to work for > such use cases. > > Once PageMemory becomes stable and fast, I don't believe we can afford to > maintain two types of memory management in the project. It will be just too > time consuming. On top of that, the old approach will simply not be needed > anymore. > > I am OK with maintaining 2 implementations, assuming we can have a good > abstraction for the memory management.However, even in that case, we should > all weigh whether it makes sense to spend time on migrating the current > on-heap implementation to use these new memory APIs. > > D. > > On Sun, Jan 1, 2017 at 10:47 PM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > > > Dima, > > > > Performance is a serious concern, but not the main one. My point is that > > standard users working on commodity hardware and requiring only in-memory > > mode simply do not need page memory. They need distributed HashMap. We > > already have it. It is fast, it is stable, it have been tested rigorously > > for years. It does what users need. > > > > PageMemory approach targets high-end deployments which is hardly > represents > > majority of our users. Less than 10% I think. Or may be <5%, or even <1%. > > This is who may benefit from page memory. Others will benefit nothing > > except of additional layer of indirection, drop in performance, risks of > > instability. And problems with capacity planning, because it is much > harder > > to plan two memory regions properly than a single one. > > > > I talked to Alexey Goncharuk some time ago, and he told it is not a big > > deal to abstract out PageMemory. Alex, please confirm. I encourage > everyone > > to stop thinking of dropping "old" before you have built "new" and > > confirmed that it is better. > > > > Let's ensure that new approach is well-abstracted, add it to 2.0, let it > > maturate for 1-2 years, and then think of dropping current approach in > 3.0. > > This sounds much better to me. > > > > > > On Sun, Jan 1, 2017 at 10:42 AM, Denis Magda <dma...@apache.org> wrote: > > > > > Sorry, just recalled that Unsafe is not JNI based. However, my previous > > > point of view still remains the same. > > > > > > > On Dec 31, 2016, at 11:39 PM, Denis Magda <dma...@apache.org> wrote: > > > > > > > > JNI-based Unsafe that also brings performance hit > > > > > > — > > > Denis > > > > > > > > >
