This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: New C++ ABI: patches.

Bryce McKinlay writes:

> The new C++ ABI stores extra fields at a negative offset in the
> vtable.  Given Java's simple inheritence model, there are two fields
> there: the RTTI pointer (at -1) and offset-to-top (at -2, which in
> the case of Java classes would always be zero because there are no
> more fields).

Yes. For some reasons, it took me some time to realize that
`vtables'-first-entry-must-be-a-function-pointer' would be enforced

> In the case of a Java class, gcj, rather than c++, generates the
> vtable, but it does not generate these extra two negative-offset
> fields.

Yeah. Gcj doesn't generated any special vtable. 2entries+array, as
usual -- no negatie-offsets.

> (and native constructors arn't allowed in Java).
> However, when you pull tricks to static allocate Java objects, as is
> done for the primitive type classes, no gcj-generated constructor is
> used. 

Right, this situation is sort of a first.

> a) adjust gcj so that it generates the extra two fields and offsets
> its vtable pointers just like c++ does (this is REQUIRED if we want
> to support RTTI and properly conform to the ABI)

OK, that's right we could do that. Wasn't that going to be painful for
the collector, as I recall?

> b) adjust c++ so that it special-cases "extern "Java"" classes and
> doesn't do the vtable pointer adjustment.

That's the patch I submitted. Gotta correct the comments and the
ChangeLog entry. ;-)

> c) just use the explicit-setting-of-this hack in this case, because
> its the only place where we should ever need to do something like
> this anyway?

Right. It's just ugly and asking for more beating in the future. But
ii no one really disagree, I could easily go down that path (of least
resistance) and drop the C++ patch.

> One possibility: there is something hairy going on right now in
> natSystem::init_properties. It calls into TimeZone, which has a
> System.getProperty() in its static initializer: infinate
> recursion. What I can't figure out is why this _doesn't_ crash (for
> me)!

OK. Seems like I have to build a newer gdb to see what's going on :-(


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]