Hacker News Reader

Comment by avibryant | Hacker News Reader

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.

View on HN

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

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.

Did you bootstrap a Ruby parser in Ruby into the image? Or did you take another approach?

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

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.

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?

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

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

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.

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.

How does gemstone get around the garbage collection issue?

Reply on news.ycombinator.com