Lazily create singletons on instance_{exec,eval} #5146
Conversation
f09b438 to
474395c
Compare
Previously when instance_exec or instance_eval was called on an object,
that object would be given a singleton class so that method
definitions inside the block would be added to the object rather than
its class.
This commit aims to improve performance by delaying the creation of the
singleton class unless/until one is needed for method definition. Most
of the time instance_eval is used without any method definition.
This was implemented by adding a flag to the cref indicating that it
represents a singleton of the object rather than a class itself. In this
case CREF_CLASS returns the object's existing class, but in cases that
we are defining a method (either via definemethod or
VM_SPECIAL_OBJECT_CBASE which is used for undef and alias).
This also happens to fix what I believe is a bug. Previously
instance_eval behaved differently with regards to constant access for
true/false/nil than for all other objects. I don't think this was
intentional.
String::Foo = "foo"
"".instance_eval("Foo") # => "foo"
Integer::Foo = "foo"
123.instance_eval("Foo") # => "foo"
TrueClass::Foo = "foo"
true.instance_eval("Foo") # NameError: uninitialized constant Foo
This also slightly changes the error message when trying to define a method
through instance_eval on an object which can't have a singleton class.
Before:
$ ruby -e '123.instance_eval { def foo; end }'
-e:1:in `block in <main>': no class/module to add method (TypeError)
After:
$ ./ruby -e '123.instance_eval { def foo; end }'
-e:1:in `block in <main>': can't define singleton (TypeError)
IMO this error is a small improvement on the original and better matches
the (both old and new) message when definging a method using `def self.`
$ ruby -e '123.instance_eval{ def self.foo; end }'
-e:1:in `block in <main>': can't define singleton (TypeError)
Co-authored-by: Matthew Draper <[email protected]>
24e9f19 to
38a7480
Compare
vm_eval.c
Outdated
| //rb_obj_info_dump(under); | ||
| // Make crefs log that this is a special lazy singleton? | ||
|
|
||
| cref = vm_cref_push(ec, under, ep, TRUE); |
There was a problem hiding this comment.
It might be good to add an assertion VM_ASSERT(singleton ? under == CLASS_OF(self) : under == self). Personally I like to remove under argument and pass CLASS_OF(self) to vm_cref_push when singleton is true, but I don't know whether @ko1 likes.
| break; | ||
| } | ||
| cref = CREF_NEXT(cref); | ||
| } |
There was a problem hiding this comment.
@ko1 Can CREF_CLASS(cref) be no longer zero? According to the code coverage, this loop seems indeed unused.
https://rubyci.s3.amazonaws.com/coverage-latest-html/ruby/vm_insnhelper.c.gcov.html#920
There was a problem hiding this comment.
Thanks for bringing this up. I couldn't find anywhere this happened (even before this change) and added an assertion to cref_new that klass was never 0 https://github.com/ruby/ruby/pull/5146/files#diff-2af2e7f2e1c28da5e9d99ad117cba1c4dabd8b0bc3081da88e414c55c6aa9549R251
Great improvement! 👏|
Oops, this change makes constant access slow. Can you reproduce this on your machine? I thought opt_getinlinecache would work, but looks like it does not actually? I have no idea why. |
Yes. I do see a slowdown as well 😩. I actually don't think it's the constant access that's slow but the EDIT: it seems to have something to do with what gcc happens to want to inline. |
|
I've included suggestions and think I have a better understanding of the performance change of that loop. I think what we're seeing is just a change to GCC's inlining. The change seems to be visible just from a Comparing the two using What's interesting is we see To test this assumption I made a commit jhawthorn@dc7f771 which inlines This took some trial and error I happened to find that inlining What do you recommend? I don't love using |
insns.def
Outdated
| (rb_num_t value_type) | ||
| () | ||
| (VALUE val) | ||
| // attr bool leaf = (value_type != VM_SPECIAL_OBJECT_CBASE); /* get cbase may allocate a singleton */ |
There was a problem hiding this comment.
allocation violate the leaf assumption?
There was a problem hiding this comment.
Ah maybe it does not I was mistaken, but I think this can also raise in the case of special constant so can't be leaf. I will update the comment.
|
I couldn't check everything (I forget this area...), but it seems okay. |
|
Could you note the improvement in NEWS performance section? |
Previously when
instance_execorinstance_evalwas called on an object, that object would be given a singleton class so that method definitions inside the block would be added to the object rather than its class.This commit aims to improve performance by delaying the creation of the singleton class unless/until one is needed for method definition, based on the discussion in #18276. Most of the time
instance_evalis used without any method definition.This was implemented by adding a flag to the cref indicating that it represents a singleton of the object rather than a class itself. In this case
CREF_CLASSreturns the object's existing class, but in cases that we are defining a method (either viadefinemethodorVM_SPECIAL_OBJECT_CBASEwhich is used for undef and alias).This also happens to fix what I believe is a bug. Previously
instance_evalbehaved differently with regards to constant access fortrue/false/nilthan for all other objects. I don't think this was intentional.With this change TrueClass/NilClass/FalseClass behave the same as everything else.
This also slightly changes the error message when trying to define a method through
instance_evalon an object which can't have a singleton class.Before:
After:
IMO this error is a small improvement on the original and better matches
the (both old and new) message when definging a method using
def self.With this change we can observe that instance_eval doesn't change an object's class unless necessary.
Before
(the "class" address changes)
After
(the "class" address remains the same)
This should be particularly helpful for Rails apps, which use
instance_evalas part of theActiveSupport::Callbacksmechanism when provided aProc(which is common for developers to do). Under the interpreter, this should be faster due to not allocating a new singleton, and keeping method entries and inline caches valid. Under both MJIT and YJIT this should be even more helpful as we'll be able to use jitted methods on objects which previously had been given singleton classes.I ran railsbench from yjit-bench on this (on my local AMD zen2 Linux machine) and the numbers look great (great enough that I'd love someone to double check this because it's in "too good to be true" territory 😳 🤞)
Before
After
So this change makes YJIT 1.16x faster than it was previously, and the interpreter 1.09x faster than it used to be! (and for fun old_interp/new_yjit = 1.47)
Ref: https://bugs.ruby-lang.org/issues/18354