Skip to content
This repository was archived by the owner on Aug 31, 2021. It is now read-only.

[[ Bug 20933 ]] Fix unchecked codegen overflow for large handlers #6311

Open
wants to merge 1 commit into
base: develop-8.1
Choose a base branch
from

Conversation

runrevmark
Copy link
Contributor

This patch changes the way instructions are turned into bytecode
for a handler. Previously there was an unreported hard limit which
meant that any handler which contained jumps with a delta > 8192
would cause a bad module to be generated. This has been fixed
by trying different sizes for jump delta encodings until one is
found which works. Very small handlers will be encoded in fewer
bytes than they are now, handlers which currently compile and work
will be the same size, and large handlers will now compile and
work correctly.

@runrevmark
Copy link
Contributor Author

I did this against develop, but it should be against develop-8.1 as it is a bug there too.

@peter-b
Copy link
Contributor

peter-b commented Feb 1, 2018

I'm not sure whether you can afford a more extensive refactor here & a jump in the bytecode format at the moment. If you can, consider adopting Self-Delimited Numeric Value representation throughout the bytecode format in order to extend to being able to represent arbitrary-sized everything.

@runrevmark
Copy link
Contributor Author

@peter-b : The argument indicies are already SDNVs - they always have been. This patch tries 5 different sizes for jump deltas in a handler - the one chosen being the smallest which allows all deltas to be encoded. Using a fixed chosen size for those indicies means the deltas can be calculated without doing a basic block decomposition (the problem being that the size of a delta depends on the size of the jumps and their deltas it jumps over).

@peter-b
Copy link
Contributor

peter-b commented Feb 2, 2018

You'd pay a lot of time during compilation to determine the most compact representation, while only saving a few bytes (assuming people only write handlers of a sensible length)

@runrevmark
Copy link
Contributor Author

@peter-b : Yes - that's why I think this is a happy medium - small handlers will now be smaller than they were, all handlers which currently work will be the same size and large handlers will be less compact than they could potentially be, but actually work.

In terms of doing it 'optimally', then it would be an O(n) algorithm to do so - which is what it is at the moment (imagine the VM had structured control-flow ops rather than jumps and then it is easy to see that the control-flow graph is essentially a tree - which you then compute deltas depth-first). It is worth doing but only when the decomposition is there and being used to actually optimize the bytecode (i.e. eliding jumps etc.).

@livecodeali livecodeali changed the base branch from develop to develop-8.1 March 8, 2018 21:10
This patch changes the way instructions are turned into bytecode
for a handler. Previously there was an unreported hard limit which
meant that any handler which contained jumps with a delta > 8192
would cause a bad module to be generated. This has been fixed
by trying different sizes for jump delta encodings until one is
found which works. Very small handlers will be encoded in fewer
bytes than they are now, handlers which currently compile and work
will be the same size, and large handlers will now compile and
work correctly.
@livecodepanos livecodepanos removed this from the 8.1.10-rc-1 milestone Jun 1, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants