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


> My #1 motivation is that I am trying to figure out why --jit is making discourse bench slower even after everything is warmed up, so I want to run with --jit but disable all jitting so it continues counting method calls but never actually jits anything to see what the minimum impact of jit instrumentation is.
>
> If we can prove that jit instrumentation is just too expensive then it makes absolute sense to enable jit for N seconds in long running processes and then disable it after that, so you get the advantage of faster warmed up method and none of the cost of "jit" instrumentation where it has a counter on every method call counting to 5 so it can decide if it needs to jit it.

Your motivation makes sense. If it's turned out to be caused by counting method calls and we can't think of any option for it, having MJIT.disable is the last resort for it.

I still think we can use sampling profiler (like LLRB, which is my another JIT compiler), or disable automatically after some threshold (maybe it's not so realistic).

> That said I guess I can just edit the c files here to figure this out.

I know it's hard work and I wish I could add it, but I need to be conservative for adding interface for future maintenance cost.

I want to help you improve discourse's performance. Thank you for your suggestions on this.

----------------------------------------
Feature #14491: MJIT needs internal debugging methods
https://bugs.ruby-lang.org/issues/14491#change-70491

* Author: sam.saffron (Sam Saffron)
* Status: Feedback
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
### Issue

Doing careful analysis of MJIT performance is very hard cause there is no way of instrumenting this in runtime 

### Proposal

1. Add `MJIT.enable`, `MJIT.disable`, `MJIT.pause` methods. 

   - `MJIT.pause` will continue using MJIT for execution but will no longer compile new fragments

2. Add `MJIT.trace` or similar that returns a block for key compile start / compile end operations. 
   
```
MJIT.trace do |klass, method, line, operation, duration|
end
```

This will allow simpler analysis of MJITs performance.



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