Project

General

Profile

Bug #13188

Reinitialize Ruby VM.

Added by joedaniels29 (Joe Daniels) about 2 years ago. Updated almost 2 years ago.

Status:
Rejected
Priority:
Normal
Target version:
-
ruby -v:
2.0.0-p648
[ruby-core:79414]

Description

It appears that by following what appears to be a pretty standard setup procedure:

ruby_init_stack(variable_in_this_stack_frame)
ruby_init();
ruby_init_loadpath();

rb_require("enc/encdb");
rb_require("enc/trans/transdb");
ruby_process_options(Int32(options.count), &cargs)

var state: Int32 = 0;
if ruby_executable_node(node, &state) != 0 {
    state = ruby_exec_node(node)
}
if state != 0 {
    throw RubyError.current
}


ruby_cleanup(state);

Its not possible to recreate the VM. Are there instructions on this process? or is this an actionable task for which contributions from a first time contributor would be accepted?


Related issues

Related to Ruby trunk - Feature #14792: Multiple RubyVM in one process to make real multi-threading.FeedbackActions

History

Updated by shyouhei (Shyouhei Urabe) about 2 years ago

AFAIK the ruby interpreter uses lots of global variables, which makes it practically impossible to re-initialize.

This is of course not a good thing (antique design). I think mruby is much modern here.

Updated by duerst (Martin Dürst) about 2 years ago

Shyouhei Urabe wrote:

AFAIK the ruby interpreter uses lots of global variables, which makes it practically impossible to re-initialize.

How difficult would it be to fix this?

Updated by shyouhei (Shyouhei Urabe) about 2 years ago

Martin Dürst wrote:

Shyouhei Urabe wrote:

AFAIK the ruby interpreter uses lots of global variables, which makes it practically impossible to re-initialize.

How difficult would it be to fix this?

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.

So it is not only very hard to fix, but even when we do so, we have to live with slowness.

Updated by ko1 (Koichi Sasada) about 2 years ago

On 2017/02/06 10:10, shyouhei@ruby-lang.org wrote:

VM-stored pointers

More correctly, thread-local variables (on pthread).

--
// SASADA Koichi at atdot dot net

Updated by normalperson (Eric Wong) about 2 years ago

SASADA Koichi ko1@atdot.net wrote:

On 2017/02/06 10:10, shyouhei@ruby-lang.org wrote:

VM-stored pointers

More correctly, thread-local variables (on pthread).

Was it function call overhead from pthread_getspecific?

Did you try __thread?

I think __thread was GCC-specific, but clang supports it, too;
and we can fall back to existing pthread_getspecific for other
compilers. I think something similar was introduced for C11,
too, but we're still on C89...

But yeah, having VM struct passed with every function call
(like mrb_state in mruby) is probably most portable and fast.

Updated by ko1 (Koichi Sasada) about 2 years ago

On 2017/02/08 7:18, Eric Wong wrote:

But yeah, having VM struct passed with every function call
(like mrb_state in mruby) is probably most portable and fast.

Yes. Ruby 3 will use it.

--
// SASADA Koichi at atdot dot net

Updated by normalperson (Eric Wong) about 2 years ago

SASADA Koichi ko1@atdot.net wrote:

On 2017/02/08 7:18, Eric Wong wrote:

But yeah, having VM struct passed with every function call
(like mrb_state in mruby) is probably most portable and fast.

Yes. Ruby 3 will use it.

Good, but we will still keep a compatibility API for C extensions?

Updated by normalperson (Eric Wong) about 2 years ago

Eric Wong normalperson@yhbt.net wrote:

SASADA Koichi ko1@atdot.net wrote:

On 2017/02/08 7:18, Eric Wong wrote:

But yeah, having VM struct passed with every function call
(like mrb_state in mruby) is probably most portable and fast.

Yes. Ruby 3 will use it.

Good, but we will still keep a compatibility API for C extensions?

Also, can we introducing it in 2.5?
(keeping compatibility API, of course).

Updated by shyouhei (Shyouhei Urabe) about 2 years ago

  • Assignee set to ko1 (Koichi Sasada)
  • Status changed from Open to Assigned

Updated by ko1 (Koichi Sasada) almost 2 years ago

  • Status changed from Assigned to Closed

I close this ticket because we need long-time effort.

Also, can we introducing it in 2.5?
(keeping compatibility API, of course).

If we can.

#11

Updated by usa (Usaku NAKAMURA) almost 2 years ago

  • Status changed from Closed to Rejected
#12

Updated by shyouhei (Shyouhei Urabe) 11 months ago

  • Related to Feature #14792: Multiple RubyVM in one process to make real multi-threading. added

Also available in: Atom PDF