Issue #14491 has been updated by sam.saffron (Sam Saffron).


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 and new 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. 

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


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

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