From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19220 invoked by alias); 10 May 2004 16:14:23 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 9365 invoked by uid 48); 10 May 2004 15:57:23 -0000 Date: Mon, 10 May 2004 16:14:00 -0000 Message-ID: <20040510155723.9364.qmail@sourceware.org> From: "mckinlay at redhat dot com" To: java-prs@gcc.gnu.org In-Reply-To: <20040510050403.15363.tromey@gcc.gnu.org> References: <20040510050403.15363.tromey@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libgcj/15363] Binary Compatibility: need special access control X-Bugzilla-Reason: CC X-SW-Source: 2004-q2/txt/msg00091.txt.bz2 List-Id: ------- Additional Comments From mckinlay at redhat dot com 2004-05-10 15:57 ------- Note that when field access occurs within a compilation unit, we can optimize dispatch so that a full otable entry is not required: - If the field access is to a class that within the same compilation unit and has no superclasses except Object, or all its superclasses are also within the same compilation unit, then direct dispatch can be used - no otable entry. This assumes the size of java.lang.Object doesn't change, but I think thats a reasonable assumption. - If the field access is to a class within the same compilation unit but which extends a class in a different compilation unit, then a shortcut dispatch can be used. We only need to look up the base offset of the object, ie the size of its superclass. The fixed offset of the object within the current class would then be added to this offset to find the address of the object. The first case is clearly faster in all cases, but the second case isn't so clear cut since it involves an extra add. However it would reduce the amount of otable symbol data required and increase sharing of otable entries - when multiple fields are loaded from the same class, only a single otable load would be required. Assuming these dispatch options are used, special cases would typically not be required within the runtime as inner class field accesses are usually within the same complation unit. Its conceivable, however, that an inner class could end up in a different compilation unit from its parent when compiling from bytecode, so we'd still need to solve this problem for that case. The best solution is probably to support class metadata attributes for native code. Specifically, the "InnerClasses" attribute. The runtime can then check this attribute when performing field access checks and adjust for inner classes accordingly. -- What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed|2004-05-10 15:23:28 |2004-05-10 15:57:22 date| | Version|3.5.0 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15363