This is the mail archive of the java-patches@gcc.gnu.org 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]
Other format: [Raw text]

Re: [BC ABI] For entertainment purposes only: gcj-JIT


Tom Tromey wrote:

Andrew>   /* FIXME: The gcj runtime is broken in that atable references to
Andrew>      static fields in interpreted classes aren't fixed up until too
Andrew>      late.  When this is fixed we can re-enable this code.  */

Andrew> .. this is all to do with the time whan we do resolution, as we
Andrew> discussed before.  Somehow we need to defer resolving the references
Andrew> to data until they're used.

[ just thought I'd get this in the archives ]

This might be the bug I'm hitting when I compile swt.jar.

It occurs to me that before we can reference a static field, we must
initialize the target class. What if at these places we call a
special (new) function that both initializes the target class and
updates all atable references to static fields of that class?



I'm not sure that fixing up atable entries at runtime is the best approach. For one thing, are static field references really a special case? If the static fields wern't resolved at the time the atable was linked, why dont the entries for non-static fields and methods have the same problem?


See this thread for the discussion the last time this issue came up: http://gcc.gnu.org/ml/java/2004-07/msg00219.html

Summary points:
- To be spec compliant, resolution does not have to be deferred to active use. However, the errors resulting from failed resolution do - ie exceptions like NoClassDefFoundError and NoSuchMethodError.
- Sun's Hotspot however is more lazy than the spec requires and does defer resolution to active use.
- It doesn't seem very likely that any sane code actually relies on this
- Any code that already runs on GIJ will be fine with the current BC approach, because GIJ is actually not yet compliant with the spec, it is currently too eager at throwing exceptions for failed resolution.


Bryce


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