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]
Other format: [Raw text]

Re: profile questions


Mathieu Lacage writes:
 > On Tue, 2006-08-29 at 17:31 +0100, Andrew Haley wrote:
 > > Tom Tromey writes:
 > >  > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > >  > 
 > >  > >> I'd prefer to use dlmopen to solve this instead, but I'm not sure it
 > >  > >> is actually suitable for our needs :-(
 > >  > 
 > >  > Andrew> I've heard you say so before, but you never said *why* you think it may
 > >  > Andrew> not actually be suitable.  Can you tell us?
 > >  > 
 > >  > Yeah, sorry.  When loading a library into a new dlmopen namespace, I
 > >  > wonder how other libraries needed by that library are handled.  E.g.,
 > >  > a BC-compiled .so will depend on libgcj_bc.so.  I suppose it would try
 > >  > to load a new copy of libgcj_bc.so into the new namespace... but this
 > >  > is incorrect for our situation.
 > 
 > It will load a new copy of the library into the new namespace.
 > 
 > Another thing to keep in mind is that dlmopen has a static maximum
 > number of namespaces per process. On my FC5 system, that max number is
 > 15. (1 is used for the main namespace which leaves you 16 - 1 = 15 for
 > your own namespaces).

Aww, how annoying!  I did try to trick dlopen() by making a hard link
to the shared object and using that, but dlopen() checks the
underlying inode.  So we have to copy the whole shared library into
/tmp and dlopen() that...  :-(

Andrew.


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