Aren't most of those shenanigans done early in the VM's lifespan (as Rails boots, actions are called the first time,...), after which the world would be stable, and JIT-related caches wouldn't have to be lost?
Generally yes, and I won’t get into the weeds about how inlined methods can have their inlinedness invalided if you look too hard at or breathe on them- but this isn’t a deterministic process. The first time you touch an ActiveRecord::Model, the database is queried and your classes ARE redefined. It’s not even close to the same ballpark of loading a new class on the JVM, and the stabilizing assumption you’re hoping exists often doesn’t. Death by 1,000 cuts
Long time Rails dev here. I believe not. The Rails core devs have long known that monkey patching is not thread safe, and blows Ruby method caches, so they already reserve monkey patching for initialization time.
I feel that the definition of "monkey patching" doesn't (or shouldn't) cover what Rails does in AR. Monkey patch suggests a change of behaviour over what was initially intended, however dynamic method generation in AR is very-much part of the intended API.
That said, there are plenty of Rails apps that do monkey patch Rails internals, for better or worse.
Do you have something specific in mind? From my understanding of ActiveRecord, most of the method generation should happen the first time the class is defined.
