Content-Length: 214506 | pFad | http://github.com/rickyyx/ParNVM/issues/7

AC Customized allocator for containers · Issue #7 · rickyyx/ParNVM · GitHub
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Customized allocator for containers #7

Open
rickyyx opened this issue Jul 23, 2018 · 1 comment
Open

Customized allocator for containers #7

rickyyx opened this issue Jul 23, 2018 · 1 comment
Labels
refract Refactoring that won't be done in the near future

Comments

@rickyyx
Copy link
Owner

rickyyx commented Jul 23, 2018

Customized allocator for standard collections This will be a rather exciting feature for us if it can land.

Use case

A std lib's data structure can then obtain a memory pointer from the persistent memory allocator directly, For example, a Persistent Box PBox can be a wrapper over Box<T, A=PersistentAlloc> This will make the library much more coherent with the standard library.
In addition,PBox will have interface that allows controlled persistence methods: such as flush and persist, or even log.

pub struct PBox<T> {
   type PAlloc = PersistentAllocator 
   box_ : Box<T, PAlloc> 
}

impl<T> PBox<T> {
        pub fn persist(&self){};

        pub fn flush(&self){};
}

Even better with GAT #3 feature, transaction can be generics as well.

pub trait PWrapper {
    type Inner<T, A>
    fn persist(&self);
    fn flush(&self);
    fn log(&self); 
    ....
}


pub struct PBox {}

impl PWrapper for PBox {
   type Inner<T,A> = Box<T, A> 
   ...
}

Tracking issue

@rickyyx rickyyx added the refract Refactoring that won't be done in the near future label Jul 23, 2018
@rickyyx
Copy link
Owner Author

rickyyx commented Jul 23, 2018

Alternative AVAILABLE option:

🤙 [global_allocator] attribute

Another possible option which is to the `global_allocator' to have a persistent memory allocator altogether: https://doc.rust-lang.org/1.23.0/unstable-book/language-features/global-allocator.html

Potential Drawbacks:

  1. Only one global_allocator in the whole crate graph
  2. All memory must go through the persistent memory.

🤙 Wrap over a chunk

This is currently what the TBox did. it gets a pointer from the persistent memory allocator, and copys the data to the pointer.

Potential Drawbacks:

  1. This doesn't work with more complicated data structures that have pointer indirection, like hashmap because it does not allocate memory as chunk, but is a container over a RawTable in rust. In order to make the keys and values of the map persistent, need to be able to control the memory allocation of RawTable. (Which is not exposed by Rust...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refract Refactoring that won't be done in the near future
Projects
None yet
Development

No branches or pull requests

1 participant








ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://github.com/rickyyx/ParNVM/issues/7

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy