[ruby-core:72656] [Ruby trunk - Feature #11934] A feature to drop dynamics dynamically

Issue #11934 has been updated by Chris Seaton.


All of the dynamic language features you've described (constant and method redefinition, inclusion of modules etc) can already be done with no runtime cost (http://chrisseaton.com/rubytruffle/deoptimizing/, http://chrisseaton.com/phd/).

Now, that does require a JIT and a more sophisticated VM, but you were advocating disabling the language features in order to make that task easier.

So it's kind of a circular argument - you want to disable these features to make it easier to make a JIT, add inlinig etc, but if you had a JIT then you wouldn't need to disable the features in the first place.

You could still argue that even if we don't add a JIT or new optimisations such as method inlining, then disabling these features will improve the performance of MRI. I'm not so sure that's the case (but neither of us have empirical data on that). The check for redefinition is just reading and comparing a word isn't it? Compared to the massive overhead of bytecode interpretation, frames allocated on the heap etc, I'm not sure that reading a word is really a big problem.

Philosophically, I feel like it's the VM's job to fix performance, and we shouldn't be passing the buck to the user with things like `drop_dynamics`. If we did this we wouldn't be making Ruby 3x faster - we'd be making something that looked like Ruby but wasn't dynamic run faster.

----------------------------------------
Feature #11934: A feature to drop dynamics dynamically
https://bugs.ruby-lang.org/issues/11934#change-55907

* Author: Yusuke Endoh
* Status: Feedback
* Priority: Normal
* Assignee: 
----------------------------------------
Ruby is a dynamic language.  Everything is possible in runtime.

So, how about a feature to prohibit some dynamic features in runtime?

~~~~
Foo = 1

RubyVM.drop_dynamics

Bar = 2        #=> cannot define new constant
Foo = 2        #=> cannot redefine a constant
def foo; end   #=> cannot define a method
class Baz; end #=> cannot create a new class
~~~~

Ruby's dynamic property greatly restricts performance.  However, it is a bad idea to limit Ruby's dynamics.  It is Ruby's identity, and is actually useful in some aspects such as debugging, daily-scripting, research, hobby-use, etc.

That being said, when a program is in production, we don't necessarily use the dynamic features at any time during execution.  Typically, they are used only in initialization of application, such as eval-for-DRY and monkey patching.  After the initialization is done, we can drop (some of) dynamic features in some situations.

Currently, when considering optimization of Ruby implementation, we (the core-team) must always care the possibility of redefinition of any built-in methods.  That is not sound.  This proposal gives us a "normal" condition for considering optimization.  We can easily apply a lot of optimizations, like constant folding and method inline expansion.  In addition, some advanced analyses like JIT/AOT compilation, type inference and whole program optimization will be applicable much more effectively.

--

It is arguable what features are prohibited.  IMO, it is relatively easy to drop the following features.

* (re)definition of constants
* (re)definition of methods (including singleton methods an aliases)
* (re)definition of classes/modules
* inclusion of modules

Aggressively, we may limit the following features.

* destructive modification of some kind of objects (such as making string literal frozen by default)
* some meta-programming features like `Object#send`
* `eval` and `instance_eval`
* addition of instance variables
* XXX <- feel free to add your unfavorite features

We should care about a trade-off between compatibility impact and optimization effect.

--

I'm half-joking, but half-serious.  I'm unsure if this is really a great idea, but surely better than just restricting Ruby specification by default (such as frozen string literal).  This may be a key feature towards Ruby3x3.  

What do you think?

-- 
Yusuke Endoh <[e-mail]>



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>