4 ms·

As gnaritas posted below, yes, you could do that, yes, that's what Dabble DB does, and yes, memory is a serious limiting factor. That's where Gemstone comes in

As gnaritas posted below, yes, you could do that, yes, that's what Dabble DB does, and yes, memory is a serious limiting factor. That's where Gemstone comes in: unlike the Squeak VM, which we use, the Gemstone VM does not expect all objects to be in memory at all times, and can lazily load them in as needed.

anewaccountname 18y ago
Can you expand more on what makes that different from loading them in from swap?
- avibryant 18y ago
  For one thing: the second you have a full GC, you're going to need to swap in the entire object memory, dirty those pages, and then swap them back out. It doesn't take a very large image before this brings your machine to its knees.
  - rcoder 18y ago
    Of course, that's only true if you're using a totally flat heap. I don't see any reason why you couldn't be a little more clever about using a hybrid GC approach (generational + thread-local allocation pools, for example) to minimize the size of the dataset that had to be paged in or out in a given sweep. RScheme and other persistent language implementations have certainly been able to use the underlying OS paging mechanism pretty efficiently, and the performance numbers Varnish HTTP cache seems to suggest that it can work well for some kinds of web application workloads, too.
  - anewaccountname 18y ago
    How does gemstone get around the garbage collection issue?
stcredzero 18y ago
Avi, you guys are seriously going to open up the stuff that's above the VM? I had been thinking about again picking up my own project to put Ruby on top of Smalltalk. I'm envious of your approach with working with the VM hackers to get custom bytecodes. This would be great for getting Ruby to run fast. What of parallel projects on other Smalltalk VMs? It would be good for the Ruby community to have options. Gemstone might want to keep some sort of competitive advantage, however. (Email this userid at yahoo.com. Linkedin is not letting me send you a message, and so fulfilling their policy of keeping out riff-raf.)
- avibryant 18y ago
  I think and hope we seriously will, but it's not up to me. Certainly one side effect would be that, with a little work, you would be able to run Ruby on other Smalltalk VMs as well, and I think this would be a Good Thing. We'll see what happens.
  - stcredzero 18y ago
    Did you bootstrap a Ruby parser in Ruby into the image? Or did you take another approach?
- fendale 18y ago
  I know nothing about the internals of any of the Ruby VM's so this may be a totally stupid question ... How hard would be it be to 'marshal out' the entire running Ruby VM to a binary image and load it back in again like the way the Smalltalk VMs seem to do, or add the ability to marshal out objects as a memory image of some sort, meaning they can be marshalled out and in really efficiently (ie stuff a true Ruby object into Memcached instead of a string representation of it ...
  - stcredzero 18y ago
    You should be able to marshal out everything in just about any VM. The reason why Ruby and the JVM dont' do this is because it just hasn't been done yet. The whole point of VMs is that they are virtual machines. That virtual model is just data. The VM is just another program. So saving state, then restarting later from that state is quite doable. Image-based development is a very different style, however. Lots of people are in love with their command lines and text editors.
fendale 18y ago
So does that mean that if I had a Dabble DB instance that had many megabytes of data in it, you need enough RAM for the Dabble code plus all my data to be in memory at once (and so on for each customer), or can you do some lazy loading magic to only load part of my data?
- avibryant 18y ago
  So on for each customer who is active at any given time, yes. We do some lazy loading magic but not much.

anewaccountname 18y ago

Can you expand more on what makes that different from loading them in from swap?

avibryant 18y ago
For one thing: the second you have a full GC, you're going to need to swap in the entire object memory, dirty those pages, and then swap them back out. It doesn't take a very large image before this brings your machine to its knees.
- rcoder 18y ago
  Of course, that's only true if you're using a totally flat heap. I don't see any reason why you couldn't be a little more clever about using a hybrid GC approach (generational + thread-local allocation pools, for example) to minimize the size of the dataset that had to be paged in or out in a given sweep. RScheme and other persistent language implementations have certainly been able to use the underlying OS paging mechanism pretty efficiently, and the performance numbers Varnish HTTP cache seems to suggest that it can work well for some kinds of web application workloads, too.
- anewaccountname 18y ago
  How does gemstone get around the garbage collection issue?

stcredzero 18y ago

Avi, you guys are seriously going to open up the stuff that's above the VM? I had been thinking about again picking up my own project to put Ruby on top of Smalltalk. I'm envious of your approach with working with the VM hackers to get custom bytecodes. This would be great for getting Ruby to run fast. What of parallel projects on other Smalltalk VMs? It would be good for the Ruby community to have options. Gemstone might want to keep some sort of competitive advantage, however. (Email this userid at yahoo.com. Linkedin is not letting me send you a message, and so fulfilling their policy of keeping out riff-raf.)

avibryant 18y ago
I think and hope we seriously will, but it's not up to me. Certainly one side effect would be that, with a little work, you would be able to run Ruby on other Smalltalk VMs as well, and I think this would be a Good Thing. We'll see what happens.
- stcredzero 18y ago
  Did you bootstrap a Ruby parser in Ruby into the image? Or did you take another approach?
fendale 18y ago
I know nothing about the internals of any of the Ruby VM's so this may be a totally stupid question ... How hard would be it be to 'marshal out' the entire running Ruby VM to a binary image and load it back in again like the way the Smalltalk VMs seem to do, or add the ability to marshal out objects as a memory image of some sort, meaning they can be marshalled out and in really efficiently (ie stuff a true Ruby object into Memcached instead of a string representation of it ...
- stcredzero 18y ago
  You should be able to marshal out everything in just about any VM. The reason why Ruby and the JVM dont' do this is because it just hasn't been done yet. The whole point of VMs is that they are virtual machines. That virtual model is just data. The VM is just another program. So saving state, then restarting later from that state is quite doable. Image-based development is a very different style, however. Lots of people are in love with their command lines and text editors.

fendale 18y ago

So does that mean that if I had a Dabble DB instance that had many megabytes of data in it, you need enough RAM for the Dabble code plus all my data to be in memory at once (and so on for each customer), or can you do some lazy loading magic to only load part of my data?

avibryant 18y ago
So on for each customer who is active at any given time, yes. We do some lazy loading magic but not much.