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

Convert nested interpreter calls into a single loop #20

Merged
merged 10 commits into from Feb 2, 2019

Conversation

Projects
None yet
1 participant
@SquidDev
Copy link
Owner

SquidDev commented Jan 29, 2019

Previously, each frame of a Lua function was run in its own interpreter. While this made the implementation simpler (and possibly more elegant), it did mean the Lua stack depth was bound by Java's (which wasn't very high, due to the 3-4 calls needed to execute a function).

Instead, we convert an interpreter into a nested loop, with the outer one setting up the function from the current frame, and the inner one acting mostly the same as before. However, instead of using OperationHelper.invoke/OperationHelper.call for Lua functions, we'll push a new frame and run the interpreter that way.

We don't currently support running metamethods inside the same interpreter, but I think that is acceptable - Lua is the same, and it would mean we have to inline most of OperationHelper, which bloats the interpreter even more.

As far as performances goes, it's rather hard to tell. I've tried to run an awful lot of benchmarks, but they're a) hazy at best and b) some have improved, some have got worse. It appears that call-heavy code has become worse, though I'm not entirely sure why - it's something I'd like to resolve before merging, but is not entirely a blocker.

SquidDev added some commits Jan 26, 2019

Clean up the Lua VM a little bit
 - Replace most constants with those from Lua.*
 - Make branching instructions consume the jump target from the next
   instruction too. This is a minor optimisation, but is allowed by the
   Lua VM.
Allow growing the stack beyond our previous 256 limit
Our value of Short.MAX_VALUE is pretty arbitrary, but is pretty close to
Lua's limit with an average-large (30) number of variables.
Remove valueOfDirect
I'm not entirely convinced this is a "correct" optimisation, and really
doesn't make a difference in practice.

SquidDev added some commits Jan 29, 2019

Inline Math.*Exact methods
While we may lose out on some performance gain from them previously
being intrinsics, the throwing of ArithemticException was causing
serious performance regressions in very specific code paths.

The included code (primes.lua) would cause an overflow (throwing an
exception), and then modulus it (making it wrap back to an integer
again). As a result, this code ran in over 14s (almost instantly
after this patch and on master).
Remove TailcallVarargs
As the interpreter was the only thing which actually created or consumed
tail calls, and this is handled internally now, we no longer need this.
Add back integer-specialisation for multiplication
A wee bit ugly, but should still be faster than coercing to and from a
double.

@SquidDev SquidDev merged commit e380d8e into master Feb 2, 2019

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@SquidDev SquidDev deleted the feature/one-interpreter branch Feb 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.