.. and evolving object format(s) (Was: Re: [Vm-dev] #becomeUncompact not longer works in Cog/Stack VMs)
On 8 May 2011 10:32, Andreas Raab andreas.raab@gmx.de wrote:
On 5/7/2011 22:30, Igor Stasenko wrote:
On 7 May 2011 16:15, Andreas Raabandreas.raab@gmx.de wrote:
On 5/7/2011 9:25, Tobias Pape wrote:
No. It does /not/ need to be fixed. As I said earlier it is *absurd* to throw away performance for the ability to change certain classes to become uncompact.
When it worked in pre-cog VMs, why should it break in Cog?
Because Cog is all about performance. And there's a big performance difference for some classes when they are changed to be non-compact and Eliot didn't want to add the complexity it would take to support both a fast compact, and a slow non-compact version of the code.
Where is the metrics? I need to know what we lose if we do it one or another way.
And since Cog don't allows me to turn compact class back to be normal class (simply crashing), i cannot measure it.
Then write the code yourself. Why does Eliot have to do that? His metrics is pretty simple, a comparison of the speed of the interpreter with the JIT. The results (as you know) are impressive, but you can't realistically expect Eliot to do the work for something he considers directly detrimental to the goals of Cog. If you suspect that there's no difference, it's up to you to prove that, not up to Eliot to disprove you. And unless you can show differently, his claim stands unabated.
No problem. Of course i could write necessary code. I just expected it will be less work, if Cog would not nail down compactness. I understand the design decision and since future object format (tm) will unify this anyways, there's not much to worry about.
Therefore, some classes cannot be made non-compact in Cog, and that is a perfectly good tradeoff.
In theory. But you have no proof now. Why i should trust you/Eliot/anyone else, without being able to test it?
You don't. But why must Eliot jump every time you have a hunch that something can be done differently? Adding unneeded generality to a JIT just to disprove your hunches is an amazingly pointless waste of time for him. Unless you are intending to pay him for it, of course. Oh, you weren't...
I wouldn't say that its adding generality, i would call it 'inheriting' generality. I would like to squeeze some time to experiment with it and free those 5 bits for something else.
One of applications, if you remember, i had an idea to be able to attach a variable number or key/value pair slots to objects. So, objects in addition to general layout could carry additional state, like bigger storage for identity hash value.
A most interesting application for those dynamically added slots is Magma: - it could attach an unique ID per each object to identify them, instead of maintaining huge and ineffective id<->object dictionaries.
But this scheme heavily depends on fast become. If you remember we had a discussion before, where i proposed to introduce a lazy become, i.e. object is marked as forwarded by setting a certain bit(s) in header, and points to its newer version. It will stay in such forms until GC will replace all references to old object with a new one.
There of course many ways how to use extra bits freed in header: how about supporting multiple/segregated memory regions for heap? Eliot wants a non-movable memory region for FFI. And also, we could use a separate memory region for immutable objects.
Cheers, - Andreas
On 05/09/2011 04:06 AM, Igor Stasenko wrote:
There of course many ways how to use extra bits freed in header: how about supporting multiple/segregated memory regions for heap?
why do you need a flag to tell in which region the object lives? isn't its memory address/oop enough to say it?
gera
On 9 May 2011 15:25, Gerardo Richarte gera@corest.com wrote:
On 05/09/2011 04:06 AM, Igor Stasenko wrote:
There of course many ways how to use extra bits freed in header: how about supporting multiple/segregated memory regions for heap?
why do you need a flag to tell in which region the object lives? isn't its memory address/oop enough to say it?
I don't know, but probably you are right. I imagine a memory manager which dynamically allocates a memory (and address space) by chunks per region type. And to get a region (or page info), it should go to: (oop bitAnd: (4 Mb -1) bitInvert ), where oop is any object which belongs to given page.
gera
in any case I think that camillo could experience with these ideas and build prototype. Getting isolation or/and other security properties would be excellent.
Stef
On May 9, 2011, at 9:22 PM, Igor Stasenko wrote:
On 9 May 2011 15:25, Gerardo Richarte gera@corest.com wrote:
On 05/09/2011 04:06 AM, Igor Stasenko wrote:
There of course many ways how to use extra bits freed in header: how about supporting multiple/segregated memory regions for heap?
why do you need a flag to tell in which region the object lives? isn't its memory address/oop enough to say it?
I don't know, but probably you are right. I imagine a memory manager which dynamically allocates a memory (and address space) by chunks per region type. And to get a region (or page info), it should go to: (oop bitAnd: (4 Mb -1) bitInvert ), where oop is any object which belongs to given page.
gera
-- Best regards, Igor Stasenko AKA sig.
vm-dev@lists.squeakfoundation.org
-
Gerardo Richarte -
Igor Stasenko -
stephane ducasse