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 > >
