public inbox for java-prs@sourceware.org
help / color / mirror / Atom feed
From: "mckinlay at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: java-prs@gcc.gnu.org
Subject: [Bug libgcj/15363] Binary Compatibility: need special access control
Date: Mon, 10 May 2004 16:14:00 -0000	[thread overview]
Message-ID: <20040510155723.9364.qmail@sourceware.org> (raw)
In-Reply-To: <20040510050403.15363.tromey@gcc.gnu.org>


------- 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


      parent reply	other threads:[~2004-05-10 16:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-10  5:04 [Bug libgcj/15363] New: " tromey at gcc dot gnu dot org
2004-05-10 15:21 ` [Bug libgcj/15363] " mckinlay at redhat dot com
2004-05-10 15:23 ` pinskia at gcc dot gnu dot org
2004-05-10 16:14 ` mckinlay at redhat dot com [this message]

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=20040510155723.9364.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=java-prs@gcc.gnu.org \
    /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).