WIP: Feat/pooled vms

[raidancampbell]

Not worth an in-depth review yet, just looking to make sure I'm steering the implementation in a direction you'd want.

WIP until:

• [ ] more input/discussion
• [ ] enable strict mode when the flag is set so that javascript will fail rather than leak context in x = 1 declarations
  • EDIT: otto doesn't understand strict mode. this will need a switch to goja.
  • DOUBLE EDIT: this is a huge pain in the butt, and does not justify the benefits of strict mode. I'm giving up on this. Alternative workaround will be parsing the rules into JSON and passing it through a linter. This workaround will not be committed into rulio.
• [X] wrap it in return eval('%s') so that return isn't required
• [ ] manual correctness testing
• [ ] performance comparison
• [X] undo the "don't commit this" test...
• [ ] code containing newlines aren't considered legal. blindly doing a string replace with a semicolon seems unwise...

There's some unrelated test cleanups to make it run faster, 0a4244c is the big ticket commit here. happy to rip them out so that there's a single useful commit in this PR.

[jsccast]

Looks promising!

[raidancampbell]

update:

• the Travis CI configuration is no longer valid, it looks like yesterday was their big org -> com change. not sure if you care
• the urgency of this has significantly decreased from my side. The previous set of optimizations along with some GC tuning has yielded a tolerable CPU/throughput tradeoff for the time being
• the edge cases that keep sneaking up are muddying the implementation, it's no longer a quick and easy benefit
  • variable declarations need var to prevent scope leakage. setting use strict should make this a visible error, but Otto doesn't support it. Goja does support it: I gave up on refactoring that, it's a larger change than I'm looking to make. Instead the client/user needs some way of ensuring the code is compliant.
  • javascript statements that are separated by newlines (default for code expressed in arrays) isn't valid in an eval. Replacing newlines with semicolons causes collateral damage for code that's formatted like var x = {\n foo: bar,\n baz: qux\n}.

At this point the solution is fraught with enough unexpected pitfalls that I'd be unlikely to use it myself, as this implementation would require a significant amount of rule rewrites. Unless you wish otherwise, I'll close this in a couple days.

[jsccast]

Thanks for the update.

Re TravisCI, I opened #82 to track the required updates.

Re edge cases, pitfalls, and required rule updates: Understood. Sorry about that, but glad the other performance improvements resulted in a tolerable situation.

Thanks again for the analysis and related work.

[raidancampbell]

Closing as discussed above: The suggested implementation had too many pitfalls to be trustworthy