This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: FYI: loading a class twice
- To: Jeff Sturm <jsturm at one-point dot com>
- Subject: Re: Patch: FYI: loading a class twice
- From: minyard at acm dot org
- Date: 06 Sep 2001 22:27:41 -0500
- Cc: tromey at redhat dot com, Java Patch List <java-patches at gcc dot gnu dot org>
- References: <Pine.LNX.4.10.10109061435510.19776-100000@mars.deadcafe.org>
- Reply-To: minyard at acm dot org
Jeff Sturm <jsturm@one-point.com> writes:
> On 5 Sep 2001 minyard@acm.org wrote:
> > Unfortunately, I don't think that's the way the ELF loader works. It
> > always takes the most recently loaded code, but the oldest data. So
> > if you load a class on top of a double-loaded class, it will take the
> > code from the last class loaded, but the data items from the first
> > class loaded.
>
> That sounds bizarre to me. I assembled a tiny test case; it
> demonstrates that data symbols are resolved just as text symbols are
> (unless you use things like -Bsymbolic or ELF visibility modifiers).
>
> This is on GNU/Linux, right? I'd like to see an example of what you're
> talking about.
>
Ok, you are right, I don't know what our tests showed in the past, I
believe we were not using -rdynamic and the test symbols were being
overriden in the main program, so I think wierd things were happening.
It works as you say, it always gets the first symbol loaded.
But I still don't think it's a good idea to silently use the first
version of a class in the load order. If the two classes that are the
same are different versions, the newer one may have new methods and if
it is loaded second, the calls in both versions go to the first loaded
version (with possibly a second version object), but the methods that
are only in the second version will still be resolved and will call
the second version's code (with possibly a first version object).
This would cause bizarre behaviour. It works ok for JVMs because it
will only load one version of a class, any version later in the
classpath will not be loaded (it would be really nice if we could do
that), so in the situation above, the using class will not even load
because it cannot resolve it's dependencies.
-Corey