Python suffers the same issue. There's some discussion about dealing with it in this PEP and the pages it links: https://www.python.org/dev/peps/pep-0509/
Re:JITs are un-ergonomic
by The_Colonel on Sunday March 29, 2020 @08:51AM
(#22718574)
Python does not seem to be even trying to be competitive in performance though so it's less of an issue for them.
They do, it's just not a priority. The PEP I linked (as well as most of the work of its author, Victor Stinner, in the last years) are motivated by JITing.
There's also the "frame evaluation API" PEP [1], whose purpose is to allow pluggable evaluators in CPython without forking the entire interpreter, like Unladen Swallow had to.
Python is orders of magnitude slower than JS, though. It has the same problems, but doesn't even try solving most. PyPy would be a better VM to compare against.
Java deals with almost exactly the same issue. If you define an interface and a single implementing class, the code will be compiled to always call that classes method, and the deoptimized / recompiled if you load another class that implements that interface. JS could deal with these issues in a similar manner.
You can redefine Math.round. It's an ordinary method from rt.jar. You can change rt.jar or you can redefine it with java agent.
Not as straightforward as with JS, but Java JIT still have to account for those things.
May be it will assume some things about standard classes for optimization, but for user classes that will be true anyway.
Re:JITs are un-ergonomic
by ridiculous_fish on Tuesday March 31, 2020 @10:15PM
(#22744951)
You can really redefine an existing Java method at runtime? Well TIL!
To whet your appetite, what happens if you redefine Math.round? Java prohibits this for obvious reasons, but a JS joker may write:
JS engines really do inline Math.round, and must be prepared for this nonsense.It gets worse. Maybe you check for a property which is usually not found:
Hidden classes can almost reduce this to a pointer comparison. But what if someone adds a uuid property on Object.prototype? Every check is busted! v8 handles this with "validity cells", and it's ugly, requiring that every object know about every object which "inherits" from it.Now if you are a monster you may choose to write:
Every array gets a default value for 42. Think about how you would JIT numeric code in such an environment...