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

Refactor unpacking of recursive types #372

Merged
merged 4 commits into from
Nov 11, 2024
Merged

Refactor unpacking of recursive types #372

merged 4 commits into from
Nov 11, 2024

Conversation

byroot
Copy link
Member

@byroot byroot commented Nov 11, 2024

Extracted from: #370

As initially implemented, we allocate a new stack whenever we encounter a recursive type. This means acquiring a whole 4kiB chunk from the arena, which generally is overkill.

Instead we can introduce a new type of stack item, that behave just like a Hash or Array.

Extracted from: #370

As initially implemented, we allocate a new stack whenever we
encounter a child stack. This means acquiring a whole 4kiB chunk
from the arena, which generally is overkill.

Instead we can introduce a new type of stack item, that behave just
like a Hash or Array.
Now that there's no longer a concept of child stacks, we can
embed the struct and save a malloc/free pair.
Reduce its size from 264 to 256B.
child_stack->parent = uk->stack;
uk->stack = child_stack;

_msgpack_unpacker_stack_push(uk, STACK_TYPE_RECURSIVE, 1, Qnil);
Copy link
Member

Choose a reason for hiding this comment

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

Since a child no longer creating a new stack, does this change mean that recursive types will trigger a stack overflow much sooner than before?

Copy link
Member Author

Choose a reason for hiding this comment

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

Possibly, yes. But the stack size if 128, that's quite a deep document, I don't think that's something you are likely to hit..

That said, your comment make me realize there's just no check whatsoever for the stack size :/

Would be worth adding one.

Copy link
Member Author

Choose a reason for hiding this comment

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

Nevermind, there's a check for it:

    if(uk->stack.capacity - uk->stack.depth <= 0) {
        return PRIMITIVE_STACK_TOO_DEEP;
    }

ext/msgpack/unpacker.c Show resolved Hide resolved
int raised;
obj = protected_proc_call(proc, 1, &uk->self, &raised);
uk->stack = child_stack->parent;
_msgpack_unpacker_free_stack(child_stack);
msgpack_unpacker_stack_pop(uk);
Copy link
Member

Choose a reason for hiding this comment

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

Can we assert that the pop here is actually popping a STACK_TYPE_RECURSIVE to ensure that we don't have a stack inconsistency issue?

Copy link
Member Author

Choose a reason for hiding this comment

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

We don't quite have a good setup for asserts in the gem, but yes that would be valuable to put something like that in place.

@byroot byroot merged commit a60b1da into master Nov 11, 2024
17 checks passed
@byroot byroot deleted the refactor-stack branch November 11, 2024 19:01
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.

2 participants