At 11:05 PM 4/30/2001 +0200, Kai Henningsen wrote:
>[EMAIL PROTECTED] (Dan Sugalski) wrote on 25.04.01 in
><[EMAIL PROTECTED]>:
>
> > If you have the double-indirect, the window of vulnerability is smaller,
> > but it's still there if you're running multithreaded.
>
>Looks zero-sized to me. One memory write, let the garbage collector
>collect the old vtable.
Nope. Memory write, GC the old table, and then find another thread's
vectoring through the old table (now reused) off into never-never land
because some compiler got reasonably clever and cached the double-indirect
lookup.
>Well OK, you need to synchronize between different threads trying to
>update the vtable at the same time, but that's a different thing from
>synchronising with people just *using* the vtable.
That's actually the easy part--mutexes will take care of that one easily
enough.
> > Unfortunately that
> > double-indirection's not going to be cheap, and I don't see that it buys us
> > all that much. Yes, it means that updating vtables costs less and is less
> > dangerous, but it still costs and isn't free.
>
>So?
>
>Objective-C uses name lookup for method calls and is still plenty fast
>enough. (See libobjc in the gcc source tree or from www.gnustep.org.)
>That's a *lot* more expensive than double indirection! (And it allows for
>runtime changing what methods your class understands, by dynamically
>loading libraries [called bundles].)
We're not a compiled language, and that will cost us speed that objective-C
doesn't have to pay. And even though Objective-C might be plenty fast (I
have no experience with it so I can't judge) that doesn't mean we're
necessarily willing to pay a cost we might be able to skip.
Enough of the necessary things are going to be expensive, so I'd much
rather not pay for extravagances if we can avoid it.
> > Also you have the issue of needing *all* the vtables in the system resized
> > essentially atomically. (Or done at least before any code that uses the
> > resized vtable to execute, which is more doable) The vtables need to stay
> > consistent--if we add a method to one of 'em, we need to add it to all of
> > them.
>
>Hmm. Maybe you really should look at the Objective-C way of doing things.
>It doesn't need large sparse function pointer tables.
Yeah, we can do it with hashed lookups if we want, and we can even make it
reasonably quick. The question is whether we can make the (not really
sparse) pointer table faster.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
