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

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

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 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

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.

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

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

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

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

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

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.

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

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

This is the critical statement:
 

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.


 

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