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

Optimise memory deallocation for stable log entries #96

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Aditya-Sood
Copy link

Increment: Modify unstable.shrinkEntriesArray() to better account for underlying-array utilisation
Fixes #71

… underlying-array utilisation

Signed-off-by: Aditya-Sood <[email protected]>
@Aditya-Sood
Copy link
Author

hi @pavelkalinnikov, could you please review the PR?
if it looks good then I'll get started on the "MemoryStorage.Compact method" as well that you had mentioned in the original issue

@pav-kv pav-kv self-requested a review August 18, 2023 12:23
@Aditya-Sood
Copy link
Author

hi @pavelkalinnikov, does the PR need any changes?

@Aditya-Sood
Copy link
Author

hi @pavelkalinnikov, could you please review the PR?

@pav-kv
Copy link
Contributor

pav-kv commented Sep 10, 2023

@Aditya-Sood Sorry, been super busy recently. Will review this PR this week.

Copy link
Contributor

@pav-kv pav-kv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. Posting some initial thoughts.

This change needs unit-tests to check correctness and demonstrate the situations in which the compaction heuristics kick in.

const lenMultiple = 2
if len(u.entries) == 0 {
func (u *unstable) shrinkEntriesSlice(nextUnstableEntryIndex int) {
if nextUnstableEntryIndex == len(u.entries) { //all log entries have been successfully stored
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Please add a whitespace between // and the comment. Same bellow.

Comment on lines +181 to 184
countStableEntries := nextUnstableEntryIndex
if countStableEntries > cap(u.entries)/lenMultiple {
return true
}
Copy link
Contributor

@pav-kv pav-kv Sep 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This heuristic is different from the proposed idea in #71. It still honours only "visible" entries in deciding when to compact; and so it is susceptible to the same problem. The idea that was proposed is that we should instead track the full allocated size of the underlying slice.

This heuristic also seems different from the original: it checks the ratio of stable entries vs. cap; previously it checked the ratio of all entries vs. cap. Any particular reason why you went with this heuristic?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi @pavelkalinnikov, thanks for the review
I forgot that cap() considers the backing array only for the last index, not the beginning one

I had another thought - at the time of shrinking the entries slice, if we remove references to the shrunk pb.Entry elements, then two things will happen:

  1. with no more references, the 'shrunk' pb.Entry values will immediately become available for GC (if not in use)
  2. the append() method will consider creating an entirely new backing array at the time of adding new elements when capacity is low, and then the preceding unreachable values (which currently hold empty pb.Entry values after the above change) will also become available for GC

this seemed like a much cleaner solution to me

if this approach seems feasible, then we can optimise the design further by replacing pb.Entry values with pointers instead, to further minimise the memory cost of holding shrunk values in the array until append() replaces the backing array

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi @pavelkalinnikov, could you please share your review of the above approach?

@Aditya-Sood
Copy link
Author

hi @pavelkalinnikov, could you please share your thoughts on this approach - #96 (comment)

@Aditya-Sood
Copy link
Author

hi @ahrtr, would you be able to weigh-in on #96 (comment)?

@Aditya-Sood
Copy link
Author

hi @mitake, @serathius, @ptabor, @spzala
would you be able to share your opinion on #96 (comment)?
I can start working on the change then, this PR has been open for 2.5 months now

@Aditya-Sood
Copy link
Author

hi @pav-kv

@serathius
Copy link
Member

QQ for any optimisation, do we have a benchmark that confirms the improvement?

@Aditya-Sood
Copy link
Author

hi @serathius, no I haven't implemented the proposed change yet
if you don't foresee any immediate issues with this approach then I can implement it and look into benchmarking?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Release in-memory log space based on entries size
3 participants