This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: gcj-compiled jigsaw is running
- To: Jeff Sturm <jsturm at one-point dot com>
- Subject: Re: gcj-compiled jigsaw is running
- From: Cedric Berger <cedric at wireless-networks dot com>
- Date: Fri, 04 May 2001 07:26:35 -0700
- CC: java at gcc dot gnu dot org
- Organization: Wireless Networks, Inc.
- References: <Pine.LNX.4.21.0105032244110.883-100000@localhost.localdomain>
Jeff Sturm wrote:
> On Thu, 3 May 2001, Cedric Berger wrote:
> > - Yes, class$ points to a per-class/classloader heap object
>
> Well, consider that class$ is a global data symbol and cannot be
> modified. You'd have to allocate this object during library
> initialization, I think.
How is the interpreter implemented?
> > Maybee some of the static content could be moved to the heap?
>
> I'd once considered a model based on gcj in which static methods and
> fields would be non-virtual members of a class derived from
> java.lang.Class whose instances are allocated on the heap. They
> could be created from some kind of static protoclass, containing the
> vtables, metadata and field initializers constructed by the compiler.
>
> Without any static class references, these could be allocated on demand
> and linked (resolved) upon class initialization. By allowing unresolved
> classes to be loaded, some incomplete packages that now cause link errors
> in gcj could be usable. Link failures would result in a runtime
> exception, as they do in normal Java. A compiled class could even derive
> from bytecode.
>
> There are a few more details. My goal was to be compatible with both
> Java and C++. But I couldn't think of a way to keep CNI without
> modification. So it amounted to yet another class linking/loading model,
> sort of a hybrid between compiled (CNI) and the interpreter but different
> than each. It'd be quite a divergence from gcj's architecture, but
> interesting nonetheless.
> > - the finalizer method of the classloader object dlclose all its libraries
>
> A library can contain one or more classes, and be mapped by one or more
> classloaders. But yes, if all the bookkeeping is properly done they could
> eventually be dlclosed.
Is there a way to "dlopen" the same library more than once?
On win32, It's a pain, but how about on unix? worst case,
would it work to create multiple links "ln libawt.so /tmp/libawt.so_1"
and dlopen(/tmp/libawt.so_1) and so on?
Thanks
Cedric