https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112020-12-30T05:49:39ZRuby Issue Tracking SystemRuby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=896362020-12-30T05:49:39Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/89636/diff?detail_id=58845">diff</a>)</li></ul> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=896392020-12-30T15:04:59ZEregon (Benoit Daloze)
<ul></ul><p>If we'd consider RubyVM is CRuby-specific, then it seems fine.<br>
However, that's rather unclear, and then the question is what should other Ruby implementations should do <code>RubyVM::MJIT</code> and its methods?<br>
(other Ruby implementations might be forced to define <code>RubyVM</code> for compatibility at some point, it wouldn't surprise me)</p>
<p>I think Ruby users should anyway not need to use RubyVM::MJIT methods, so I prefer the more precise <code>MJIT</code> name.<br>
<code>RubyVM</code> is already awfully confusing. <code>RubyVM::JIT</code> sounds like a general/portable API (from the name) when it is in fact CRuby-specific.</p>
<p>IMHO, a benchmark harness should not need to use a JIT-specific API, so I think <code>pause</code>/<code>resume</code> are only useful for debugging.</p>
<p><code>RubyVM::MJIT.enabled?</code> could become a portable API, but it would need to move somewhere else.<br>
I'm also unsure if it's needed besides MRI tests, in part because all major Ruby implementations already show if there is a JIT in <code>RUBY_DESCRIPTION</code>.</p> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=896482020-12-30T22:59:06Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>Eregon (Benoit Daloze) wrote in <a href="#note-2">#note-2</a>:</p>
<blockquote>
<p>If we'd consider RubyVM is CRuby-specific, then it seems fine.</p>
</blockquote>
<p>Yes.</p>
<p><a class="changeset" title="Make it as clear as possible that RubyVM is MRI-specific and only exists on MRI (#2113) [ci skip]..." href="https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/39a43d9cd09f8c880d0a70d9cb8ede6d7e6ef583">39a43d9cd09f</a></p>
<pre><code> /*
* Document-class: RubyVM
*
* The RubyVM module only exists on MRI. +RubyVM+ is not defined in
* other Ruby implementations such as JRuby and TruffleRuby.
</code></pre> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=896622020-12-31T07:47:14Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul></ul><blockquote>
<p>If we'd consider RubyVM is CRuby-specific, then it seems fine.<br>
However, that's rather unclear, and then the question is what should other Ruby implementations should do RubyVM::MJIT and its methods?</p>
<p>RubyVM::MJIT.enabled? could become a portable API, but it would need to move somewhere else.<br>
I'm also unsure if it's needed besides MRI tests</p>
</blockquote>
<p>Didn't you clarify it by yourself at [Feature <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: RubyVM should be renamed to CRuby (Closed)" href="https://bugs.ruby-lang.org/issues/15743">#15743</a>]? The person who wrote the line that nobu quoted was you. You made it pretty clear that <code>RubyVM::MJIT</code> doesn't need to exist in other implementations.</p>
<blockquote>
<p>I think Ruby users should anyway not need to use RubyVM::MJIT methods, so I prefer the more precise MJIT name.</p>
</blockquote>
<p>So, would you suggest always explaining what is "M"JIT in every release note and renaming <code>--jit</code> to <code>--mjit</code> to approach the naming inconsistency issue explained in this ticket? I'm fine with pasting a link for the former, but I'm reluctant to force users to remember the name for the flag.</p>
<blockquote>
<p>IMHO, a benchmark harness should not need to use a JIT-specific API, so I think pause/resume are only useful for debugging.</p>
</blockquote>
<p>I agree. None of such benchmarks are supposed to be used for purposes other than testing MRI vs MRI+MJIT. I mean, can't I even put a script to test it?</p> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=896632020-12-31T08:05:56Zhsbt (Hiroshi SHIBATA)hsbt@ruby-lang.org
<ul></ul><p>I'm +1 to rename it.</p> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=896832021-01-01T12:20:38ZEregon (Benoit Daloze)
<ul></ul><p>k0kubun (Takashi Kokubun) wrote in <a href="#note-4">#note-4</a>:</p>
<blockquote>
<p>Didn't you clarify it by yourself at [Feature <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: RubyVM should be renamed to CRuby (Closed)" href="https://bugs.ruby-lang.org/issues/15743">#15743</a>]? The person who wrote the line that nobu quoted was you. You made it pretty clear that <code>RubyVM::MJIT</code> doesn't need to exist in other implementations.</p>
</blockquote>
<p>I tried to document it. I don't think it's good enough, many people don't read class documentation.<br>
If e.g., they see RubyVM::AbstractSyntaxTree in a blog post, they might use it and miss the fact it's MRI-specific, because the name gives no clue about it.<br>
And it gets more complicated, as RubyVM::AbstractSyntaxTree could exist on other Ruby implementations without much issues, while RubyVM::InstructionSequence probably cannot.</p>
<blockquote>
<p>So, would you suggest always explaining what is "M"JIT in every release note</p>
</blockquote>
<p>Actually I think <code>MJIT</code> is a lot clearer than <code>JIT</code> in e.g. <a href="https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/" class="external">https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/</a><br>
MJIT is not the only "Ruby Just-in-Time compiler", so being precise seems helpful to me when mentioning it by name.</p>
<blockquote>
<p>and renaming <code>--jit</code> to <code>--mjit</code> to approach the naming inconsistency issue explained in this ticket? I'm fine with pasting a link for the former, but I'm reluctant to force users to remember the name for the flag.</p>
</blockquote>
<p>Agreed the flag should be <code>--jit</code> as it is.</p>
<p>Since users shouldn't use RubyVM::MJIT methods anyway, I think it doesn't matter much what is the constant name for users.<br>
My concern is from the name, <code>RubyVM::JIT</code> sounds like some official "blessed" API ("the JIT of the Ruby VM", nothing in that name hints it's MRI-specific), while <code>RubyVM::MJIT</code> has a hint of "implementation details"/shouldn't be used by casual users.<br>
Really, the fault is the bad name of the <code>RubyVM</code> constant which completely misses the most important thing which is to hint it's MRI specific in the name, but I guess that's a lost battle (<a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: RubyVM should be renamed to CRuby (Closed)" href="https://bugs.ruby-lang.org/issues/15743">#15743</a>).</p> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=896902021-01-01T12:48:28ZEregon (Benoit Daloze)
<ul></ul><p>FYI, I filed <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: Move RubyVM::* to ExperimentalFeatures (Rejected)" href="https://bugs.ruby-lang.org/issues/17500">#17500</a> regarding RubyVM.<br>
I think <code>ExperimentalFeatures::JIT</code> would be fine if we accept that issue, and e.g. other Rubies might implement <code>ExperimentalFeatures::JIT.enabled?</code> then, which makes sense to me.</p> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=897122021-01-02T03:06:30Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul></ul><p>Now some discussions seem to be mixed, so let's sort them out:</p>
<a name="RubyVM"></a>
<h2 >RubyVM::<a href="#RubyVM" class="wiki-anchor">¶</a></h2>
<blockquote>
<p>I tried to document it. I don't think it's good enough, many people don't read class documentation.<br>
If e.g., they see RubyVM::AbstractSyntaxTree in a blog post, they might use it and miss the fact it's MRI-specific, because the name gives no clue about it.<br>
And it gets more complicated, as RubyVM::AbstractSyntaxTree could exist on other Ruby implementations without much issues, while RubyVM::InstructionSequence probably cannot.</p>
<p>My concern is from the name, RubyVM::JIT sounds like some official "blessed" API ("the JIT of the Ruby VM", nothing in that name hints it's MRI-specific), while RubyVM::MJIT has a hint of "implementation details"/shouldn't be used by casual users.<br>
Really, the fault is the bad name of the RubyVM constant which completely misses the most important thing which is to hint it's MRI specific in the name, but I guess that's a lost battle (<a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: RubyVM should be renamed to CRuby (Closed)" href="https://bugs.ruby-lang.org/issues/15743">#15743</a>).</p>
<p>FYI, I filed <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: Move RubyVM::* to ExperimentalFeatures (Rejected)" href="https://bugs.ruby-lang.org/issues/17500">#17500</a> regarding RubyVM.<br>
I think ExperimentalFeatures::JIT would be fine if we accept that issue, and e.g. other Rubies might implement ExperimentalFeatures::JIT.enabled? then, which makes sense to me.</p>
</blockquote>
<p>Yes, let's move to <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: Move RubyVM::* to ExperimentalFeatures (Rejected)" href="https://bugs.ruby-lang.org/issues/17500">#17500</a>. I thought you would not care about whether it's <code>WhateverMRISpecificName::MJIT</code> or <code>WhateverMRISpecificName::JIT</code> too.</p>
<a name="--jit"></a>
<h2 >--jit<a href="#--jit" class="wiki-anchor">¶</a></h2>
<blockquote>
<p>Agreed the flag should be --jit as it is.</p>
</blockquote>
<p>:+1:</p>
<a name="MJITpause-resume"></a>
<h2 >MJIT.pause / .resume<a href="#MJITpause-resume" class="wiki-anchor">¶</a></h2>
<blockquote>
<p>Since users shouldn't use RubyVM::MJIT methods anyway, I think it doesn't matter much what is the constant name for users.</p>
</blockquote>
<p>Yeah, when this API was introduced, it was said that "There is no objection (because RubyVM is just for internal features)" <a href="https://bugs.ruby-lang.org/issues/14830#note-3" class="external">https://bugs.ruby-lang.org/issues/14830#note-3</a>. I expected a similar kind of feedback to this ticket and meant to only confirm that here, although it seems to have triggered other discussions.</p>
<a name="Release-notes"></a>
<h2 >Release notes<a href="#Release-notes" class="wiki-anchor">¶</a></h2>
<blockquote>
<p>Actually I think MJIT is a lot clearer than JIT in e.g. <a href="https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/" class="external">https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/</a><br>
MJIT is not the only "Ruby Just-in-Time compiler", so being precise seems helpful to me when mentioning it by name.</p>
</blockquote>
<p>Are you saying, if we write "JIT" in an MRI release note, readers might get confused about whether it's MRI's JIT or TruffleRuby's Graal?</p>
<p>Once we have another tier of JIT in MRI, I'd agree it's useful to mention the name "MJIT" at least in a NEWS like:</p>
<pre><code># JIT
## Lightweight JIT
...
## MJIT
...
</code></pre>
<p>but a release note is something which is read by many non-Rubyist people who often don't know there has been a JIT since Ruby 2.6 in the first place. Many people thought Ruby 3 newly introduced a JIT, reading the latest release note. Using our original jargon would simply confuse such audiences. I'm personally <em>okay</em> with mentioning MJIT in NEWS.md though.</p> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=897132021-01-02T03:07:34Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/89713/diff?detail_id=58871">diff</a>)</li></ul> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=897202021-01-02T12:50:50ZEregon (Benoit Daloze)
<ul></ul><blockquote>
<a name="Release-notes"></a>
<h2 >Release notes<a href="#Release-notes" class="wiki-anchor">¶</a></h2>
<blockquote>
<p>Actually I think MJIT is a lot clearer than JIT in e.g. <a href="https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/" class="external">https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/</a><br>
MJIT is not the only "Ruby Just-in-Time compiler", so being precise seems helpful to me when mentioning it by name.</p>
</blockquote>
<p>Are you saying, if we write "JIT" in an MRI release note, readers might get confused about whether it's MRI's JIT or TruffleRuby's Graal?</p>
</blockquote>
<p>Not really, I'm saying the "JIT" is just unclear, "which JIT is it?".<br>
The 3.0.0 release notes are hard to read for me because they mix MJIT and JIT.<br>
If we use MJIT everywhere in that note, then I think it is very clear.<br>
If we use JIT everywhere in that note, then I think it is very unclear.<br>
I show examples below.</p>
<blockquote>
<p>Once we have another tier of JIT in MRI, I'd agree it's useful to mention the name "MJIT" at least in a NEWS like:</p>
</blockquote>
<p>Yes, I was also thinking about that, if there is another JIT in MRI then <code>RubyVM::JIT</code> would become ambiguous.</p>
<blockquote>
<p>but a release note is something which is read by many non-Rubyist people who often don't know there has been a JIT since Ruby 2.6 in the first place.</p>
</blockquote>
<p>That means they didn't read previous release notes then?<br>
So probably they read the 3.0 notes because of the new major version.</p>
<p>I think a single sentence, or a link for MJIT would be best, e.g.,<br>
"MJIT is a method JIT for CRuby available since Ruby 2.6."</p>
<blockquote>
<p>Many people thought Ruby 3 newly introduced a JIT, reading the latest release note.</p>
</blockquote>
<p>I think that's partly caused by using the term JIT and not MJIT in some places.</p>
<p>"Many improvements were implemented in MJIT." is very clear.</p>
<p>"As of Ruby 3.0, JIT is supposed to give performance improvements in limited workloads" is unclear, does it mean a JIT appeared in 3.0? (no)<br>
Same with JIT->MJIT is clear (and it connects to the previous sentence):<br>
"As of Ruby 3.0, MJIT is supposed to give performance improvements in limited workloads"</p> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=897212021-01-02T15:51:44Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul></ul><p>I get your points. Nothing is technically wrong in what you're saying, and as a committer like you it's easier to interpret MJIT.</p>
<p>But I mean, I assume we're not writing a release note for people like us who can just read details in NEWS but writing it for people who are just not interested in such details. Saying "JIT became faster" is enough to just get attention from various andiences (and explaining details which people are not interested in only hurts it), and if people really care about "which JIT is it?", they should go to NEWS and we should clarify it once we have multiple JITs.</p> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=897272021-01-03T13:28:00ZEregon (Benoit Daloze)
<ul></ul><p>JIT just means "Just-in-Time", so actually to be grammatically correct I guess the release note should either refer to "MJIT" (a proper noun) or "the JIT compiler (bundled with Ruby)".<br>
Either way, I think to make it clear in the release note, the only way would be to add a sentence like<br>
"Ruby ships with a JIT since Ruby 2.6 (named MJIT). In Ruby 3.0, it has been improved significantly".</p>
<p>I don't see why an internal/experimental module (RubyVM::MJIT) need to have name understandable by people knowing nothing about MJIT.<br>
I'd say users of RubyVM::MJIT should at least know the name of the JIT before using those APIs.</p> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=897422021-01-04T04:50:07Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul></ul><p>This thread is already too long for off topics, so let me focus on the name of <code>RubyVM::MJIT</code> in this ticket and leave the release notes discussion to elsewhere.</p>
<blockquote>
<p>I don't see why an internal/experimental module (RubyVM::MJIT) need to have name understandable by people knowing nothing about MJIT.<br>
I'd say users of RubyVM::MJIT should at least know the name of the JIT before using those APIs.</p>
</blockquote>
<p>If the feature will continue to be MJIT-specific, your point would make sense. But as I'm trying to make <code>--jit</code> and <code>RubyVM::MJIT</code> consistent in terms of their name, I think their feature should also be consistent; <code>RubyVM::MJIT.pause/resume</code> should control not only MJIT but also other JITs if <code>--jit</code> is going to enable all future tiers of JIT (at least by default, even if we add an option to specify a JIT to it). I think the number of JIT-relaed APIs should be as few as possible, and this change will contribute to limiting per-JIT features. I don't want <code>RubyVM::YetAnotherJIT</code> in the future.</p>
<p>By the way, let me point out again that this feature is mainly for MJIT's development / testing and not for people who don't contribute to developing MJIT. Please don't take my development time away for discussing this if you only care about TruffleRuby's compatibility with modules under RubyVM, because clearly there's no need to do so.</p> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=897442021-01-04T05:11:03Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/89744/diff?detail_id=58885">diff</a>)</li></ul> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=899072021-01-13T06:29:43Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>As of <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: RubyVM should be renamed to CRuby (Closed)" href="https://bugs.ruby-lang.org/issues/15743">#15743</a>, it was made clear that <code>RubyVM</code> means CRuby specific module (OK? <a class="user active user-mention" href="https://bugs.ruby-lang.org/users/772">@Eregon (Benoit Daloze)</a>). I am OK with renaming it <code>JIT</code> (or not).<br>
So it's totally up to <a class="user active user-mention" href="https://bugs.ruby-lang.org/users/10073">@k0kubun (Takashi Kokubun)</a>.</p>
<p>In addition, I don't think we need a migration path for this internal feature.</p>
<p>Matz.</p> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=899432021-01-14T06:50:23Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>Applied in changeset <a class="changeset" title="Rename RubyVM::MJIT to RubyVM::JIT because the name "MJIT" is an internal code name, it's incons..." href="https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/e1fee7f949cb6719122672fa1081c60984a5339f">git|e1fee7f949cb6719122672fa1081c60984a5339f</a>.</p>
<hr>
<p>Rename RubyVM::MJIT to RubyVM::JIT</p>
<p>because the name "MJIT" is an internal code name, it's inconsistent with<br>
--jit while they are related to each other, and I want to discourage future<br>
JIT implementation-specific (e.g. MJIT-specific) APIs by this rename.</p>
<p>[Feature <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Rename RubyVM::MJIT to RubyVM::JIT (Closed)" href="https://bugs.ruby-lang.org/issues/17490">#17490</a>]</p> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=960072022-01-17T06:00:14Zznz (Kazuhiro NISHIYAMA)
<ul></ul><p>MEMO: This feature reverted at <a href="https://github.com/ruby/ruby/commit/1a63468831524f68e73cbb068071652c6486cfc6" class="external">https://github.com/ruby/ruby/commit/1a63468831524f68e73cbb068071652c6486cfc6</a> without major release.</p> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=960082022-01-17T06:32:15Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul></ul><p>The revert was proposed and implemented at <a href="https://bugs.ruby-lang.org/issues/18349" class="external">https://bugs.ruby-lang.org/issues/18349</a>.</p> Ruby master - Feature #17490: Rename RubyVM::MJIT to RubyVM::JIThttps://bugs.ruby-lang.org/issues/17490?journal_id=960092022-01-17T06:32:47Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/18349">Feature #18349</a>: Let --jit enable YJIT on supported platforms</i> added</li></ul>