On 03/07/2018 08:50 AM, takashikkbn / gmail.com wrote:
> Issue #14489 has been updated by k0kubun (Takashi Kokubun).
>
>
> We should make sure what we're going to solve here first before introducing such mechanism. At least I prefer having Feature#14492 first and I suspect boot time would not be the issue after that. With --jit enabled, it takes time to wait for shutting down MJIT worker and it's sometimes considered as kind of boot time issue for short running scripts, but it's totally different issue from this ticket.
I'd also prefer to solve shutting down MJIT first. Right now, MJIT is 
just waiting for all processes finishing (e.g. compilation of the header 
file) even if it is already known that the result will be not used. If 
we implement canceling the processes, the run time of small scripts 
would be a smaller problem.

This task was on my todo list. I'll probably start working on it in May 
if nobody starts working on it before.
> And I also suspect that the cached code might be inefficient because some aggressive optimization using cache like class_serial would be unavailable. Just translating instructions to native code wouldn't make big difference from VM execution, and we need inlining which depends on cache key that can't be known before execution. Then it may become even slower than original ISeq execution by increasing the number of VM invocations.
>
Takashi, I am also agree with you here about the optimizations.

I also thought about caching from MJIT project start. It still can be 
helpful in many cases but dealing with security vulnerabilities of 
caching should be considered seriously first.

I recently started some research work in my spare time on a lighter JIT 
whose compilation time might be at least 100 times faster but code is 
worse. It is an ambitious project and probably will take a lot of time 
even I am going to reuse most of MJIT code but if it is implemented, it 
could be used as tier 1 JIT for practically any method and the current 
MJIT based on C compilers could be a tier 2 JIT used for more frequently 
executed methods to generate a better performance code. A lighter JIT 
project will have a slow development pace as we need to do a lot for 
improving MJIT based on C compilers (inlining, some floating point code 
improvements i am considering). I am planning to attend RubyKaigi 2018 
and if you visit it too we could discuss MJIT development and the 
lighter JIT project.


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