Issue #11934 has been updated by Benoit Daloze.


I am not sure this would bring much in terms of performance,
and it would definitely limits lots of stuff to run in this mode (Rails as today would certainly not).
It sounds a bit to me like trying another language.

Constant folding and method inlining could already be performed if the guard for the constant/method lookup is carried along when inlining the method/constant access.

Whole-program optimizations like type inference could figure out more stuff but it seems very hard in Ruby even with these limitations to prove the exact single type of most expressions.
And then, for instance for method inlining, this would be just redundant with the data already available in inline caches, which a JIT could already take advantage of.

In light of the recent discussions about OpenStruct, it also feels that reflection and meta-programming should be made faster and not prohibited.
The complexity of the current version of OpenStruct is quite high as the related bugs show, with all the smart tricks instead of a fast method_missing.

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

* 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 <mame / ruby-lang.org>



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

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