.. and evolving object format(s) (Was: Re: [Vm-dev] #becomeUncompact not longer works in Cog/Stack VMs)

[Igor Stasenko]

On 8 May 2011 10:32, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> On 5/7/2011 22:30, Igor Stasenko wrote:
>>
>> On 7 May 2011 16:15, Andreas Raab<andreas.raab at 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


-- 
Best regards,
Igor Stasenko AKA sig.