ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: [DISCUSS] Ignite memory -> virtual memory
Date Fri, 02 Jun 2017 16:51:11 GMT
Agreed then. Let's update the javadoc and documentation.

On Thu, Jun 1, 2017 at 1:33 AM, Alexey Goncharuk <alexey.goncharuk@gmail.com
> wrote:

> I am fine with this javadoc change as long as there is no confusion between
> Ignite page memory buffers and the OS Virtual Memory concept.
>
> 2017-06-01 2:07 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:
>
> > Igniters,
> >
> > With the newly donated persistence functionality in Ignite, I have been
> > struggling a bit on how to fit the notion of persistence into the current
> > Ignite interfaces, that are almost completely memory oriented. For
> example,
> > abstractions like MemoryConfiguration or MemoryMetrics will now have to
> > include the persistence context, given that pages will be seamlessly
> mapped
> > to disk, whenever the memory fills up (e.g. providing the number of pages
> > on disk on MemoryMetrics interface).
> >
> > After looking around, I have noticed that our architecture is
> increasingly
> > beginning to look like the Virtual Memory concept in operating systems
> [1],
> > if you consider Ignite off-heap memory to be the physical memory, and
> disk
> > to be the secondary memory space. Just like virtual memory, our
> > architecture is based on memory pages and memory segments. The total set
> of
> > all pages constitutes the total virtual memory space.
> >
> > If we document our memory interfaces as virtual memory, then we won't
> have
> > to do any renaming and can comfortably add disk-based methods to these
> > interfaces, as it becomes consistent with the virtual memory concept.
> >
> > Thoughts?
> >
> > [1] - https://en.wikipedia.org/wiki/Virtual_memory
> >
>

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