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

Status changed from Feedback to Rejected

> A big question though is if the binaries can have some sort of manifest that allows you to run a pre-processor and do a simple string replace?

This might resolve performance decrease in indirection. But the optimized code relies on the runtime value of call cache. So even if we cache it, we can't use such code until we call them. One option is loading it after first call, but it may have different cache for early calls.

> but GCC is slow and running it 5000 times takes a very very long time.

Do we really need to load JIT-ed 5000 methods from first? MJIT would compile methods which need to be JIT-ed first. So the boot time should not require 5000 times compilation. Also JIT is basically for long running program. Thus I don't think it's not a fatal problem. I think this is too early to introduce while JIT compiler is massively changed.

I still agree that the problem yomikomu/bootsnap solves is good to be addressed. But it's for Feature #14492.
Let me consider this again at least after Feature #14492 is introduced.  Please let me focus on other problems, especially on Bug #14490.

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

* Author: sam.saffron (Sam Saffron)
* Status: Rejected
* Priority: Normal
* Assignee: k0kubun (Takashi Kokubun)
* 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>