https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112017-02-04T05:43:55ZRuby Issue Tracking SystemRuby master - Bug #13188: Reinitialize Ruby VM. https://bugs.ruby-lang.org/issues/13188?journal_id=628542017-02-04T05:43:55Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul></ul><p>AFAIK the ruby interpreter uses lots of global variables, which makes it practically impossible to re-initialize.</p>
<p>This is of course not a good thing (antique design). I think mruby is much modern here.</p> Ruby master - Bug #13188: Reinitialize Ruby VM. https://bugs.ruby-lang.org/issues/13188?journal_id=628572017-02-04T08:19:34Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul></ul><p>Shyouhei Urabe wrote:</p>
<blockquote>
<p>AFAIK the ruby interpreter uses lots of global variables, which makes it practically impossible to re-initialize.</p>
</blockquote>
<p>How difficult would it be to fix this?</p> Ruby master - Bug #13188: Reinitialize Ruby VM. https://bugs.ruby-lang.org/issues/13188?journal_id=628702017-02-06T01:10:54Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul></ul><p>Martin Dürst wrote:</p>
<blockquote>
<p>Shyouhei Urabe wrote:</p>
<blockquote>
<p>AFAIK the ruby interpreter uses lots of global variables, which makes it practically impossible to re-initialize.</p>
</blockquote>
<p>How difficult would it be to fix this?</p>
</blockquote>
<p>Nobu and myself each once tried to move those global variables into the VM struct, to make it possible to have multiple VMs at once (mvm). My try changed hundreds of thousands of lines and resulted in inferior performance. It was because accessing global variable is in fact much faster than to indirectly refer them via VM-stored pointers.</p>
<p>So it is not only very hard to fix, but even when we do so, we have to live with slowness.</p> Ruby master - Bug #13188: Reinitialize Ruby VM. https://bugs.ruby-lang.org/issues/13188?journal_id=628712017-02-06T02:41:37Zko1 (Koichi Sasada)
<ul></ul><p>On 2017/02/06 10:10, <a href="mailto:shyouhei@ruby-lang.org" class="email">shyouhei@ruby-lang.org</a> wrote:</p>
<blockquote>
<p>VM-stored pointers</p>
</blockquote>
<p>More correctly, thread-local variables (on pthread).</p>
<p>--<br>
// SASADA Koichi at atdot dot net</p> Ruby master - Bug #13188: Reinitialize Ruby VM. https://bugs.ruby-lang.org/issues/13188?journal_id=629072017-02-07T22:21:43Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p>SASADA Koichi <a href="mailto:ko1@atdot.net" class="email">ko1@atdot.net</a> wrote:</p>
<blockquote>
<p>On 2017/02/06 10:10, <a href="mailto:shyouhei@ruby-lang.org" class="email">shyouhei@ruby-lang.org</a> wrote:</p>
<blockquote>
<p>VM-stored pointers</p>
</blockquote>
<p>More correctly, thread-local variables (on pthread).</p>
</blockquote>
<p>Was it function call overhead from pthread_getspecific?</p>
<p>Did you try __thread?</p>
<p>I think __thread was GCC-specific, but clang supports it, too;<br>
and we can fall back to existing pthread_getspecific for other<br>
compilers. I think something similar was introduced for C11,<br>
too, but we're still on C89...</p>
<p>But yeah, having VM struct passed with every function call<br>
(like mrb_state in mruby) is probably most portable and fast.</p> Ruby master - Bug #13188: Reinitialize Ruby VM. https://bugs.ruby-lang.org/issues/13188?journal_id=629082017-02-08T00:05:05Zko1 (Koichi Sasada)
<ul></ul><p>On 2017/02/08 7:18, Eric Wong wrote:</p>
<blockquote>
<p>But yeah, having VM struct passed with every function call<br>
(like mrb_state in mruby) is probably most portable and fast.</p>
</blockquote>
<p>Yes. Ruby 3 will use it.</p>
<p>--<br>
// SASADA Koichi at atdot dot net</p> Ruby master - Bug #13188: Reinitialize Ruby VM. https://bugs.ruby-lang.org/issues/13188?journal_id=629102017-02-08T00:41:45Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p>SASADA Koichi <a href="mailto:ko1@atdot.net" class="email">ko1@atdot.net</a> wrote:</p>
<blockquote>
<p>On 2017/02/08 7:18, Eric Wong wrote:</p>
<blockquote>
<p>But yeah, having VM struct passed with every function call<br>
(like mrb_state in mruby) is probably most portable and fast.</p>
</blockquote>
<p>Yes. Ruby 3 will use it.</p>
</blockquote>
<p>Good, but we will still keep a compatibility API for C extensions?</p> Ruby master - Bug #13188: Reinitialize Ruby VM. https://bugs.ruby-lang.org/issues/13188?journal_id=629492017-02-10T23:21:52Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p>Eric Wong <a href="mailto:normalperson@yhbt.net" class="email">normalperson@yhbt.net</a> wrote:</p>
<blockquote>
<p>SASADA Koichi <a href="mailto:ko1@atdot.net" class="email">ko1@atdot.net</a> wrote:</p>
<blockquote>
<p>On 2017/02/08 7:18, Eric Wong wrote:</p>
<blockquote>
<p>But yeah, having VM struct passed with every function call<br>
(like mrb_state in mruby) is probably most portable and fast.</p>
</blockquote>
<p>Yes. Ruby 3 will use it.</p>
</blockquote>
<p>Good, but we will still keep a compatibility API for C extensions?</p>
</blockquote>
<p>Also, can we introducing it in 2.5?<br>
(keeping compatibility API, of course).</p> Ruby master - Bug #13188: Reinitialize Ruby VM. https://bugs.ruby-lang.org/issues/13188?journal_id=642672017-04-17T05:39:08Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Assigned</i></li><li><strong>Assignee</strong> set to <i>ko1 (Koichi Sasada)</i></li></ul> Ruby master - Bug #13188: Reinitialize Ruby VM. https://bugs.ruby-lang.org/issues/13188?journal_id=648962017-05-19T03:05:13Zko1 (Koichi Sasada)
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Closed</i></li></ul><p>I close this ticket because we need long-time effort.</p>
<blockquote>
<p>Also, can we introducing it in 2.5?<br>
(keeping compatibility API, of course).</p>
</blockquote>
<p>If we can.</p> Ruby master - Bug #13188: Reinitialize Ruby VM. https://bugs.ruby-lang.org/issues/13188?journal_id=655342017-06-29T16:37:17Zusa (Usaku NAKAMURA)usa@garbagecollect.jp
<ul><li><strong>Status</strong> changed from <i>Closed</i> to <i>Rejected</i></li></ul> Ruby master - Bug #13188: Reinitialize Ruby VM. https://bugs.ruby-lang.org/issues/13188?journal_id=722802018-05-29T05:23:31Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/14792">Feature #14792</a>: Multiple RubyVM in one process to make real multi-threading.</i> added</li></ul>