honeypony / jaylox Goto Github PK

gc: trace 000001eb00505328 = instance (-1512 rel to high_ptr)
-- instance->class: 000001eb00504b40 -> 000001eb00505370
    gc: copy 000001eb005050e0 -> 000001eb00505910 (216 bytes)
    gc: copy table
-- instance->table: 000001eb005050e0 -> 000001eb00505910
^^^ return size = 24
gc: trace 000001eb00505340 = instance (-1704 rel to high_ptr)
    gc: copy 000001eb00505340 -> 000001eb005059e8 (24 bytes)
    gc: copy instance
-- instance->class: 000001eb00505340 -> 000001eb005059e8
-- instance->table: 0000000000000000 -> 0000000000000000
runtime error: unknown garbage collection type

This output shows that an instance's ->class is somehow set t the same pointer (ending in 340) and so when it copies that value over, it ends up causing a problem for itself.

Now, strictly speaking, if an object is pointing at itself when we visit it, we shouldn't copy it -- so more than one thing is going wrong here..?

The idea here is that, instead of having specialized functions for things like arithmetic operations, we just directly generate code like:

// expr: subtract
jay_check_numerical(jay_stack_ptr[-2]);
jay_check_numerical(jay_stack_ptr[-1]);
jay_stack_ptr[-2] = JAY_AS_NUMBER(jay_stack_ptr[-2]) - JAY_AS_NUMBER(jay_stack_ptr[-1]);
jay_stack_ptr -= 1;

Then, we can very easily check if one if the inner expressions is an expression that MUST produce a number, and simply elide that 'check'. Obviously, this is still a little bit slower than if we don't go through the stack at all, but it's an easy optimization.

In fact, it should be relatively straightforward to bridge from doing that to just checking the operands in a larger expression and then directly generating an arithmetic expression. But this simple optimization could be done just with some very basic pattern matching in the compiler.

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.

• Strings
  • Strings should compute a hash and store it internally, so that string comparison can be sped up.
  • 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.
  • Implement string concatenation.
  • Make string concatenation faster by storing the string length.
• 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
• "invoke" optimization
  • non-super
  • 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.
  • 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.
    • 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.
• Bug fixes
  • At the very least, each benchmark program should run without issue.
• Addition clox optimizations
  • Replace modulo with bitwise &
  • 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.

This would allow for any optimizations to locals, such as type-flow analysis / fence-elision / whatever, to be automatically applied to any variables that are only accessed in main, without any otherwise special logic.

It can be hard to keep track of which tests are failing, so I want to write them down.

Known failing tests at the moment: None!

• this.lox
• zoo.lox (should print, but it doesn't)
• binary_trees.lox