This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: patches to re-direct _Jv_RegisterClass
Tom Tromey <tromey@redhat.com> writes:
> I think there should be a comment by _Jv_RegisterClassHook explaining
> that you must acquire the Class mutex before changing it. This might
> not be necessary, since it might be the case that no existing or
> future system can dlopen and invoke static constructors on two shared
> libraries at once. However, it is safe and easy.
I added this comment:
// A pointer to a function that actually registers a class.
// Normally _Jv_RegisterClassHookDefault, but could be some other function
// that registers the class in e.g. a ClassLoader-local table.
// Should synchronize on Class:class$ while setting/restore this variable.
void (*_Jv_RegisterClassHook) (jclass cl) = _Jv_RegisterClassHookDefault;
> Per> It might be useful to include SharedLibLoader in libgcj, if
> Per> people think that would be desirable.
>
> How does it differ from the shared library code already in the default
> classloader?
Is there any shared library code already in the default classloader?
I just see some code in natRuntime, but no classloader support.
Basically, SharedLibLoader is analogous to UrlClassLoader, in that it
manages a bunch of classes that have their private name space, but
from a .so rather than a .jar. To do that we have to prevent the
shared library's classes from getting mixed in with the classes
managed by the system class loader.
Why would you want a private nameapace in a .so? One example is
Java Server Pages. You have a server, which notices that a .jsp
file is out of date, and re-compiles it, generating a new .so.
The class name generated from the .jsp is arbitrary, and should
not be globally visible. Furthermore, you might have a new .so that
is an updated version of an older one. These should to be loaded
into two separate namespaces, using separate ClassLoaders.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/