How hard would it be for the new VM to run two images at once?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

How hard would it be for the new VM to run two images at once?

Louis LaBrunda
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Seth Berman
Greetings Lou,

Thank you for the feedback.  We have been very pleased by stability of the new virtual machines out in the field.
We know of many customers who have been successfully moving their systems forward, so we're happy.

Now to your question:
"How hard would it be for the new VM to run two images at once?"
- It's difficult to answer because I would think a lot of this depends on what we specifically mean by "run".

  One can already launch multiple images and have them communicate.  Depending on how far you would like to
  take it, you could arrange it so that the communication channel is quite efficient.  

  So is the goal to just have everything
  in one OS process?  And if so, for what reason exactly?

Kind Regards,

- Seth


On Tuesday, March 20, 2018 at 9:46:21 AM UTC-4, Louis LaBrunda wrote:
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

jtuchel
In reply to this post by Louis LaBrunda
Lou,


I wonder why you think the VM running 2 or more images allows for efficient use of multiple CPUs or Cores? In my naive mind, the VM is the bottleneck here...?

Joachim



Am Dienstag, 20. März 2018 14:46:21 UTC+1 schrieb Louis LaBrunda:
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Louis LaBrunda
Hi Seth and Joachim,

You both raise good questions.  I'm thinking that the VM running 2 or more images allows for efficient use of multiple CPUs or Cores but I have no real idea why I should think this other than one program would have access to everything including what the images would want to share.  This may be completely without merit.  But that is why I ask these kinds of questions.

Lou



On Tuesday, March 20, 2018 at 1:00:27 PM UTC-4, Joachim Tuchel wrote:
Lou,


I wonder why you think the VM running 2 or more images allows for efficient use of multiple CPUs or Cores? In my naive mind, the VM is the bottleneck here...?

Joachim



Am Dienstag, 20. März 2018 14:46:21 UTC+1 schrieb Louis LaBrunda:
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Seth Berman
Hi Lou,

It's certainly not a bad question.  Many languages seek to solve this very important issue in different ways.
I know questions like this have been asked in other posts so it may be worth searching on.
It's really the question of a shared object heap (or global vm state) that makes this difficult.  Neither the vm
or the smalltalk image code (i.e. Collections) would be prepared to deal with multiple executions operating on them
at the same time.
So one way or another, you would really need to maintain separate heaps for each execution unit.  Perhaps some
part of it could be shared memory or perhaps just efficient communication channels.
But this can be accomplished via separate OS processes.

-- Seth


On Tuesday, March 20, 2018 at 6:21:18 PM UTC-4, Louis LaBrunda wrote:
Hi Seth and Joachim,

You both raise good questions.  I'm thinking that the VM running 2 or more images allows for efficient use of multiple CPUs or Cores but I have no real idea why I should think this other than one program would have access to everything including what the images would want to share.  This may be completely without merit.  But that is why I ask these kinds of questions.

Lou



On Tuesday, March 20, 2018 at 1:00:27 PM UTC-4, Joachim Tuchel wrote:
Lou,


I wonder why you think the VM running 2 or more images allows for efficient use of multiple CPUs or Cores? In my naive mind, the VM is the bottleneck here...?

Joachim



Am Dienstag, 20. März 2018 14:46:21 UTC+1 schrieb Louis LaBrunda:
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Louis LaBrunda
Hi Seth,

Now you are getting to what I was thinking.  Each image would have its own copy of the memory "areas" (like old memory, new memory, I will let you list them all if you like) that a single image has now.  And as you say there can be a "shared memory area" that was what I was alluding to with communicate with each other through a primitive.

I don't think this is the perfect solution to any particular problem but it may be an "inexpensive" solution to something like load balancing with a Seaside program that doesn't require some front end system to direct traffic to separate VA Smalltalk programs.

Lou
 
On Wednesday, March 21, 2018 at 10:13:56 AM UTC-4, Seth Berman wrote:
Hi Lou,

It's certainly not a bad question.  Many languages seek to solve this very important issue in different ways.
I know questions like this have been asked in other posts so it may be worth searching on.
It's really the question of a shared object heap (or global vm state) that makes this difficult.  Neither the vm
or the smalltalk image code (i.e. Collections) would be prepared to deal with multiple executions operating on them
at the same time.
So one way or another, you would really need to maintain separate heaps for each execution unit.  Perhaps some
part of it could be shared memory or perhaps just efficient communication channels.
But this can be accomplished via separate OS processes.

-- Seth


On Tuesday, March 20, 2018 at 6:21:18 PM UTC-4, Louis LaBrunda wrote:
Hi Seth and Joachim,

You both raise good questions.  I'm thinking that the VM running 2 or more images allows for efficient use of multiple CPUs or Cores but I have no real idea why I should think this other than one program would have access to everything including what the images would want to share.  This may be completely without merit.  But that is why I ask these kinds of questions.

Lou



On Tuesday, March 20, 2018 at 1:00:27 PM UTC-4, Joachim Tuchel wrote:
Lou,


I wonder why you think the VM running 2 or more images allows for efficient use of multiple CPUs or Cores? In my naive mind, the VM is the bottleneck here...?

Joachim



Am Dienstag, 20. März 2018 14:46:21 UTC+1 schrieb Louis LaBrunda:
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Seth Berman
Hi Lou,

The "shared memory" area can work...but there are still a lot of considerations in a memory-managed environment that make it non-trivial in the general case of objects.
For example, some immediate questions I would have are...
Who accepts responsibility for freeing this shared object when it's no longer in use? 
If it's not the user, how does the program establish the shared object is no longer in use?
If it is the user, then I just assume we are introducing unsafe behavior into a virtual machine which is supposed to provide certain protections for objects.
What if this shared object points to other non-shared objects in one of many potential heap spaces...what does book-keeping for that look like?
How is the program telling non-shared objects not to be garbage collected when all intra-heap references are gone, but shared refs still remain?

This all reminds me of some of the SST distributed garbage collection components which set out to solve some non trivial problems.

Now if all you want to do is share some "bytes"...maybe just things like byte arrays or strings that basically don't point to other objects...some of these issues might go away.
But that seems awfully limiting...and then again...who establishes that your done with some "bytes"?

Not sure how inexpensive this endeavor might be:) I guess it just depends on what exactly your trying to do.

-- Seth

On Thursday, March 22, 2018 at 8:43:56 AM UTC-4, Louis LaBrunda wrote:
Hi Seth,

Now you are getting to what I was thinking.  Each image would have its own copy of the memory "areas" (like old memory, new memory, I will let you list them all if you like) that a single image has now.  And as you say there can be a "shared memory area" that was what I was alluding to with communicate with each other through a primitive.

I don't think this is the perfect solution to any particular problem but it may be an "inexpensive" solution to something like load balancing with a Seaside program that doesn't require some front end system to direct traffic to separate VA Smalltalk programs.

Lou
 
On Wednesday, March 21, 2018 at 10:13:56 AM UTC-4, Seth Berman wrote:
Hi Lou,

It's certainly not a bad question.  Many languages seek to solve this very important issue in different ways.
I know questions like this have been asked in other posts so it may be worth searching on.
It's really the question of a shared object heap (or global vm state) that makes this difficult.  Neither the vm
or the smalltalk image code (i.e. Collections) would be prepared to deal with multiple executions operating on them
at the same time.
So one way or another, you would really need to maintain separate heaps for each execution unit.  Perhaps some
part of it could be shared memory or perhaps just efficient communication channels.
But this can be accomplished via separate OS processes.

-- Seth


On Tuesday, March 20, 2018 at 6:21:18 PM UTC-4, Louis LaBrunda wrote:
Hi Seth and Joachim,

You both raise good questions.  I'm thinking that the VM running 2 or more images allows for efficient use of multiple CPUs or Cores but I have no real idea why I should think this other than one program would have access to everything including what the images would want to share.  This may be completely without merit.  But that is why I ask these kinds of questions.

Lou



On Tuesday, March 20, 2018 at 1:00:27 PM UTC-4, Joachim Tuchel wrote:
Lou,


I wonder why you think the VM running 2 or more images allows for efficient use of multiple CPUs or Cores? In my naive mind, the VM is the bottleneck here...?

Joachim



Am Dienstag, 20. März 2018 14:46:21 UTC+1 schrieb Louis LaBrunda:
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Louis LaBrunda
Hi Seth,

I don't know if you can tell but I am more interested in the discussion than I am in trying to get it to go in any particular direction.  So, forgive me for not being able to say "I want to achieve X".  I did say "shared memory" but maybe a shared connection is a better place to start.  Maybe it can do slightly more than pass bytes but once passed the originating image no-longer has an knowledge of or even interest in the data/object passed.

Again, I don't NEED to solve any particular problem but as an example, I do have a bunch of images that are all different and communicate with each other via serialized objects sent over a TCP/IP connection.  This can be very slow.  If two different images, running in the same VM could pass data/objects back and forth, maybe without serializing, that would be cool.

This could probably also work for the Seaside program with two or more copies of the same image, where one image gets all connections and then passes them off to another image.

Lou

On Thursday, March 22, 2018 at 11:37:33 AM UTC-4, Seth Berman wrote:
Hi Lou,

The "shared memory" area can work...but there are still a lot of considerations in a memory-managed environment that make it non-trivial in the general case of objects.
For example, some immediate questions I would have are...
Who accepts responsibility for freeing this shared object when it's no longer in use? 
If it's not the user, how does the program establish the shared object is no longer in use?
If it is the user, then I just assume we are introducing unsafe behavior into a virtual machine which is supposed to provide certain protections for objects.
What if this shared object points to other non-shared objects in one of many potential heap spaces...what does book-keeping for that look like?
How is the program telling non-shared objects not to be garbage collected when all intra-heap references are gone, but shared refs still remain?

This all reminds me of some of the SST distributed garbage collection components which set out to solve some non trivial problems.

Now if all you want to do is share some "bytes"...maybe just things like byte arrays or strings that basically don't point to other objects...some of these issues might go away.
But that seems awfully limiting...and then again...who establishes that your done with some "bytes"?

Not sure how inexpensive this endeavor might be:) I guess it just depends on what exactly your trying to do.

-- Seth

On Thursday, March 22, 2018 at 8:43:56 AM UTC-4, Louis LaBrunda wrote:
Hi Seth,

Now you are getting to what I was thinking.  Each image would have its own copy of the memory "areas" (like old memory, new memory, I will let you list them all if you like) that a single image has now.  And as you say there can be a "shared memory area" that was what I was alluding to with communicate with each other through a primitive.

I don't think this is the perfect solution to any particular problem but it may be an "inexpensive" solution to something like load balancing with a Seaside program that doesn't require some front end system to direct traffic to separate VA Smalltalk programs.

Lou
 
On Wednesday, March 21, 2018 at 10:13:56 AM UTC-4, Seth Berman wrote:
Hi Lou,

It's certainly not a bad question.  Many languages seek to solve this very important issue in different ways.
I know questions like this have been asked in other posts so it may be worth searching on.
It's really the question of a shared object heap (or global vm state) that makes this difficult.  Neither the vm
or the smalltalk image code (i.e. Collections) would be prepared to deal with multiple executions operating on them
at the same time.
So one way or another, you would really need to maintain separate heaps for each execution unit.  Perhaps some
part of it could be shared memory or perhaps just efficient communication channels.
But this can be accomplished via separate OS processes.

-- Seth


On Tuesday, March 20, 2018 at 6:21:18 PM UTC-4, Louis LaBrunda wrote:
Hi Seth and Joachim,

You both raise good questions.  I'm thinking that the VM running 2 or more images allows for efficient use of multiple CPUs or Cores but I have no real idea why I should think this other than one program would have access to everything including what the images would want to share.  This may be completely without merit.  But that is why I ask these kinds of questions.

Lou



On Tuesday, March 20, 2018 at 1:00:27 PM UTC-4, Joachim Tuchel wrote:
Lou,


I wonder why you think the VM running 2 or more images allows for efficient use of multiple CPUs or Cores? In my naive mind, the VM is the bottleneck here...?

Joachim



Am Dienstag, 20. März 2018 14:46:21 UTC+1 schrieb Louis LaBrunda:
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Seth Berman
Hi Lou,

I think its better to think of an object in these discussions as a complex graph rather than a single datum.
The discussion is too over-simplified if we just talk about a data/object being passed around .  We're back to the "bytes" example and I don't have much to contribute here.
Presumably this object refers to other objects.  Probably other objects refer to this object...and if not then we probably expect this object to go away.

So I would think the discussion would need to begin with a clear understanding of what is meant by "sharing an object"...because we are really talking about "sharing an object graph which other things may refer to".
I think this orientation leads one to ask the appropriate questions when considering various approaches...and ultimately a worthwhile discussion.

For example, you mentioned "but once passed the originating image no-longer has a knowledge of or even interest in the data/object passed".
If I were to think of an object as this standalone non-dependent thing...then what you suggest is very easy for me to imagine.
But now let's replace "data/object" with "object graph that other objects may refer to" and re-read.
When I read it this way...the first question that stands out to me is "So is it implied that we have to transfer the whole object graph?"
Yes...ok well that might be a lot.  And then of course, the details of how to correctly and efficiently vacate an object graph in mid execution (that other objects might be referring to some portion of) from one place to another we will just leave because that's currently too painful for me to imagine:)
No...now one would have to address some of my previous questions concerning share semantics.  One part of the graph in one place and the other part in another place....and wrapped around it is a memory management program that is trying to figure out who still needs to be there.

Unfortunately, unless we are talking about a theoretical execution engine, this is one of those areas where the detail is not desired...but it's also not escapable.
Otherwise the discussion will quickly degenerate into  "well, that would be nice if it worked that way".

I think some of your points have been good and in the right direction.
I would be curious to hear some of your suggestions if you mentally swap out "data/object" with "object graph that others objects might refer to some part of".

- Seth



On Thursday, March 22, 2018 at 3:18:10 PM UTC-4, Louis LaBrunda wrote:
Hi Seth,

I don't know if you can tell but I am more interested in the discussion than I am in trying to get it to go in any particular direction.  So, forgive me for not being able to say "I want to achieve X".  I did say "shared memory" but maybe a shared connection is a better place to start.  Maybe it can do slightly more than pass bytes but once passed the originating image no-longer has an knowledge of or even interest in the data/object passed.

Again, I don't NEED to solve any particular problem but as an example, I do have a bunch of images that are all different and communicate with each other via serialized objects sent over a TCP/IP connection.  This can be very slow.  If two different images, running in the same VM could pass data/objects back and forth, maybe without serializing, that would be cool.

This could probably also work for the Seaside program with two or more copies of the same image, where one image gets all connections and then passes them off to another image.

Lou

On Thursday, March 22, 2018 at 11:37:33 AM UTC-4, Seth Berman wrote:
Hi Lou,

The "shared memory" area can work...but there are still a lot of considerations in a memory-managed environment that make it non-trivial in the general case of objects.
For example, some immediate questions I would have are...
Who accepts responsibility for freeing this shared object when it's no longer in use? 
If it's not the user, how does the program establish the shared object is no longer in use?
If it is the user, then I just assume we are introducing unsafe behavior into a virtual machine which is supposed to provide certain protections for objects.
What if this shared object points to other non-shared objects in one of many potential heap spaces...what does book-keeping for that look like?
How is the program telling non-shared objects not to be garbage collected when all intra-heap references are gone, but shared refs still remain?

This all reminds me of some of the SST distributed garbage collection components which set out to solve some non trivial problems.

Now if all you want to do is share some "bytes"...maybe just things like byte arrays or strings that basically don't point to other objects...some of these issues might go away.
But that seems awfully limiting...and then again...who establishes that your done with some "bytes"?

Not sure how inexpensive this endeavor might be:) I guess it just depends on what exactly your trying to do.

-- Seth

On Thursday, March 22, 2018 at 8:43:56 AM UTC-4, Louis LaBrunda wrote:
Hi Seth,

Now you are getting to what I was thinking.  Each image would have its own copy of the memory "areas" (like old memory, new memory, I will let you list them all if you like) that a single image has now.  And as you say there can be a "shared memory area" that was what I was alluding to with communicate with each other through a primitive.

I don't think this is the perfect solution to any particular problem but it may be an "inexpensive" solution to something like load balancing with a Seaside program that doesn't require some front end system to direct traffic to separate VA Smalltalk programs.

Lou
 
On Wednesday, March 21, 2018 at 10:13:56 AM UTC-4, Seth Berman wrote:
Hi Lou,

It's certainly not a bad question.  Many languages seek to solve this very important issue in different ways.
I know questions like this have been asked in other posts so it may be worth searching on.
It's really the question of a shared object heap (or global vm state) that makes this difficult.  Neither the vm
or the smalltalk image code (i.e. Collections) would be prepared to deal with multiple executions operating on them
at the same time.
So one way or another, you would really need to maintain separate heaps for each execution unit.  Perhaps some
part of it could be shared memory or perhaps just efficient communication channels.
But this can be accomplished via separate OS processes.

-- Seth


On Tuesday, March 20, 2018 at 6:21:18 PM UTC-4, Louis LaBrunda wrote:
Hi Seth and Joachim,

You both raise good questions.  I'm thinking that the VM running 2 or more images allows for efficient use of multiple CPUs or Cores but I have no real idea why I should think this other than one program would have access to everything including what the images would want to share.  This may be completely without merit.  But that is why I ask these kinds of questions.

Lou



On Tuesday, March 20, 2018 at 1:00:27 PM UTC-4, Joachim Tuchel wrote:
Lou,


I wonder why you think the VM running 2 or more images allows for efficient use of multiple CPUs or Cores? In my naive mind, the VM is the bottleneck here...?

Joachim



Am Dienstag, 20. März 2018 14:46:21 UTC+1 schrieb Louis LaBrunda:
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Richard Sargent
Administrator
In reply to this post by Louis LaBrunda
On Tuesday, March 20, 2018 at 6:46:21 AM UTC-7, Louis LaBrunda wrote:
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Hi Lou,

These are interesting thoughts, but I think they probably take you in the wrong direction(*). Without trying to direct you away from VA Smalltalk, I suggest you examine GemStone/S. It's model is multiple VMs running against a shared image with transactional semantics. (The database *is* the image.) So, one spins up as many running VMs as make sense for the application / load. This utilizes as many CPUs and separate machines as you want, without having the data get away from you.

If you want to follow up on this, let's spin off a separate thread rather than derail this one.
 


(*) By wrong direction, I mean that the added complexity to make one running VM deal safely with multiple images would make for a complicated and - in my opinion - fragile solution.


Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Marten Feldtmann-5
I would also follow your suggestion ... keep the VMs isolated doing their job ... add very fast interprocess technology between these images and let them communicate e.g. via a suitable SST-AddOn.

If you do not want to go via shared memory (which may be fast, but may also produce problems and is not friendly to other languages) you may use libraries like 0MQ (which has the benefit to do the communication stuff in an external C thread and opens your tool for other languages) and then look for an appropiate programming model in Smalltalk and that's the biggest problem.

Marten




Am Freitag, 23. März 2018 17:27:19 UTC+1 schrieb Richard Sargent:
On Tuesday, March 20, 2018 at 6:46:21 AM UTC-7, Louis LaBrunda wrote:
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Hi Lou,

These are interesting thoughts, but I think they probably take you in the wrong direction(*). Without trying to direct you away from VA Smalltalk, I suggest you examine GemStone/S. It's model is multiple VMs running against a shared image with transactional semantics. (The database *is* the image.) So, one spins up as many running VMs as make sense for the application / load. This utilizes as many CPUs and separate machines as you want, without having the data get away from you.

If you want to follow up on this, let's spin off a separate thread rather than derail this one.
 


(*) By wrong direction, I mean that the added complexity to make one running VM deal safely with multiple images would make for a complicated and - in my opinion - fragile solution.


Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Seth Berman
Hi Lou,

I echo Marten and Richard if you have an actual problem to solve.
If your more interested in the fundamental discussion, which may have been my assumption, then you have my thoughts:)

- Seth

On Friday, March 23, 2018 at 12:44:04 PM UTC-4, Marten Feldtmann wrote:
I would also follow your suggestion ... keep the VMs isolated doing their job ... add very fast interprocess technology between these images and let them communicate e.g. via a suitable SST-AddOn.

If you do not want to go via shared memory (which may be fast, but may also produce problems and is not friendly to other languages) you may use libraries like 0MQ (which has the benefit to do the communication stuff in an external C thread and opens your tool for other languages) and then look for an appropiate programming model in Smalltalk and that's the biggest problem.

Marten




Am Freitag, 23. März 2018 17:27:19 UTC+1 schrieb Richard Sargent:
On Tuesday, March 20, 2018 at 6:46:21 AM UTC-7, Louis LaBrunda wrote:
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Hi Lou,

These are interesting thoughts, but I think they probably take you in the wrong direction(*). Without trying to direct you away from VA Smalltalk, I suggest you examine GemStone/S. It's model is multiple VMs running against a shared image with transactional semantics. (The database *is* the image.) So, one spins up as many running VMs as make sense for the application / load. This utilizes as many CPUs and separate machines as you want, without having the data get away from you.

If you want to follow up on this, let's spin off a separate thread rather than derail this one.
 


(*) By wrong direction, I mean that the added complexity to make one running VM deal safely with multiple images would make for a complicated and - in my opinion - fragile solution.


Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Louis LaBrunda
Hi Seth, Marten and Richard,

I really don't have an actual problem to solve.  This is not a case of necessity being the mother of invention but more like inventing something and looking around for a problem.  In general, I like the idea of improving VA Smalltalk.  For some unknown reason the idea of the VM running more than one image popped into my head.  It was/is my uneducated guess that running multiple images that didn't share much if anything wouldn't be too hard.  I expect the range of difficulty for sharing little or nothing to sharing a lot goes from not too difficult to extremely difficult.  Once one has some understanding of the costs and benefits one might be able to find a sweet spot where the benefit is of some value and the cost is low.  I expect this is on the low end of how much gets shared.

To address Seth's previous request "I would be curious to hear some of your suggestions if you mentally swap out "data/object" with "object graph that others objects might refer to some part of".", unfortunately I haven't thought about this much and my formal education in this area ended in the early 1970's and I haven't been able to keep up with much of it.

I don't want to take up much of anyones time with this.  If anyone has a few minutes to contribute to the discussion, that's great, if not, that's fine too.

Lou



On Friday, March 23, 2018 at 12:54:03 PM UTC-4, Seth Berman wrote:
Hi Lou,

I echo Marten and Richard if you have an actual problem to solve.
If your more interested in the fundamental discussion, which may have been my assumption, then you have my thoughts:)

- Seth

On Friday, March 23, 2018 at 12:44:04 PM UTC-4, Marten Feldtmann wrote:
I would also follow your suggestion ... keep the VMs isolated doing their job ... add very fast interprocess technology between these images and let them communicate e.g. via a suitable SST-AddOn.

If you do not want to go via shared memory (which may be fast, but may also produce problems and is not friendly to other languages) you may use libraries like 0MQ (which has the benefit to do the communication stuff in an external C thread and opens your tool for other languages) and then look for an appropiate programming model in Smalltalk and that's the biggest problem.

Marten




Am Freitag, 23. März 2018 17:27:19 UTC+1 schrieb Richard Sargent:
On Tuesday, March 20, 2018 at 6:46:21 AM UTC-7, Louis LaBrunda wrote:
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Hi Lou,

These are interesting thoughts, but I think they probably take you in the wrong direction(*). Without trying to direct you away from VA Smalltalk, I suggest you examine GemStone/S. It's model is multiple VMs running against a shared image with transactional semantics. (The database *is* the image.) So, one spins up as many running VMs as make sense for the application / load. This utilizes as many CPUs and separate machines as you want, without having the data get away from you.

If you want to follow up on this, let's spin off a separate thread rather than derail this one.
 


(*) By wrong direction, I mean that the added complexity to make one running VM deal safely with multiple images would make for a complicated and - in my opinion - fragile solution.


Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Marten Feldtmann-5
Louis,

this discussion is actually a very important discussion - the main idea behind it is to get access to lots of cores - but it also open a question of the future of this product.

Regarding the main idea: what is a suitable programming model and comfortable development model ? I think, that NO Smalltalk system available offers a good solution here - even the multi-core-attempts of Cincom are only a start here.

I would not mind to start 5 vm's running on one machine to produce a solution for a customer, even with the IC technology the system could share the same source code between the running VMs. It more or less depends on a very good network connection between these images.

For me, when staying with VA, the direction is clear - multi core support with good network support, very fast way to create server application (headless apps) with connectivity against a UI written in a totally different system (actually I would prefer Election based systems - or local HTML5 based UI, served by VA).

But this is totally unimportant for the already existing customers ... and I am not sure, where the new customers should come from. And the multi-language programming paradigm I suggest above is perhaps not very good for marketing reasons.




--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Marten Feldtmann-5
We do this kind of development right now with Gemstone and at least with the UI (written in Javascript either in a browser or Election based) I am more than satisfied with the results we can offer our customers.

The problem is the programming model - and here we go the strictly API oriented way, which needs lots of development infrastructure and lots of work in front of our first product.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

jtuchel
In reply to this post by Marten Feldtmann-5
Marten,

I agree that starting a number of VMs and Images is not a problem at all. In fact, that is what most scalable solutions do. A big plus is that if one image goes crazy and crashes, only this one image/vm combo is affected.
I'd also say that a fast, reliable and - most imprtantly - out-of-the box communication protocol is key here. Some boilerplate code and a first steps tutorial and a simple demo implementation, be it on top of bare HTTP or some protocol like 0MQ or MQTT would make life easier.

Other platforms are not necessarily better in what they do. They just offer a very easy start.

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Marten Feldtmann-5
Yes, that's correct ...

 Marten

Am Sonntag, 25. März 2018 09:41:01 UTC+2 schrieb Joachim Tuchel:

Other platforms are not necessarily better in what they do. They just offer a very easy start.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

jtuchel
Let's put it that way: if a piece of software makes the first steps easy, people will most likely just use it, even if things get more complicated later. It is accepted that things get harder once you want to do real stuff. But the start must be easy.

In most Smalltalks, things are the other way round: you can do everything and once you've sorted out the technical difficulties, you are even more productive and faster than other platforms. But getting there is hard and a lot of work. You need to figure out how to support some basic protocols and almost surely have to implement some of this stuff before you can start your first sample. What is a developer supposed to think how hard thing might be if the start is that much work already...?

So we don't probably need the best possible solution for scalability (although it wouldn't hurt, obviously), what we need is some easy to setup starting point and current protocols out of the box.

Sorry, Lou, if this is more or less off-topic ;-) But I think something like MatriX/Polycephaly on top of Sst with some sample code and good documentation would lift us a good step up. Sure, if VMs could offer some help in making better use of multiple cores, this would possibly give us even more bang for our bucks, but some image-level code on top of that would be needed anyways.

Sst is like a box of legos from the eighties: there are 2-pieces, 4-pieces and bigger ones. Some are transparent. But that's all there is. You can do lots of stuff with them, but your are more or less left to your own research. The code is complicated (or you could say: highly flexible) and hard to understand. It offers all that's needed for communicating between images, there even is the groundwork for distributed objects. It is just not easy to find out how to do things with it. We've implemented REST servers and clients in almost no time, but we had to experiment and find our way on our own. This could be the basis for a simple inter-image communication protocol. As could the object distribution thing.
Same for ESMTP. There is basic IMAP support, but no sample mail client that you could use as a starting point.

So VAST and Sst are a raw diamond which offers all that's needed for a competitor to MatriX or similar models. It's the final steps that are missing.

Joachim





 

Am Sonntag, 25. März 2018 09:57:03 UTC+2 schrieb Marten Feldtmann:
Yes, that's correct ...

 Marten

Am Sonntag, 25. März 2018 09:41:01 UTC+2 schrieb Joachim Tuchel:

Other platforms are not necessarily better in what they do. They just offer a very easy start.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Richard Sargent
Administrator
In reply to this post by Louis LaBrunda
On Saturday, March 24, 2018 at 7:17:20 AM UTC-7, Louis LaBrunda wrote:
Hi Seth, Marten and Richard,

I really don't have an actual problem to solve.  This is not a case of necessity being the mother of invention but more like inventing something and looking around for a problem.  In general, I like the idea of improving VA Smalltalk. 


This is the critical statement:
 
For some unknown reason the idea of the VM running more than one image popped into my head. 

Allow me to share some superb advice I read nearly 30 years. (I think it was in the 1989 Software Development magazine, in a column by P.J.Plauger of Whitesmith C renown.)

Plauger described something he called the "0, 1, Infinity Rule". I have used this design rule assiduously ever since, with great result. In essence, he explained that there are things you exclude from your model simply because they aren't a part of it. These are the zero. They don't occur. Then there are the things that you can only have one of. Social Security Number is a reasonably useful example, with the simplification that "everyone has one". (That's not really true, but we'll work with that for this explanation.) Last, there are things that have an arbitrary number, such as children, parents, cars, drivers, etc. The best designs always model these as having an unlimited number of occurrences. (Unlimited at least from the program's perspective. Database, memory, etc. might impose some absolute limit. As long as it isn't imposed by the program logic, you'll be fine.)

If we look at a VM running a single image, we have a number of elements involved: VM code, DLLs, caches, image memory, perhaps more, but this will do for now. To give you a handle on these, GemStone's VM allocates a number of caches by default from one cache size declaration. The total of all the caches, memory allocations, whatever, works out to about 3.3x that one parameter's declared size. The VM code adds more, but the actual fraction of that really depends on the size of the caches. Except for extremely small images, the memory needs of the VM itself will be pretty small.

This brings me to the point: if we were to make one running VM run multiple images, we have a huge step function in terms of making the VM go from modelling a single image to modelling multiple. But modern operating systems will share the code of the VM and any DLLs (shared libraries, etc.) when running multiple processes using the same executable. It might be possible, with a lot of effort (in my opinion), to make some of the caches common for all the running images. I am doubtful of that; certainly the risk of errors screwing up everything is much higher.

I don't see anything that having one running VM support multiple concurrent images will actually offer any benefit for the substantial cost required to create that ability.


Separately, there was the question of communicating between the images. There was discussion of 0MQ, sockets, shared memory segments, etc. On Linux at least, sockets on the same machine are memory based and don't go through the network. In some respects, sockets are one of the best ways to share data, since you can scale nearly infinitely (there's that 0, 1, ∞ rule once again). I don't know anything about 0MQ, other than its name and existence, but I would guess it is socket-based and scales the same way. These techniques do impose an overhead in serializing the data being transferred.  Shared memory offers the potential for the VM to read and write it using the image memory format, thereby making it look like a part of the image. Of course, you need some external gatekeeper to control access to the shared resource; something like OS semaphores, for example.


 
It was/is my uneducated guess that running multiple images that didn't share much if anything wouldn't be too hard.  I expect the range of difficulty for sharing little or nothing to sharing a lot goes from not too difficult to extremely difficult.  Once one has some understanding of the costs and benefits one might be able to find a sweet spot where the benefit is of some value and the cost is low.  I expect this is on the low end of how much gets shared.

To address Seth's previous request "I would be curious to hear some of your suggestions if you mentally swap out "data/object" with "object graph that others objects might refer to some part of".", unfortunately I haven't thought about this much and my formal education in this area ended in the early 1970's and I haven't been able to keep up with much of it.

I don't want to take up much of anyones time with this.  If anyone has a few minutes to contribute to the discussion, that's great, if not, that's fine too.

Lou



On Friday, March 23, 2018 at 12:54:03 PM UTC-4, Seth Berman wrote:
Hi Lou,

I echo Marten and Richard if you have an actual problem to solve.
If your more interested in the fundamental discussion, which may have been my assumption, then you have my thoughts:)

- Seth

On Friday, March 23, 2018 at 12:44:04 PM UTC-4, Marten Feldtmann wrote:
I would also follow your suggestion ... keep the VMs isolated doing their job ... add very fast interprocess technology between these images and let them communicate e.g. via a suitable SST-AddOn.

If you do not want to go via shared memory (which may be fast, but may also produce problems and is not friendly to other languages) you may use libraries like 0MQ (which has the benefit to do the communication stuff in an external C thread and opens your tool for other languages) and then look for an appropiate programming model in Smalltalk and that's the biggest problem.

Marten




Am Freitag, 23. März 2018 17:27:19 UTC+1 schrieb Richard Sargent:
On Tuesday, March 20, 2018 at 6:46:21 AM UTC-7, Louis LaBrunda wrote:
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Hi Lou,

These are interesting thoughts, but I think they probably take you in the wrong direction(*). Without trying to direct you away from VA Smalltalk, I suggest you examine GemStone/S. It's model is multiple VMs running against a shared image with transactional semantics. (The database *is* the image.) So, one spins up as many running VMs as make sense for the application / load. This utilizes as many CPUs and separate machines as you want, without having the data get away from you.

If you want to follow up on this, let's spin off a separate thread rather than derail this one.
 


(*) By wrong direction, I mean that the added complexity to make one running VM deal safely with multiple images would make for a complicated and - in my opinion - fragile solution.


Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How hard would it be for the new VM to run two images at once?

Louis LaBrunda
In reply to this post by Seth Berman
Hi Seth,

I have given the shared object graph some more thought, so here goes.

I understand that just unleashing two or more threads on many of VA Smalltalk's classes/objects is a bad idea.  People seldom explain why it is a bad idea, so for the sake of the discussion, let me venture a guess.  For example the collections classes that can grow, like OrderedCollection are basically arrays of a given size that contain pointers the the objects in the collection.  When an object is added to the collection and there isn't room for it, the object gets more memory (another array probably twice as big) and copies the pointers to the new array and then frees the old one.  If a second thread were to come along and do this same process before the first thread finishes growing the collection, the internal state of the object could be left in disarray (I think there is a pun in there somewhere).  I doubt there is anything that can be done about this other than preventing the second thread from having access to the collection until the first thread is finished.

Now, the simplest thing to think of is to replace collection with shared object graph and not allow the second thread to send any messages to any objects in the graph.  The question then arises, is this too restricting?  Does it defeat too may of the benefits (what ever they are) of having more than one image running in one VM?  If all the objects of both VMs were being shared all the time, I think the answer would be yes, one thread wouldn't be doing anything most of the time.  But it the shared object graph is small and most of the time the threads were working with the non-shared portions of the images, then I think it wouldn't be too restrictive.  Of course, I don't know this for sure, that's why we are having this discussion.

The next question is how many applications would benefit from running two or more images in the same VM and sharing a small object graph?  Maybe none.  But I think some.  I have already mention Seaside, where the main thread could begin the process of a new session and pass it off to another thread, preforming a form of load balancing.  Yes, I know there are other ways of doing this with front ends like Apache.  Those other ways may be better, I don't know.  I guess they involve having N number of VMs running or the front end being able to automatically start VMs as needed but it seems to be it would be easier for one VM to start more threads if needed.  I assume the image would be able to have the VM start another image in another thread.

Lou


On Thursday, March 22, 2018 at 7:19:55 PM UTC-4, Seth Berman wrote:
Hi Lou,

I think its better to think of an object in these discussions as a complex graph rather than a single datum.
The discussion is too over-simplified if we just talk about a data/object being passed around .  We're back to the "bytes" example and I don't have much to contribute here.
Presumably this object refers to other objects.  Probably other objects refer to this object...and if not then we probably expect this object to go away.

So I would think the discussion would need to begin with a clear understanding of what is meant by "sharing an object"...because we are really talking about "sharing an object graph which other things may refer to".
I think this orientation leads one to ask the appropriate questions when considering various approaches...and ultimately a worthwhile discussion.

For example, you mentioned "but once passed the originating image no-longer has a knowledge of or even interest in the data/object passed".
If I were to think of an object as this standalone non-dependent thing...then what you suggest is very easy for me to imagine.
But now let's replace "data/object" with "object graph that other objects may refer to" and re-read.
When I read it this way...the first question that stands out to me is "So is it implied that we have to transfer the whole object graph?"
Yes...ok well that might be a lot.  And then of course, the details of how to correctly and efficiently vacate an object graph in mid execution (that other objects might be referring to some portion of) from one place to another we will just leave because that's currently too painful for me to imagine:)
No...now one would have to address some of my previous questions concerning share semantics.  One part of the graph in one place and the other part in another place....and wrapped around it is a memory management program that is trying to figure out who still needs to be there.

Unfortunately, unless we are talking about a theoretical execution engine, this is one of those areas where the detail is not desired...but it's also not escapable.
Otherwise the discussion will quickly degenerate into  "well, that would be nice if it worked that way".

I think some of your points have been good and in the right direction.
I would be curious to hear some of your suggestions if you mentally swap out "data/object" with "object graph that others objects might refer to some part of".

- Seth



On Thursday, March 22, 2018 at 3:18:10 PM UTC-4, Louis LaBrunda wrote:
Hi Seth,

I don't know if you can tell but I am more interested in the discussion than I am in trying to get it to go in any particular direction.  So, forgive me for not being able to say "I want to achieve X".  I did say "shared memory" but maybe a shared connection is a better place to start.  Maybe it can do slightly more than pass bytes but once passed the originating image no-longer has an knowledge of or even interest in the data/object passed.

Again, I don't NEED to solve any particular problem but as an example, I do have a bunch of images that are all different and communicate with each other via serialized objects sent over a TCP/IP connection.  This can be very slow.  If two different images, running in the same VM could pass data/objects back and forth, maybe without serializing, that would be cool.

This could probably also work for the Seaside program with two or more copies of the same image, where one image gets all connections and then passes them off to another image.

Lou

On Thursday, March 22, 2018 at 11:37:33 AM UTC-4, Seth Berman wrote:
Hi Lou,

The "shared memory" area can work...but there are still a lot of considerations in a memory-managed environment that make it non-trivial in the general case of objects.
For example, some immediate questions I would have are...
Who accepts responsibility for freeing this shared object when it's no longer in use? 
If it's not the user, how does the program establish the shared object is no longer in use?
If it is the user, then I just assume we are introducing unsafe behavior into a virtual machine which is supposed to provide certain protections for objects.
What if this shared object points to other non-shared objects in one of many potential heap spaces...what does book-keeping for that look like?
How is the program telling non-shared objects not to be garbage collected when all intra-heap references are gone, but shared refs still remain?

This all reminds me of some of the SST distributed garbage collection components which set out to solve some non trivial problems.

Now if all you want to do is share some "bytes"...maybe just things like byte arrays or strings that basically don't point to other objects...some of these issues might go away.
But that seems awfully limiting...and then again...who establishes that your done with some "bytes"?

Not sure how inexpensive this endeavor might be:) I guess it just depends on what exactly your trying to do.

-- Seth

On Thursday, March 22, 2018 at 8:43:56 AM UTC-4, Louis LaBrunda wrote:
Hi Seth,

Now you are getting to what I was thinking.  Each image would have its own copy of the memory "areas" (like old memory, new memory, I will let you list them all if you like) that a single image has now.  And as you say there can be a "shared memory area" that was what I was alluding to with communicate with each other through a primitive.

I don't think this is the perfect solution to any particular problem but it may be an "inexpensive" solution to something like load balancing with a Seaside program that doesn't require some front end system to direct traffic to separate VA Smalltalk programs.

Lou
 
On Wednesday, March 21, 2018 at 10:13:56 AM UTC-4, Seth Berman wrote:
Hi Lou,

It's certainly not a bad question.  Many languages seek to solve this very important issue in different ways.
I know questions like this have been asked in other posts so it may be worth searching on.
It's really the question of a shared object heap (or global vm state) that makes this difficult.  Neither the vm
or the smalltalk image code (i.e. Collections) would be prepared to deal with multiple executions operating on them
at the same time.
So one way or another, you would really need to maintain separate heaps for each execution unit.  Perhaps some
part of it could be shared memory or perhaps just efficient communication channels.
But this can be accomplished via separate OS processes.

-- Seth


On Tuesday, March 20, 2018 at 6:21:18 PM UTC-4, Louis LaBrunda wrote:
Hi Seth and Joachim,

You both raise good questions.  I'm thinking that the VM running 2 or more images allows for efficient use of multiple CPUs or Cores but I have no real idea why I should think this other than one program would have access to everything including what the images would want to share.  This may be completely without merit.  But that is why I ask these kinds of questions.

Lou



On Tuesday, March 20, 2018 at 1:00:27 PM UTC-4, Joachim Tuchel wrote:
Lou,


I wonder why you think the VM running 2 or more images allows for efficient use of multiple CPUs or Cores? In my naive mind, the VM is the bottleneck here...?

Joachim



Am Dienstag, 20. März 2018 14:46:21 UTC+1 schrieb Louis LaBrunda:
Hi Everyone,

Congratulations to everyone at Instantiations on the new 32 and 64 bit VMs.  That effort seems to be doing well.

I don't have a need for a VM to run two images at once, I just find the idea interesting.  I pose this in the form of a question but I am really more interested in the discussion.  How hard would it be for the new VM to run two images at once?

Could the VM be made to run two images, most likely the same image, at the same time?  This seems like a good way to make use of more than one CPU.  I expect the images would be able to communicate with each other, maybe through a primitive or something.

Is there anyone who could use this?  What do you think about the idea?

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
12