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

Port RECIPE data structures to libpmem #5

Open
vijay03 opened this issue Oct 31, 2019 · 2 comments · May be fixed by #14
Open

Port RECIPE data structures to libpmem #5

vijay03 opened this issue Oct 31, 2019 · 2 comments · May be fixed by #14
Assignees
Labels
help wanted Extra attention is needed

Comments

@vijay03
Copy link
Member

vijay03 commented Oct 31, 2019

This issue involves porting the RECIPE data structures to work on libpmem. For example, converting P-CLHT to a form that uses the libpmem pointers and allocation routines.

@vijay03 vijay03 added the help wanted Extra attention is needed label Oct 31, 2019
@pyrito pyrito mentioned this issue Mar 29, 2020
4 tasks
@onceltl
Copy link

onceltl commented Jul 20, 2020

I found that P-Masstree in the PMDK branch still used volatile linked lists to maintain the DeletionList. Will this cause memory leaks after system crash?

@SeKwonLee
Copy link
Member

SeKwonLee commented Jul 20, 2020

Hi @onceltl,

Yes, the current implementation of P-Masstree in the PMDK branch still can cause persistent memory leaks after a system crash. RECIPE conversions are specifically restricted to the consistency guarantee of the internal updates of the indexes, so they do not provide a specific solution for persistent memory leaks. However, in my opinion (also described in our publication), I don't think the solution for persistent memory leaks should not be provided by the level of index structures (or should not be index-structure specific). There have been prior studies using post-crash garbage collection to solve persistent memory leaks (Please check the limitation section in README.md in the master branch). We are planning to add a supplementary implementation of post-crash garbage collection to resolve persistent memory leaks when I have time.

Thanks,

@SeKwonLee SeKwonLee self-assigned this Sep 6, 2020
@SeKwonLee SeKwonLee linked a pull request Sep 7, 2020 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants