Issue #14489 has been updated by k0kubun (Takashi Kokubun).

Status changed from Open to Feedback

By the way, one thing I want to share is that currently JIT-ed function is not reusable for another process. That's because it embeds class serial that can be changed in next boot for inlining things, and pointers of ISeq / call cache that can be changed too. This ticket requires giving up some optimizations and need indirection in generated code, and it may make JIT-ed code slow. 

I agree that it's good to decrease time to warm up, but if it requires JIT to be slow, it doesn't make sense to me.

> Also, I think https://github.com/ko1/yomikomu should be in
stdlib(*) and there will be code sharing opportunity for
JIT and ISeq caches.

How does yomikomu.gem improve the boot time? I've thought the default way of ISeq serialization costs and bootsnap improves the performance by another way. I know bootsnap doesn't work with trunk though.

----------------------------------------
Feature #14489: MJIT needs a reusable cache
https://bugs.ruby-lang.org/issues/14489#change-70441

* Author: sam.saffron (Sam Saffron)
* Status: Feedback
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
Currently on Discourse boot I notice a few minutes of jitting every time you boot it:

This is a redacted output: https://gist.github.com/SamSaffron/4e18c2dacf476f1f27275f5b5d7bbb97 

CPU is spinning hard compiling temp file after temp file for **minutes**:

> JIT success (213.1ms): platform_string@/home/sam/.rbenv/versions/master/lib/ruby/gems/2.6.0/gems/bundler-1.16.1/lib/bundler/lazy_specification.rb:18 -> /tmp/_ruby_mjit_p6914u199.c

and so on.

Instead, mjit should have a reusable cache on disk it first tries fetching from prior to re-compiling. It can use an ISEQ SHA1 hash as the key to the cache. 








-- 
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>