meeting-20080122jp report

Hi,

Sorry for long absence.

I and nobu discussed about MVM (and application embedded feature).

I summurized it on this page:
http://qwik.atdot.net/ruby-mvm/2.html

• Can you accesss above page? (instructions are written in

Japanese, but I believe it can be guessed)

• Do you have any question? comments?
• Are there any discuss of MVM around JRuby? Rubinius?
• How to go ahead with this project?
• Make IRC meeting? Skype meeting?

---

// SASADA Koichi at atdot dot net

SASADA Koichi wrote:

Hi,

Sorry for long absence.

I and nobu discussed about MVM (and application embedded feature).

I summurized it on this page: http://qwik.atdot.net/ruby-mvm/2.html

• Can you accesss above page? (instructions are written in

Japanese, but I believe it can be guessed)

I am able to access it. Instructions were in English (it must be localized).

• Do you have any question? comments?

I will review today. It looks very good!

• Are there any discuss of MVM around JRuby? Rubinius?

As you know JRuby already supports MVM via our integration with Java. So
you can construct a new JRuby instance as follows:

include Java

ruby = org.jruby.Ruby.new_instance

The methods of our Ruby class are then available to be called.

Rubinius has something more explicit, similar to your summary:

(method names may not be right)

vm = VM.spawn("this is like a command line (argv)")
vm.put("some queue name", "some value")
result = vm.take("some queue name")

Putting is asynchronous, and you can only put integral types (numbers,
strings, lists, hashes...).

This seems similar to your summary.

• How to go ahead with this project?

I think we should get Evan on this list to discuss as well. JRuby and
Rubinius already have basic MVM support, so we would like to align API.
And then we can discuss how to make everything work in YARV too.

• Make IRC meeting? Skype meeting?

IRC seems best to me.

• Charlie

Charles Oliver Nutter wrote:

SASADA Koichi wrote:

Hi,

Sorry for long absence.

I and nobu discussed about MVM (and application embedded feature).

I summurized it on this page: http://qwik.atdot.net/ruby-mvm/2.html

• Can you accesss above page? (instructions are written in

Japanese, but I believe it can be guessed)

I am able to access it. Instructions were in English (it must be localized).

I can access it as well.

• Make IRC meeting? Skype meeting?

IRC seems best to me.

IRC is a common tool for most of us.

Using the wiki will also be nice since it is still somewhat interactive
and captures thoughts.

• Tom

• -

Thomas E Enebo <thomas.enebo@s...>
JRuby Core Developer, http://www.bloglines.com/blog/ThomasEEnebo

Hi,

Charles Oliver Nutter wrote:

SASADA Koichi wrote: I am able to access it. Instructions were in English (it must be localized).

Good.

• Are there any discuss of MVM around JRuby? Rubinius?

As you know JRuby already supports MVM via our integration with Java. So you can construct a new JRuby instance as follows:

include Java

ruby = org.jruby.Ruby.new_instance

The methods of our Ruby class are then available to be called.

Rubinius has something more explicit, similar to your summary:

(method names may not be right)

vm = VM.spawn("this is like a command line (argv)") vm.put("some queue name", "some value") result = vm.take("some queue name")

Putting is asynchronous, and you can only put integral types (numbers, strings, lists, hashes...).

This seems similar to your summary.

OK.

• How to go ahead with this project?

I think we should get Evan on this list to discuss as well. JRuby and Rubinius already have basic MVM support, so we would like to align API. And then we can discuss how to make everything work in YARV too.

Evan, do you have any comments on MVM feature? blog entry or
proposal/spec summary documents?

• Make IRC meeting? Skype meeting?

IRC seems best to me.

ok. now, we should sort out issues on ML and make irc meeting.

Thanks!

---

// SASADA Koichi at atdot dot net

Hi,

Thomas Enebo wrote:

Using the wiki will also be nice since it is still somewhat interactive and captures thoughts.

On qwik system, an ML article makes a Wiki page (if there is same
subject page, it will be merged). You can access with link on
signature of posted article.

I hope this system is convinience for you.

---

// SASADA Koichi at atdot dot net

Hello everyone.

Here is a short summary of the MVM features I added to Rubinius.

1) Simple API, creates a new VM from scratch:

  vm = Rubinius::VM.spawn(command_line)

  command_line is processed normally, as though it were a stand alone  

VM.

2) Each VM has an independent ObjectSpace, and each runs in it's own
native thread.
3) There is a single, async message queue for VMs to communicate with:

  Parent does:

  vm << [:hello, "evan"]

  Child VM does:

  mesg = Rubinius::VM.get_message
  p mesg # => [:hello, "evan"]

4) Only integral (primitive) types are allowed in the message queue.
5) Messages between VMs are marshaled, so no pointers are shared.
6) Each VM is assigned an id, just a number, thats used by other VMs
to send

   it messages.

7) STDIN, STDOUT, STDERR of the sub-VM are available at
Rubinius::VM#stdin,

   #stdout, and #stderr. These are pipes.

Thats all that I have right now.

 - Evan

On Jan 23, 2008, at 10:09 AM, SASADA Koichi wrote:

Hi,

Charles Oliver Nutter wrote:

SASADA Koichi wrote: I am able to access it. Instructions were in English (it must be localized).

Good.

• Are there any discuss of MVM around JRuby? Rubinius?

As you know JRuby already supports MVM via our integration with Java. So you can construct a new JRuby instance as follows:

include Java

ruby = org.jruby.Ruby.new_instance

The methods of our Ruby class are then available to be called.

Rubinius has something more explicit, similar to your summary:

(method names may not be right)

vm = VM.spawn("this is like a command line (argv)") vm.put("some queue name", "some value") result = vm.take("some queue name")

Putting is asynchronous, and you can only put integral types (numbers, strings, lists, hashes...).

This seems similar to your summary.

OK.

• How to go ahead with this project?

I think we should get Evan on this list to discuss as well. JRuby and Rubinius already have basic MVM support, so we would like to align API. And then we can discuss how to make everything work in YARV too.

Evan, do you have any comments on MVM feature? blog entry or proposal/spec summary documents?

• Make IRC meeting? Skype meeting?

IRC seems best to me.

ok. now, we should sort out issues on ML and make irc meeting.

Thanks!

• -

// SASADA Koichi at atdot dot net

• -

archive-> http://qwik.atdot.net/ruby-mvm/3.html ML-> ruby-mvm@q...

Hi,

Evan Phoenix wrote:

Here is a short summary of the MVM features I added to Rubinius.

Thanks!

1) Simple API, creates a new VM from scratch:

vm = Rubinius::VM.spawn(command_line)

command_line is processed normally, as though it were a stand alone VM.

How about safe-level or somthing I wrote?

http://qwik.atdot.net/ruby-mvm/2.html

Environment Variables

ARGV

working directory

process id?

signal handling information (mask information)

safe level

class set? (to achieve sand box)

load path?

stdio (stdin, stdout, stderr)

o Ruby level IO (on Ruby API) o System level file descriptor? (on C API)

2) Each VM has an independent ObjectSpace, and each runs in it's own native thread.

3) There is a single, async message queue for VMs to communicate with:

Parent does:

vm << "evan"

Child VM does:

mesg = Rubinius::VM.get_message p mesg # => "evan"

How to access parent VM?

4) Only integral (primitive) types are allowed in the message queue.

What is "integral types"?

5) Messages between VMs are marshaled, so no pointers are shared.

I see. We can optimize it, isn't it?

6) Each VM is assigned an id, just a number, thats used by other VMs to send it messages.

What kind of application use it?

7) STDIN, STDOUT, STDERR of the sub-VM are available at Rubinius::VM#stdin,

So it needs some program to output via normal stdin/out/err. or
reopen it?

Thats all that I have right now.

How about signals?

How about performance of VM creation? Sharing bytecodes?

---

// SASADA Koichi at atdot dot net

one more.

How to separate working directory? Making full path with VM's
working directory? or using openat()?

---

// SASADA Koichi at atdot dot net

On Jan 23, 2008, at 11:59 AM, SASADA Koichi wrote:

Hi,

Evan Phoenix wrote:

Here is a short summary of the MVM features I added to Rubinius.

Thanks!

1) Simple API, creates a new VM from scratch: vm = Rubinius::VM.spawn(command_line) command_line is processed normally, as though it were a stand alone VM.

How about safe-level or somthing I wrote?

Currently, nothing except the command line. You could manipulate the
load path by passing -I to it, but thats all. I plan to add more of
these in the future, but none yet. All of them are easy except process
id and class set.

http://qwik.atdot.net/ruby-mvm/2.html

Environment Variables

ARGV

working directory

process id?

signal handling information (mask information)

safe level

class set? (to achieve sand box)

load path?

stdio (stdin, stdout, stderr)

o Ruby level IO (on Ruby API) o System level file descriptor? (on C API)

2) Each VM has an independent ObjectSpace, and each runs in it's own native thread.

3) There is a single, async message queue for VMs to communicate with: Parent does: vm << "evan" Child VM does: mesg = Rubinius::VM.get_message p mesg # => "evan"

How to access parent VM?

I haven't done this yet, but I'm going to make a constant at
Rubinius::VM::PARENT be the VM id of the parent in each child VM.
Using that VM id, a child can communicate with the parent.

4) Only integral (primitive) types are allowed in the message queue.

What is "integral types"?

Strings, Symbols, Arrays, Numbers, Tuples.

5) Messages between VMs are marshaled, so no pointers are shared.

I see. We can optimize it, isn't it?

Maybe, but special care must be taken to make sure that no pointers
are shared between VMs.

6) Each VM is assigned an id, just a number, thats used by other VMs to send it messages.

What kind of application use it?

This is to communicate between VMs. This is the only way one VM can
reference another VM.

7) STDIN, STDOUT, STDERR of the sub-VM are available at Rubinius::VM#stdin,

So it needs some program to output via normal stdin/out/err. or reopen it?

My thinking was that the parent would read the stdout and print it if
it wanted.

Thats all that I have right now.

How about signals?

No work yet on signals. Not sure how it's going to work.

How about performance of VM creation? Sharing bytecodes?

I don't think we should be concerned with the performance of VM
creation at this point. I have not tested performance, and nothing is
shared between VMs currently.

 - Evan

• -

// SASADA Koichi at atdot dot net

• -

archive-> http://qwik.atdot.net/ruby-mvm/3.html ML-> ruby-mvm@q...

On Jan 23, 2008, at 12:04 PM, SASADA Koichi wrote:

one more.

How to separate working directory? Making full path with VM's working directory? or using openat()?

Whatever the current directory is when the VM is spawned is it's
current directory. Why does that need to be different?

• -

// SASADA Koichi at atdot dot net

• -

archive-> http://qwik.atdot.net/ruby-mvm/3.html ML-> ruby-mvm@q...

Evan Phoenix wrote:

On Jan 23, 2008, at 12:04 PM, SASADA Koichi wrote:

one more.

How to separate working directory? Making full path with VM's working directory? or using openat()?

Whatever the current directory is when the VM is spawned is it's current directory. Why does that need to be different?

In JRuby, current directory is just another field on the runtime/VM. All
file operations are aware of that cwd.

So each JRuby instance can have its own notion of cwd.

What about in your sub vms if they call Dir.chdir? Will it not change
cwd for the whole process?

• Charlie

Evan Phoenix wrote:

1) Simple API, creates a new VM from scratch: vm = Rubinius::VM.spawn(command_line) command_line is processed normally, as though it were a stand alone VM.

How about safe-level or somthing I wrote?

Currently, nothing except the command line. You could manipulate the load path by passing -I to it, but thats all. I plan to add more of these in the future, but none yet. All of them are easy except process id and class set.

In JRuby we do something similar for Kernel#system and Kernel#`: if the
command being run starts with "ruby" or "jruby" as the executable, we
just spin it up in the same JVM under a new JRuby instance. There's no
explicit way to cause this to happen through an MVM API, but it would be
simple to add.

2) Each VM has an independent ObjectSpace, and each runs in it's own native thread.

In JRuby, all VMs are just part of the JVM, so it's the same GC. Also,
native threads can migrate across VMs even within a single call stack,
so there's not really a need for sub-VMs to be explicitly in a separate
thread

How to access parent VM?

I haven't done this yet, but I'm going to make a constant at Rubinius::VM::PARENT be the VM id of the parent in each child VM. Using that VM id, a child can communicate with the parent.

JRuby's MVM support doesn't have any explicit management or
message-passing APIs. VMs are just objects like any other. I'm looking
to these discussions to come up with a standard we can implement too.

I see. We can optimize it, isn't it?

Maybe, but special care must be taken to make sure that no pointers are shared between VMs.

In JRuby objects *could* be passed across VMs, but they all have a
reference to their creating VM. They'd be objects, but not really usable.

What kind of application use it?

This is to communicate between VMs. This is the only way one VM can reference another VM.

To me this seems like the only safe way for two VMs to communicate. I do
not see how the block form (ko1's idea) can be implemented. ko1, can you
explain how?

So it needs some program to output via normal stdin/out/err. or reopen it?

My thinking was that the parent would read the stdout and print it if it wanted.

That's how it typically works in JRuby, though you can choose to give
the sub-VM any streams you want.

No work yet on signals. Not sure how it's going to work.

Same in JRuby, though in JRuby signals are already a little sketchy (we
have to make native calls for them).

How about performance of VM creation? Sharing bytecodes?

I don't think we should be concerned with the performance of VM creation at this point. I have not tested performance, and nothing is shared between VMs currently.

ko1: can you explain why performance of VM creation is important to you?
I can understand shared bytecode....memory savings?

• Charlie

Charles Oliver Nutter wrote:

Evan Phoenix wrote:

2) Each VM has an independent ObjectSpace, and each runs in it's own native thread.

In JRuby, all VMs are just part of the JVM, so it's the same GC. Also, native threads can migrate across VMs even within a single call stack, so there's not really a need for sub-VMs to be explicitly in a separate thread

 We also have independent ObjectSpace's per runtime.

What kind of application use it?

This is to communicate between VMs. This is the only way one VM can reference another VM.

To me this seems like the only safe way for two VMs to communicate. I do not see how the block form (ko1's idea) can be implemented. ko1, can you explain how?

I am also interested in this one. It looks really nice, but I am not
it is safe (and I think it make require making the parser plus other
pieces smarter to recognize cross-VM boundaries.

So it needs some program to output via normal stdin/out/err. or reopen it?

My thinking was that the parent would read the stdout and print it if it wanted.

That's how it typically works in JRuby, though you can choose to give the sub-VM any streams you want.

 Any streams should be a requirement.  I guess we need to go over use 

cases to better understand stuff like this.

No work yet on signals. Not sure how it's going to work.

Same in JRuby, though in JRuby signals are already a little sketchy (we have to make native calls for them).

VM to VM signalling does not need to use regular signals. To me this
is just more message passing and can be implemented any way. The
behavior of a VM recieving these messages is another story.

In general I think we need to create a wiki page which groups use cases
together to make sure we have the same vision of what MVM means. It is
always easier to envision a use first. For JRuby and Rubinius we
already have some aspect of MVM in place, so perhaps we should be the
first to list these.

• Tom

• -

Thomas E Enebo <thomas.enebo@s...>
JRuby Core Developer, http://www.bloglines.com/blog/ThomasEEnebo

Morning.

Evan Phoenix wrote:

Currently, nothing except the command line. You could manipulate the load path by passing -I to it, but thats all. I plan to add more of these in the future, but none yet. All of them are easy except process id and class set.

I see. Maybe pid is not needed.

How to access parent VM?

I haven't done this yet, but I'm going to make a constant at Rubinius::VM::PARENT be the VM id of the parent in each child VM. Using that VM id, a child can communicate with the parent.

Constant or method. Mmm. Are there any constant similar to this one?

4) Only integral (primitive) types are allowed in the message queue.

What is "integral types"?

Strings, Symbols, Arrays, Numbers, Tuples.

• Tuples? Rubinius has tuple?
• sending clone? it seems clone because of including Array.
• What do you think passing dRuby model proxy objects?

5) Messages between VMs are marshaled, so no pointers are shared.

I see. We can optimize it, isn't it?

Maybe, but special care must be taken to make sure that no pointers are shared between VMs.

I see.

6) Each VM is assigned an id, just a number, thats used by other VMs to send it messages.

What kind of application use it?

This is to communicate between VMs. This is the only way one VM can reference another VM.

Yes, I understand.

7) STDIN, STDOUT, STDERR of the sub-VM are available at Rubinius::VM#stdin,

So it needs some program to output via normal stdin/out/err. or reopen it?

My thinking was that the parent would read the stdout and print it if it wanted.

I see. I meant this process as "some program" above.

Thats all that I have right now.

How about signals?

No work yet on signals. Not sure how it's going to work.

What do you think "universal event mechanism"?
http://qwik.atdot.net/ruby-mvm/2.files/RIMG0089.JPG

How about performance of VM creation? Sharing bytecodes?

I don't think we should be concerned with the performance of VM creation at this point. I have not tested performance, and nothing is shared between VMs currently.

Yes. Performance is an advanced issue. I only want to know
performance on naive implementation (and I want to know how fast we
should implement/optimize).

---

// SASADA Koichi at atdot dot net

Charles Oliver Nutter wrote:

How to separate working directory? Making full path with VM's working directory? or using openat()?

Whatever the current directory is when the VM is spawned is it's current directory. Why does that need to be different?

>

In JRuby, current directory is just another field on the runtime/VM. All file operations are aware of that cwd.

So each JRuby instance can have its own notion of cwd.

What about in your sub vms if they call Dir.chdir? Will it not change cwd for the whole process?

If (1) VMs are running with cooperation, we don't need separate cwd.

 But if (2) VMs are running independently, we should separate cwd.

(1) MVM for parallelization or separate namespace, (or sandbox?)

    running 1 application with MVM.

(2) MVM for Multi-application, runnning N applications with N VMs.

    ex) mod_ruby, application embedded ruby, ...

---

// SASADA Koichi at atdot dot net

Afternoon.

On Jan 23, 2008, at 3:01 PM, SASADA Koichi wrote:

Morning.

Evan Phoenix wrote:

Currently, nothing except the command line. You could manipulate the load path by passing -I to it, but thats all. I plan to add more of these in the future, but none yet. All of them are easy except process id and class set.

I see. Maybe pid is not needed.

How to access parent VM?

I haven't done this yet, but I'm going to make a constant at Rubinius::VM::PARENT be the VM id of the parent in each child VM. Using that VM id, a child can communicate with the parent.

Constant or method. Mmm. Are there any constant similar to this one?

Currently, it's a constant. Because a child VM has a completely new
set of constants, it makes sense that the Parent VM is a constant.

4) Only integral (primitive) types are allowed in the message queue.

What is "integral types"?

Strings, Symbols, Arrays, Numbers, Tuples.

• Tuples? Rubinius has tuple?

Yes, it does. They're used to implement everything else.

• sending clone? it seems clone because of including Array.

Marshaled, so yes, the receiver gets a clone of the original.

• What do you think passing dRuby model proxy objects?

Very possible, but I think the way to implement them is to build them
on top of a more simple set. For example, I could implement dRuby
proxy's being passed on top of the code I already have very easily.
This would simply be a higher layer.

5) Messages between VMs are marshaled, so no pointers are shared.

I see. We can optimize it, isn't it?

Maybe, but special care must be taken to make sure that no pointers are shared between VMs.

I see.

6) Each VM is assigned an id, just a number, thats used by other VMs to send it messages.

What kind of application use it?

This is to communicate between VMs. This is the only way one VM can reference another VM.

Yes, I understand.

7) STDIN, STDOUT, STDERR of the sub-VM are available at Rubinius::VM#stdin,

So it needs some program to output via normal stdin/out/err. or reopen it?

My thinking was that the parent would read the stdout and print it if it wanted.

I see. I meant this process as "some program" above.

Thats all that I have right now.

How about signals?

No work yet on signals. Not sure how it's going to work.

What do you think "universal event mechanism"? http://qwik.atdot.net/ruby-mvm/2.files/RIMG0089.JPG

Abstracting the idea of what a Signal is away from it being just being
what Unix means is a good idea. It means that we can get the semantics
right and solid.

How about performance of VM creation? Sharing bytecodes?

I don't think we should be concerned with the performance of VM creation at this point. I have not tested performance, and nothing is shared between VMs currently.

Yes. Performance is an advanced issue. I only want to know performance on naive implementation (and I want to know how fast we should implement/optimize).

Currently, it's probably the slowest thing in Rubinius, because it's
the most work. :)

• -

// SASADA Koichi at atdot dot net

• -

archive-> http://qwik.atdot.net/ruby-mvm/3.html ML-> ruby-mvm@q...

Charles Oliver Nutter wrote:

In JRuby we do something similar for Kernel#system and Kernel#`: if the command being run starts with "ruby" or "jruby" as the executable, we just spin it up in the same JVM under a new JRuby instance. There's no explicit way to cause this to happen through an MVM API, but it would be simple to add.

Does it help fast bootstrap?

2) Each VM has an independent ObjectSpace, and each runs in it's own native thread.

In JRuby, all VMs are just part of the JVM, so it's the same GC. Also, native threads can migrate across VMs even within a single call stack, so there's not really a need for sub-VMs to be explicitly in a separate thread

JRuby/JVM is great!

How to access parent VM?

I haven't done this yet, but I'm going to make a constant at Rubinius::VM::PARENT be the VM id of the parent in each child VM. Using that VM id, a child can communicate with the parent.

JRuby's MVM support doesn't have any explicit management or message-passing APIs. VMs are just objects like any other. I'm looking to these discussions to come up with a standard we can implement too.

I see. We can optimize it, isn't it?

Maybe, but special care must be taken to make sure that no pointers are shared between VMs.

In JRuby objects *could* be passed across VMs, but they all have a reference to their creating VM. They'd be objects, but not really usable.

So passing object invoke creating VM's method.

What kind of application use it?

This is to communicate between VMs. This is the only way one VM can reference another VM.

To me this seems like the only safe way for two VMs to communicate. I do not see how the block form (ko1's idea) can be implemented. ko1, can you explain how?

We discussed about this feature, but we had concluded that it is too
difficult to implement. For example, we can do it with making all
objects of created VMs as proxy object. this should be future (far
future) work.

No work yet on signals. Not sure how it's going to work.

Same in JRuby, though in JRuby signals are already a little sketchy (we have to make native calls for them).

Do you mean making signal support with JNI?

ko1: can you explain why performance of VM creation is important to you?

Fast is good, justice!
...
Some MVM application such as mod_ruby needs fast VM creation, isn't
it? One of the purpose of this research is performance.

I can understand shared bytecode....memory savings?

Yes.

---

// SASADA Koichi at atdot dot net

Evan Phoenix wrote:

• What do you think passing dRuby model proxy objects?

Very possible, but I think the way to implement them is to build them on top of a more simple set. For example, I could implement dRuby proxy's being passed on top of the code I already have very easily. This would simply be a higher layer.

I agree. And I want to expand Inner-Process communication to
Inter-Process communication, Inter-machine communication. ... is it
overkill?

How about signals?

No work yet on signals. Not sure how it's going to work.

What do you think "universal event mechanism"? http://qwik.atdot.net/ruby-mvm/2.files/RIMG0089.JPG

Abstracting the idea of what a Signal is away from it being just being what Unix means is a good idea. It means that we can get the semantics right and solid.

Yes, and it may help embedded ruby.

Currently, it's probably the slowest thing in Rubinius, because it's the most work. :)

I see. Same as first VM bootstrap?

---

// SASADA Koichi at atdot dot net

On Jan 23, 2008, at 3:27 PM, SASADA Koichi wrote:

Evan Phoenix wrote:

• What do you think passing dRuby model proxy objects?

Very possible, but I think the way to implement them is to build them on top of a more simple set. For example, I could implement dRuby proxy's being passed on top of the code I already have very easily. This would simply be a higher layer.

I agree. And I want to expand Inner-Process communication to Inter- Process communication, Inter-machine communication. ... is it overkill?

If we design the communication protocol (ie, right rubinius uses a
form of Marshal), then expanding that protocol to talk between
anything should be easy.

How about signals?

No work yet on signals. Not sure how it's going to work.

What do you think "universal event mechanism"? http://qwik.atdot.net/ruby-mvm/2.files/RIMG0089.JPG

Abstracting the idea of what a Signal is away from it being just being what Unix means is a good idea. It means that we can get the semantics right and solid.

Yes, and it may help embedded ruby.

Currently, it's probably the slowest thing in Rubinius, because it's the most work. :)

I see. Same as first VM bootstrap?

Exactly the same.

• -

// SASADA Koichi at atdot dot net

• -

archive-> http://qwik.atdot.net/ruby-mvm/3.html ML-> ruby-mvm@q...

SASADA Koichi wrote:

Does it help fast bootstrap?

I think I understand more about why you want fast
bootstrapping...discussion is at the bottom of this mail.

So passing object invoke creating VM's method.

Yes, which might appear to work, but for example passing a String from
one VM to another would never since there would be at least two
String classes involved. An object from a given VM will only ever
construct objects owned by that VM.

We discussed about this feature, but we had concluded that it is too difficult to implement. For example, we can do it with making all objects of created VMs as proxy object. this should be future (far future) work.

I'd be comfortable putting that out of scope for early discussions.
Basic MVM management and communication should come first.

Do you mean making signal support with JNI?

Signal suppoer is via both Sun JVM-specific libraries and JNA (Java
Native Access, http://jna.dev.java.net), which is a foreign function
interface for Java.

Some MVM application such as mod_ruby needs fast VM creation, isn't it? One of the purpose of this research is performance.

Ok, I'm starting to understand a bit more...your other email lists two
scenarios:

(1) MVM for parallelization or separate namespace, (or sandbox?)

    running 1 application with MVM.

(2) MVM for Multi-application, runnning N applications with N VMs.

    ex) mod_ruby, application embedded ruby, ...

I see these as two very distinct areas. I don't see why we can't
research into both, but we should recognize this distinction right now.

• Charlie

Thomas Enebo wrote:

In general I think we need to create a wiki page which groups use cases together to make sure we have the same vision of what MVM means. It is always easier to envision a use first. For JRuby and Rubinius we already have some aspect of MVM in place, so perhaps we should be the first to list these.

I agree.

I made a template page.
http://qwik.atdot.net/ruby-mvm/UseCase.html

---

// SASADA Koichi at atdot dot net

Evan Phoenix wrote:

On Jan 23, 2008, at 3:27 PM, SASADA Koichi wrote:

Evan Phoenix wrote:

• What do you think passing dRuby model proxy objects?

Very possible, but I think the way to implement them is to build them on top of a more simple set. For example, I could implement dRuby proxy's being passed on top of the code I already have very easily. This would simply be a higher layer.

I agree. And I want to expand Inner-Process communication to Inter-Process communication, Inter-machine communication. ... is it overkill?

If we design the communication protocol (ie, right rubinius uses a form of Marshal), then expanding that protocol to talk between anything should be easy.

I think it's way, way out of scope to consider RPC mechanisms in this
API. RPC has been reinvented 100 times, and I do not want to be the
author of the 101st failure. We should focus directly on what makes
sense for "inner vm" communication within a given process, and leave RPC
to people who have failed many times already.

• Charlie

Hi,

Charles Oliver Nutter wrote:

I think it's way, way out of scope to consider RPC mechanisms in this API. RPC has been reinvented 100 times, and I do not want to be the author of the 101st failure. We should focus directly on what makes sense for "inner vm" communication within a given process, and leave RPC to people who have failed many times already.

OK, I understand. Could you fill usecase of MVM?
http://qwik.atdot.net/ruby-mvm/UseCase.html

---

// SASADA Koichi at atdot dot net

SASADA Koichi wrote:

Hi,

Charles Oliver Nutter wrote:

I think it's way, way out of scope to consider RPC mechanisms in this API. RPC has been reinvented 100 times, and I do not want to be the author of the 101st failure. We should focus directly on what makes sense for "inner vm" communication within a given process, and leave RPC to people who have failed many times already.

OK, I understand. Could you fill usecase of MVM? http://qwik.atdot.net/ruby-mvm/UseCase.html

I added a few updates. Please ask me if you have questions.

• Charlie

Hi,

Charles Oliver Nutter wrote:

I added a few updates. Please ask me if you have questions.

Thanks.

Performance and scaling requirements should be considered separately from functional requirements; they address different areas and are largely orthogonal.

I agree.

BTW, what is "CON"?(english question)

---

// SASADA Koichi at atdot dot net

SASADA Koichi wrote:

Hi,

Charles Oliver Nutter wrote:

I added a few updates. Please ask me if you have questions.

Thanks.

Performance and scaling requirements should be considered separately from functional requirements; they address different areas and are largely orthogonal.

I agree.

BTW, what is "CON"?(english question)

CON = Charles Oliver Nutter

• Tom

Thomas Enebo wrote:

BTW, what is "CON"?(english question)

CON = Charles Oliver Nutter

Ah. I had imaged CONsole or CONs.

---

// SASADA Koichi at atdot dot net