This is the mail archive of the java@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]

Re: gcj-compiled jigsaw is running


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



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