-
Notifications
You must be signed in to change notification settings - Fork 25
Fix/product zipper shared node id by factor #136
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
Draft
imlvts
wants to merge
4
commits into
Adam-Vandervorst:master
Choose a base branch
from
imlvts:fix/product-zipper-shared-node-id-by-factor
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
66b804b
Fix ProductZipper is_shared at a factor root
imlvts 22750f8
Only report ProductZipper sharing in the last factor
imlvts 1e4a683
Report ProductZipper sharing in every factor, keyed by factor
imlvts e9d63f3
Never report sharing from DependentProductZipperG
imlvts File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already use a crate for this which steals bits from alignment, sign, and address space?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, we don't use a crate. there's code copied from
ointersinsrc/trie_node.rs:2804.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No? For physical addresses you can use the top byte, but for virtual ones you can't do that, and definitely not the top two bytes.
0b00000001 0b00000001is a perfectly fine start of an untagged pointer.Failing sharing on factor count seems devious.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
of all the limitations that PathMap and MORK have, this one should be the least controversial.
if you have more than 254 factors in a product zipper, please let me know.
doing any sort of traversal there would take too much time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, why again wasn't this lifted out @luketpeterson ? Seems like we don't want to be doing this ad-hoc, a mistake like this could corrupt the trie.
We do traversals over 1000+ bytes all the time
This should come with a big red exclamation mark. With that, we can move the <=255 assumption to optimize other methods as well perhaps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I double-checked myself, and it's system-dependent. for x86, 4K tables, top 2 bytes of virtual memory are either 0x00 or 0xff.
On all systems, top 4 bits are sign-extended. I'll find a better way.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the limit is on the number of nested maps, not byte depth. so
[map1, map2, map3, ... map254]Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reproduced with custom Alloc on x86, 4k tables, with 5-level paging that 0x0000_0020_0000_0000 and 0x0001_0020_0000_0000 are sent to the same node id, causing trie corruption.
Unless enrolling factors is slow, search algorithms controlling zippers can definitely still use this, see utils int.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Converting this to draft until we have a better solution.
If shared node id is u64 and they're essentially pointers, there will be still limits on what we can do with this.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This strikes me as one of those "difficult in theory but solvable in practice" kind of situations.
_idwithout the possibility of collisions.We have plenty of bits to give to this use - especially because we can ditch the tags from the ODRC pointers.
So the practical problems are:
Or, if there is some other really clever digest that can guarantee uniqueness without those limitations, I'm all for it. But I don't know what that would be.
If we implement the solution I outlined, the trickiest / most disruptive part seems to be 2 from an interface level. My preferred solution would be to create another trait, like
ZipperConcreteNodes(maybe there is a better name) with a different contract - to limit the results to 50 bits or whatever, and have theZipperConcreteimplemented as a pass-through toZipperConcreteNodes. Then PZs would choose NOT to implementZipperConcreteNodes, and supply their own impls ofZipperConcrete.