Re: New vtable ABI (was Re: Strange behaviour in C++...)

[Per Bothner <per@bothner.com>]

"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:

> > I put my design up on http://www.bothner.com/~per/jv-inherit.txt
> Interesting. Is this used in jc1/linbgcj? I couldn't find it there.

No.  I'm hoping it (or something better) will get implemented.
Currently, Gcj does a linear search on *each call*, which is
why something better has high priority.

> I think cc1plus could certainly follow this ABI for extern "Java"
> classes. It won't work as a general C++ ABI, for a number of reasons:
> 
> - It requires (potentially dynamic) allocation of numbers to
>   interfaces, and in turn potentially dynamic resizing of arrays.
>   C++ users (especially those designing embedded applications) usually
>   don't like the idea of the C++ runtime system allocating memory when
>   they didn't explicitly requires that.

No, the design requires *link-time* allocation of numbers.  Thus your
objection about embedded applications is not relevant, since such
applications use static linking.

> - It requires class information structures which more details than
>   mandated by the C++ standard. For the standard C++ ABI, only features
>   justified by the C++ standard are acceptable (in the case of RTTI,
>   this is dynamic_cast, typeid, and EH)

I don't follow this.  Yes, Java does require more class
information data structures than C++, but that is all orthogonal to
my design.  My design proposes alternative data structured for
virtual function calls and exactly the things you mention.

> - It appears to assume a single-rooted class hierarchy. In C++, an
>   interface can be implemented by classes that don't share a base class.
>   If a pointer-to-interface really means pointer-to-complete-object
>   in the ABI, I don't think you can support multi-rooted hierarchies
>   at the same time. You wouldn't know where the vtbl is, or the class
>   description (i.e. you couldn't implement OBJECT_CLASS)

Well, the write-up is written in the context of Java.  But is there
any fundamental reason the basic idea can't be generalized to more of
C++? Note the idea is to use special "extra-indirect vtables", but *only*
for abstract classes with no fields.  Specifically, I don't think
pointer-to-interface needs to mean pointer-to-complete-object.  Instead,
how about pointer-to-interface meaning pointer-to-*concrete*-object,
where a "concrete" object corresponds to a class that has fields or
non-abstract virtual methods.

> - It distinguishes between classes and interfaces, when there is no
>   such distinction in C++.

But we can make a distiction between "classes that have no instance fields
or non-abstract virtual methods" and "other classes" in the implementation.

>   As a result, it does not support all features
>   required in C++. E.g. in Java, you cannot cast from one interface
>   to another, unless they are in an inheritance hierarchy (you need
>   two casts to implement a cross-cast). In C++, you can dynamic_cast to
>   a sibling class.

I think that is an implementation detail.

> So, in short: I think its nice for Java, but it doesn't port to C++.

I am not convinced yet.  Of course I'm not the one that needs to be
convinced either way, as I don't see myself being able to do the
implementation.
-- 
	--Per Bothner
bothner@pacbell.net  per@bothner.com   http://www.bothner.com/~per/