[Vm-dev] [Pharo-project] Plan/discussion/communication around new object format

[Igor Stasenko]

On 13 June 2012 18:13, Chris Cunningham <cunningham.cb at gmail.com> wrote:
> On Tue, Jun 12, 2012 at 8:13 PM, Igor Stasenko <siguctua at gmail.com> wrote:
> [snip]
>> This could be somewhat memory-hungry (but do we care?), but you don't
> [snip]
>
> As long as the Windows VM is severely limited in how much memory it
> can handle, some of us care a lot.  It just depends on how
> memory-hungry it is, and how much memory we're already using.

no, it just about keeping a copy of working set of your transaction.
And nothing will save you from memory problems if you start to abuse DB to load
huge blobs of data, required for your working set..

and as i said, you have to use the copy anyways in case if you need to
rollback transaction.

and nobody said that you cannot employ a hybrid approach: you can keep
a copies of objects
up to certain size/or for certain kind of classes and for the large
ones you can still use the same write barrier approach.
so you will have a best of both worlds :)

In terms of implementation, this is quite easy to do: since graph
comes from database in serialized form, creating an initial copy is
just about materializing same object twice (or materializing and then
copying) instead of once.
One will be used in working set,
and another will be used to detect the changes upon committing transaction.

-- 
Best regards,
Igor Stasenko.