Clox parity

[HoneyPony]

I want to get jaylox in a state where it runs sort of "head to head" with clox before I start adding too many other optimizations.

• [x] Strings
  • [x] Strings should compute a hash and store it internally, so that string comparison can be sped up.
  • [x] Perhaps make string constants loaded once as globals? This isn't exactly what clox does, as clox stores constants per-Chunk, but it is closer.
  • [x] Implement string concatenation.
  • [x] Make string concatenation faster by storing the string length.
• [x] Garbage collector
  • The garbage collector will both slow things down, but also speed things up. It will be necessary to collect garbage sometimes, but if we do it right, allocation should be very fast in the non-collect case.
  • Note: I'm thinking of using a Cheney semi-space collector, which is different from Lox's mark-and-sweep--but that's OK
  • This may be the most important thing for parity
• [x] "invoke" optimization
  • [x] non-super
  • [x] super
  • Function calls on objects, right now, always create a new jay_bound_method. Which is, of course, very inefficient. It would be much better to only create that if we aren't immediately invoking a function.
  • This is an optimization clox does, and it would make sense to do this one to have parity.
  • [x] Semantic hole: In clox and jlox, a field shadowing a method gets priority, while right now, a method shadowing a field gets priority. I honestly might make this a "compatibility option" -- in my opinion, the method-shadowing-field makes more sense, as it is both faster in implementation, and doesn't break OO semantics. We could even make it illegal to assign to the same name.
  • [x] Possible optimization: Make a list of names that are both assigned to and method names, and only check the field set if the name is one of those.
• [x] Bug fixes
  • At the very least, each benchmark program should run without issue.
• [x] Addition clox optimizations
  • [x] Replace modulo with bitwise &
  • [x] Support NaN boxing
  • Note: at first it seemed like this made binary_tree.lox slower but with -O2 maybe it's actually faster..?

Once all these features are done, it would be interesting to benchmark clox vs jaylox. Then, I can start implementing new optimizations.

[HoneyPony]

Note: the "Possible optimization" was implemented much more elegantly than I originally thought, in commit 5363019. This makes method calls much faster, speeding up zoo.lox by about 40%. This wasn't really in clox but it's good to have it done now.

As far as "Bug fixes" go I'm considering that done as well. That said, the real question is whether the "clox parity" tag has all the bugs fixed, which isn't totally clear... but that's OK. If I ever write some tests to really compare my "clox parity" versus the newer versions, I will find out then.