[Vm-dev] Object format(s) as a contract with VM?

Igor Stasenko siguctua at gmail.com
Fri Jul 29 20:30:54 UTC 2011


On 29 July 2011 11:41, Wolfgang Eder <edw at generalmagic.at> wrote:
>
> hi igor,
> i have in the past pondered this question many times,
> and have not yet come to satisfying conclusions.
> the big question (for me) is where exactly to draw the
> line. what are the assumptions that are fixed,
> and what not. i mean, e.g.
>
> what would be the interface (contract) that the garbage
> collector would use?
>
> is there a contract to the object memory itself
> (e.g. allocate new memory, make an object fixed in memory,
> etc)?
>
> can we extend not only object representations, but
> also compose different object memory strategies
> (like, object table vs direct pointers)?
>

There's a plenty of various options. What is hard is to take all
tradeoffs into account.

One of extreme approaches which i thought about is to turn an object
header into pointer to a function,
of a form (selector, arguments ...), which then looks like a low-level
message send.

Then anything you can do to object will be available only through call
to this function with corresponding arguments,
including accessing object's state, sending a message, retrieving its
class , GC , etc.

Then there will be very few fixed points. The problem of course how to
apply optimizations in a presence of such extremely
late bound interface.

-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list