Modifying compiled code objects at runtime results in race conditions if the code is executed under different contexts in multiple threads. This changes it to always use the constant scope from the call frame and set this up properly for all the cases. Also the JIT needs to setup these frames properly. Also ensures that the JIT also checks the constant scope when validating an inlined constant. Fixes #2221
This is a short blog post on how you can access call site objects from Ruby and do more inspection of the state of the VM at runtime.
Also updates config file for the latest jekyll version.
This allows for having a fixed point in memory that the JIT can use in the future, so we don't have to pin ConstantCache and we can fold the ConstantCache and ConstantCacheEntry together, while still being thread safe. This is the same mechanism that the InlineCache uses by replacing the symbol that gives the name for the lookup.
We didn't have caching for constant lookup for nested constants, such as Rubinius::VariableScope. This means that when a constants was referenced in that way, it would not cache the VariableScope constant. This commit introduces a constant cache very similar to not nested constants. It also stores the scope it was used under, so we can properly validate the have the correct constant. Also specialization is added to the JIT to have a fast path for these cached constants if they are still valid.
Currently the keyword "literal" is used inconsistently across the bytecode instructions. For example, push_const uses it, but set_const doesn't. Always use "literal" to indicate the index to literals. And this enables Rubinius' built-in bytecode printer to show the actual literals referenced by the index. This would really ease my life when hacking on Rubinus, hopefully others starting to hack on it.