This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: classloading from so
- From: Tom Tromey <tromey at redhat dot com>
- To: Lars Andersen <lars at rimfaxe dot com>
- Cc: java at gcc dot gnu dot org
- Date: 24 Sep 2002 14:51:07 -0600
- Subject: Re: classloading from so
- References: <1032862273.16624.10.camel@lars.rimfaxe.com>
- Reply-to: tromey at redhat dot com
>>>>> "Lars" == Lars Andersen <lars@rimfaxe.com> writes:
Lars> What if an app loaded that class, then lib-org-pack.so is
Lars> recompiled. If the app should issue another class.forName,
Lars> would it load the newly compiled .so ? Or would the app have to
Lars> be restarted?
The app would have to be restarted. Currently we never unload shared
libraries.
It appears if you use the SharedLibLoader, instead of the built-in
one, then you can get class unloading. I have never tried it, but I
do note that SharedLibLoader.finalize() calls dlclose(). Of course,
for this to work, the SharedLibLoader and all its classes must be
collected.
Lars> And another related question : Is there some debugging trick to
Lars> tell which classes are executed as native code, and which are
Lars> interpreted? (I want to check if it loads the .so just right,
Lars> and isn't interpreting some class from CLASSPATH)
There are lots of ways. You could set your class path to point to a
directory where no .jar files exist. Or you could run your program in
the debugger and see what is happening. Or use ltrace. Or get a raw
stack trace (you'd have to set a system property; see NameFinder.java
for the list) and make sure that there are no interpreter frames.
Tom