Re: Patch: replace mutex with object synchronization

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

Andrew> The glibc shared library loader goes to great lengths to
Andrew> prevent a DSO from being loaded twice.

Even if the library is not opened with RTLD_GLOBAL?  Weird.

Andrew> The only way I can see around this is to copy the library:
Andrew> simply changing its name by making a link doesn't work, as the
Andrew> shared library loader checks the inode number.

It seems to me that if we adopt Bryce's plan to have gcj emit class
metadata rather than actual Class objects, then we've added the
required extra layer of indirection...  Meaning, we can map a given
.so exactly once, and then simple create Class objects from the .so
for multiple class loaders.

Actually we could do that even if gcj emits Class objects, simply by
copying them for every class loader instead of doing any rewriting
in-place like we do now.

Does this make sense?  I can't tell if I'm missing something.  My
reasoning goes: with BC, the only globals to worry about are the
classes themselves.  If we copy or create those anew for each class
loader requesting the class (and hence the .so), everything else
(static fields basically) will also be freshly made.  Since we'll copy
the otable, too, we'll also see the correct types for the runtime
environment.

CNI code might have real globals that we can't touch.  But JNI code
already has a restriction that a given JNI library can only be loaded
once into a VM, under a single class loader.  IMO there's no harm in
extending that restriction to CNI as well.

Tom