public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: per@bothner.com
Cc: gcc@gcc.gnu.org
Subject: Re: New vtable ABI (was Re: Strange behaviour in C++...)
Date: Tue, 07 Sep 1999 23:14:00 -0000	[thread overview]
Message-ID: <199909080607.IAA00513@mira.isdn.cs.tu-berlin.de> (raw)
In-Reply-To: <m24sh6i3ig.fsf@magnus.bothner.com>

> I confess to not being able to follow more than the very basic idea;
> I guess I'm rather rusty on g++ vtable management.  However, it does
> not seem like this will do much for Java, since the big deal is
> how to handle the offsets, while for Java object the offsets are
> always zero.

Is that mandatory? The naïve way of implementing interfaces is to take
the usual C++ approach: interfaces are virtual classes with pure
virtual methods. So

interface FooBar{
  public void x();
}
class Foo extends Bar implements FooBar{public void x(){...}}

becomes

class FooBar{
  virtual void x()=0;
};

class Foo:Bar, virtual FooBar{
  void x(){...}
};

Does that meet all requirements? If so, you will have adjustments when
you have a FooBar pointer and invoke x. The reason is that Foo has two
embedded vtbl pointers: the one of Foo, and the one of FooBar. A
FooBar pointer is represented as a pointer to the location of the
FooBar vtbl pointer inside the Foo object.

In the current ABI proposal (by Jason), the FooBar vtbl is represented
as

-1: RTTI (at negative offset for COM compatibility)
0:  x

Inside Foo, Foo::x has two entry points:

x_for_FooBar: this = this + this->_vtbl[1] ;fallthrough
x__3Foo:      ...

So, the FooBar-in-Foo vtbl has a different layout:

-1: RTTI
0:  x_for_FooBar
1:  Adjust FooBar to Foo (say, -16)

An interface call would then be a normal virtual call: Using the
pointer you have, retrieve the vtbl (at offset 0), retrieve the method
pointer, and call it. The adjustment to the full object is made at the
target.

Would that work for Java?

Martin

WARNING: multiple messages have this Message-ID
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: per@bothner.com
Cc: gcc@gcc.gnu.org
Subject: Re: New vtable ABI (was Re: Strange behaviour in C++...)
Date: Thu, 30 Sep 1999 18:02:00 -0000	[thread overview]
Message-ID: <199909080607.IAA00513@mira.isdn.cs.tu-berlin.de> (raw)
Message-ID: <19990930180200.vmGRWx-Jev9v30mC_x3k-Qs1f7DCJKcpXC-Km1a8iSQ@z> (raw)
In-Reply-To: <m24sh6i3ig.fsf@magnus.bothner.com>

> I confess to not being able to follow more than the very basic idea;
> I guess I'm rather rusty on g++ vtable management.  However, it does
> not seem like this will do much for Java, since the big deal is
> how to handle the offsets, while for Java object the offsets are
> always zero.

Is that mandatory? The naïve way of implementing interfaces is to take
the usual C++ approach: interfaces are virtual classes with pure
virtual methods. So

interface FooBar{
  public void x();
}
class Foo extends Bar implements FooBar{public void x(){...}}

becomes

class FooBar{
  virtual void x()=0;
};

class Foo:Bar, virtual FooBar{
  void x(){...}
};

Does that meet all requirements? If so, you will have adjustments when
you have a FooBar pointer and invoke x. The reason is that Foo has two
embedded vtbl pointers: the one of Foo, and the one of FooBar. A
FooBar pointer is represented as a pointer to the location of the
FooBar vtbl pointer inside the Foo object.

In the current ABI proposal (by Jason), the FooBar vtbl is represented
as

-1: RTTI (at negative offset for COM compatibility)
0:  x

Inside Foo, Foo::x has two entry points:

x_for_FooBar: this = this + this->_vtbl[1] ;fallthrough
x__3Foo:      ...

So, the FooBar-in-Foo vtbl has a different layout:

-1: RTTI
0:  x_for_FooBar
1:  Adjust FooBar to Foo (say, -16)

An interface call would then be a normal virtual call: Using the
pointer you have, retrieve the vtbl (at offset 0), retrieve the method
pointer, and call it. The adjustment to the full object is made at the
target.

Would that work for Java?

Martin

  reply	other threads:[~1999-09-07 23:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-08-26 15:59 Jason Merrill
1999-08-26 16:38 ` Jason Merrill
1999-08-31 23:20   ` Jason Merrill
1999-08-26 17:05 ` Joe Buck
1999-08-26 17:13   ` Jason Merrill
1999-08-26 17:26     ` Mumit Khan
1999-08-31 23:20       ` Mumit Khan
1999-08-31 23:20     ` Jason Merrill
1999-08-31 23:20   ` Joe Buck
1999-08-31 23:20 ` Jason Merrill
1999-09-07 18:42 ` Per Bothner
1999-09-07 23:14   ` Martin v. Loewis [this message]
1999-09-07 23:53     ` Per Bothner
1999-09-08  0:49       ` Martin v. Loewis
1999-09-08  6:33         ` Per Bothner
1999-09-09  1:39           ` Martin v. Loewis
1999-09-09  9:28             ` Per Bothner
1999-09-30 18:02               ` Per Bothner
1999-09-30 18:02             ` Martin v. Loewis
1999-09-30 18:02           ` Per Bothner
1999-09-30 18:02         ` Martin v. Loewis
1999-09-30 18:02       ` Per Bothner
1999-09-30 18:02     ` Martin v. Loewis
1999-09-30 18:02   ` Per Bothner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199909080607.IAA00513@mira.isdn.cs.tu-berlin.de \
    --to=martin@mira.isdn.cs.tu-berlin.de \
    --cc=gcc@gcc.gnu.org \
    --cc=per@bothner.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).