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

EOF Optimization - don't split code sections #4898

Merged
merged 3 commits into from
Jan 11, 2023

Conversation

shemnon
Copy link
Contributor

@shemnon shemnon commented Jan 9, 2023

PR description

Optimize the EOF Functions implementation by not splitting code sections into separate Bytes object. Instead the EOF evaluation occurs on a single container space. When a function is called the PC (relative to container start, not section start) is moved, and no section re-loading needs to occur.

EOF lacks PC introspection and absolute jumps, so where "PC=0" starts is not observable to the code.

Fixed Issue(s)

Documentation

  • I thought about documentation and added the doc-change-required label to this PR if
    updates are required.

Changelog

Optimize the EOF Functions implementation by not splitting code sections
into separate Bytes object.  Instead the EOF evaluation occurs on a
single container space.  When a function is called the PC (relative to
container start, not section start) is moved.

EOF lacks PC introspection and absolute jumps, so where "PC=0" starts is
not observable to the code.

Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com>
@shemnon shemnon requested a review from diega January 9, 2023 15:44
workList[maxWork] = new int[] {currentPC + rvalue + 3, currentStackHeight};
maxWork++;
} else if (thisOp == RelativeJumpVectorOperation.OPCODE) {
int immediateDataSize = (code[currentPC + 1] & 0xff) * 2;

Check failure

Code scanning / CodeQL

Array index out of bounds

This array access might be out of bounds, as the index might be equal to the array length.
@macfarla macfarla changed the title EOF Optimization - don't spit code sections EOF Optimization - don't split code sections Jan 9, 2023
@shemnon shemnon requested a review from jflo January 11, 2023 19:11
Copy link
Contributor

@jflo jflo left a comment

Choose a reason for hiding this comment

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

All good. Is this just improving memory usage or is there some other improvement i'm not seeing?

@shemnon
Copy link
Contributor Author

shemnon commented Jan 11, 2023

(a) memory usage. We don't have to slice out code sections and make copies of the sections. Also a bit of speed on the parse
(b) complexity. You will notice that CALLF and RETF no longer need special handling in the EVM loop. While they can be moved there if it is optimal they no longer need to reset the code in that loop as we are all off of one code loop.

@shemnon shemnon enabled auto-merge (squash) January 11, 2023 19:47
Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com>
@shemnon
Copy link
Contributor Author

shemnon commented Jan 11, 2023

(c) there is also a runtime performance improvement, as we don't have to swap code sections in and out at function calls, but instead it's just a jump with more rules.

@shemnon shemnon merged commit 2a30dfb into hyperledger:main Jan 11, 2023
eum602 pushed a commit to lacchain/besu that referenced this pull request Nov 3, 2023
Optimize the EOF Functions implementation by not splitting code sections
into separate Bytes object.  Instead the EOF evaluation occurs on a
single container space.  When a function is called the PC (relative to
container start, not section start) is moved.

EOF lacks PC introspection and absolute jumps, so where "PC=0" starts is
not observable to the code.  "PC=0" is still respected in the traces.

Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com>
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