The use of Array#map would require the use of Array#compact to get rid of NilClass values in the parameters collection. An easier (and probably a bit faster way) of doing this is to simply use Array#each and push values into another Array. Signed-off-by: Yorick Peterse <email@example.com>
Before this commit the code tasked with retrieving method parameters would produce incorrect results. For example, take the following method definition: def example(number, &block) another_number = 20 end method(:example).parameters This would lead to the following output: [[:req, :number], [:block, :block], [:block, :another_number]] This was caused due to everything that remains (after processing other argument types) being assigned as block arguments. This patch fixes this issue by keeping track of the index of the block argument and comparing this to the list of local variables similar to how splat arguments are handled. Signed-off-by: Yorick Peterse <firstname.lastname@example.org>
We must ensure that the self object we see is actually of the same class that we optimized for. These types can be different, for example for subclasses of a certain class that might end up with a different memory layout for variables.
Before the additional data was either a block environment or a receiver class, but having a receiver class is also useful for compiling blocks. This matters for example for inlining instance variable reads if just a block is compiled. Improves benchmark/tiers/0/bm_vm1_ivar.rb significantly: Before: === bin/rbx === ivar read 58492061.6 (±3.0%) i/s - 289205872 in 4.948913s ivar set 41165744.5 (±2.6%) i/s - 204915000 in 4.982051s After: === bin/rbx === ivar read 266371814.2 (±5.6%) i/s - 1283690000 in 4.836606s ivar set 224551559.4 (±4.0%) i/s - 1110346272 in 4.953298s
Make it easier to see what the class is we guard the ivar read against.
Apperently on RHEL / CentOS 5.9 this breaks the compile since these symbols are exported there. Also checked against Ubuntu and the symbols are available there too. Fixes #2217
Problem here was that using assign() also resets the hit counters, leading to wrong heuristics on whether a method is called often or not. In certain cases this could lead to hot methods not being inlined.
We only need to mark this as on stack when internalizing, since only internalize could cause a lock and needs the compiled code object to be updated.