public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Dynamic class loading
  2000-04-01  0:00     ` Godmar Back
  2000-04-01  0:00       ` Per Bothner
@ 2000-04-01  0:00       ` Tom Tromey
  2000-04-01  0:00         ` Per Bothner
                           ` (2 more replies)
  1 sibling, 3 replies; 33+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Godmar Back
  Cc: Kresten Krab Thorup, Tom Tromey, Matt Welsh, Bryce McKinlay,
	java-discuss

>>>>> "Godmar" == Godmar Back <gback@cs.utah.edu> writes:

Godmar> It seems that .so files should be treated more similar to .jar
Godmar> or .zip entries in a CLASSPATH than to a .class file.  In
Godmar> fact, one simple solution would just be to allow .so files
Godmar> alongside .zip, .jar, or directory paths in a CLASSPATH var
Godmar> (or GCJ_CLASSPATH, as the case may be.)  There shouldn't have
Godmar> to be any relationship between the name of the class being
Godmar> loaded and the name of the .so file, me thinks.

First, I don't have any problem changing the current implementation if
that is what we decide.

There are two reasons I like the way things are right now:

1. We don't load every .so around in order to find a given class.

2. We don't require the user to set his CLASSPATH to include every .so
installed on the system.  For instance, suppose we package AWT as a
.so ("java-awt.so") and Swing as a .so ("javax-swing.so").  So then
the user has to add both of these to his CLASSPATH.  But then if we
add another new package, everybody has to update CLASSPATH.  With the
current scheme, we just have to arrange to have the properly-named
.so's appear in the appropriate directory.  (For system packagers like
Debian or Red Hat, this means you can just drop the new .so into /lib
and everything will magically work.)

I also don't think that the naming requirement is that big a burden.

That said, I'm curious to know why you (& Per) think that putting the
.so into CLASSPATH is the way to go.

Now it occurs to me that we'd also have to teach gcj to ignore a .so
in CLASSPATH.  (Not a big deal.)

Tom

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00   ` Matt Welsh
  2000-04-01  0:00     ` Tom Tromey
@ 2000-04-01  0:00     ` Bryce McKinlay
  1 sibling, 0 replies; 33+ messages in thread
From: Bryce McKinlay @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Matt Welsh; +Cc: Tom Tromey, Bryce McKinlay, java-discuss

Matt Welsh wrote:

> As I mentioned in my other message, the newest libgcj doesn't compile
> with gcc 2.95.2 (darn). I'm building the latest CVS egcs right now. Do I
> still need to apply Bryce's patch?

No, my patch just brings 2.95.2 up to speed if (for whatever reason) you
want to compile the latest libgcj with it. I hacked it together a while back
because at the time the gcc in cvs was buggy and I wanted a stable platform
to hack libgcj with. Now the cards have turned: 2.95.2 has a nasty bug to do
with jbooleans in C++ that shows up with the new interface lookup stuff, so
I don't use it anymore. The cvs gcc has been pretty stable recently.

regards

  [ bryce ]


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00 Dynamic class loading Matt Welsh
  2000-04-01  0:00 ` Bryce McKinlay
@ 2000-04-01  0:00 ` Tom Tromey
  2000-04-01  0:00   ` Matt Welsh
  2000-04-01  0:00   ` Kresten Krab Thorup
  1 sibling, 2 replies; 33+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Matt Welsh; +Cc: Bryce McKinlay, java-discuss

Matt> Great! This is the feature I have been waiting for! What version
Matt> of gcj supports it?

The latest HEAD libgcj supports this.  You can build this libgcj with
either the latest gcc (unstable) or with gcc 2.95.2 if you grab
Bryce's gcj update patches (you'll have to search the list archives
since I don't have the URL handy).

Matt> Since I'm hesitant to run a less stable gcj/libgcj snapshot, I'd
Matt> like to know if there are any plans for labelling a version with
Matt> this feature as "stable" (as libgcj 2.95.2 was).

Currently we don't have a plan for this, because the new libgcj relies
on changes to the compiler -- and re-releasing a subdir of the
compiler seems a bit bogus.

I haven't heard anything about the gcc release plans.  I don't even
know what the gating factors are there.

I agree this isn't the best situation.

Matt> Also, this description is a little confusing. First you say that
Matt> if a class can't be found, the interpreter will be used, but now
Matt> you're saying that a shared object will be searched for
Matt> first. Maybe we should unify the description of the interpreter
Matt> and the shared-library search mechanism.

First we try to load a .so.  Then we try to find the .class file for
the interpreter.  This choice was fairly arbitrary.

Matt> Also, where are the .so's searched for? Only the current
Matt> directory? Or on LD_LIBRARY_PATH? It might make sense for
Matt> CLASSPATH to be searched first, or perhaps something like
Matt> GCJ_CLASSPATH.

We use libltdl to load libraries.

So we search the libltdl path (LTDL_LIBRARY_PATH) followed by the
system search path (eg LD_LIBRARY_PATH, but this depends on the
system).

We could add another variable fairly easily.

Would searching CLASSPATH get right answers enough?  I'd expect
CLASSPATH to hold mostly architecture-independent paths (on systems
where people make this distinction -- anyway maybe we shouldn't
encourage people to conflate the two).

Tom

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00           ` Tom Tromey
@ 2000-04-01  0:00             ` Bryce McKinlay
  2000-04-01  0:00               ` Per Bothner
  2000-04-01  0:00             ` Godmar Back
  1 sibling, 1 reply; 33+ messages in thread
From: Bryce McKinlay @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Godmar Back, Kresten Krab Thorup, Matt Welsh, java-discuss

Tom Tromey wrote:

> Suppose you are looking for a class quux.foo.bar.
> The system class loader will first look for a .so named quux-foo-bar.so.
> If that fails (either not found, or doesn't provide the class), it
> will look for quux-foo.so.
> Then it will look for quux.so.

And, of course, it searches for these .so files on LD_LIBRARY_PATH, not
CLASSPATH. Personally I'm not sure that confusing the two is really a good idea.
CLASSPATH is for class files, not system-dependent native code. And if we start
putting .so's on there, it could potentially cause problems with existing java
applications.

  [ bryce ]


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Dynamic class loading
@ 2000-04-01  0:00 Matt Welsh
  2000-04-01  0:00 ` Bryce McKinlay
  2000-04-01  0:00 ` Tom Tromey
  0 siblings, 2 replies; 33+ messages in thread
From: Matt Welsh @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Bryce McKinlay; +Cc: java-discuss

Hi Bryce et. al., 

Thanks for updating the NEWS file. I have a couple of questions:

> +* Runtime.loadLibrary() has been implemented. In addition, Class.forName() 
> +will try to load a series of shared objects in order to find the requested 
> +class.  If a class `gnu.quux.whatever' is requested, libgcj will first look 
> +for `gnu-quux-whatever.so', then `gnu-quux.so', and finally `gnu.so'.

Great! This is the feature I have been waiting for! What version of gcj 
supports it? Since I'm hesitant to run a less stable gcj/libgcj snapshot, 
I'd like to know if there are any plans for labelling a version with 
this feature as "stable" (as libgcj 2.95.2 was).

Also, this description is a little confusing. First you say that if a class
can't be found, the interpreter will be used, but now you're saying that 
a shared object will be searched for first. Maybe we should unify the 
description of the interpreter and the shared-library search mechanism.

Also, where are the .so's searched for? Only the current directory? Or
on LD_LIBRARY_PATH? It might make sense for CLASSPATH to be searched first,
or perhaps something like GCJ_CLASSPATH. 

I would argue that the mechanism for searching for .so files should be as
close as possible to the mechanism for searching for .class files. However,
I like the idea of wrapping up a whole package into a single .so.

Cheers -
Matt

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00           ` Tom Tromey
  2000-04-01  0:00             ` Bryce McKinlay
@ 2000-04-01  0:00             ` Godmar Back
  1 sibling, 0 replies; 33+ messages in thread
From: Godmar Back @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey
  Cc: Godmar Back, Tom Tromey, Kresten Krab Thorup, Matt Welsh,
	Bryce McKinlay, java-discuss

 I see.  

So .so files always override CLASSPATH settings.
You'd have to delete them or remove them from your LD_LIBRARY_PATH
if you didn't want them to be looked at first.  If you're a non-privileged
user and someone dropped javax-servlet.so in /lib, you couldn't test your
own ./javax/servlet/Servlet.class?  (Is this so?)

This could of course be fixed by telling it how to ignore those
files.  Sure, why not.


Regarding Kresten's suggestion that a class loader should decide:
I thought that .so files should only be used to resolve classes once
a class loader invoked findSystemClass(), i.e., only for classes in
the "primordial" bootstrap classloader path.  
Would it make sense to associate loaded classes in a .so file with a 
classloader as their defining loader?  After all, because of the dumbness 
of dynamic linkers, you can't have multiple definitions in multiple 
namespaces anyway.  I'm not sure though, it may be desirable, for instance
for purposes of unloading upon gcing the loader.

	- Godmar


> 
> Godmar> Could you summarize in a paragraph or two what the current
> Godmar> algorithm is?
> 
> Sure.
> 
> Suppose you are looking for a class quux.foo.bar.
> The system class loader will first look for a .so named quux-foo-bar.so.
> If that fails (either not found, or doesn't provide the class), it
> will look for quux-foo.so.
> Then it will look for quux.so.
> 
> If none of that works it will search for a .class file using
> CLASSPATH.
> 
> Tom
> 

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00   ` Matt Welsh
@ 2000-04-01  0:00     ` Tom Tromey
  2000-04-01  0:00     ` Bryce McKinlay
  1 sibling, 0 replies; 33+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Matt Welsh; +Cc: Tom Tromey, Bryce McKinlay, java-discuss

Matt> As I mentioned in my other message, the newest libgcj doesn't
Matt> compile with gcc 2.95.2 (darn). I'm building the latest CVS egcs
Matt> right now. Do I still need to apply Bryce's patch?

Nope.  Last I heard there were some problems building the latest gcc,
though.  I think you have to bootstrap with -fno-builtin.  You might
want to check the recent java-discuss archives.  Bummer.

Matt> That's what I figured - just wanted to get that
Matt> documented. Maybe it's time for someone (me?) to take a crack at
Matt> a GCJ-HOWTO :-)

Sounds good.

I spent some time this weekend working towards getting FAQ-O-Matic
installed for all the projects on sourceware (not just gcc, as it is
now).  Maybe we could use that for these tasks.

Matt> One cute hack would be to have the "interpreter" fork off an
Matt> instance of gcj to quietly compile a .class into a .so in the
Matt> background, and load it right from /tmp - so that someone with
Matt> an existing set of .class files doesn't even know gcj is there
Matt> :-)

A really, really slow JIT :-)

Tom

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00       ` Tom Tromey
@ 2000-04-01  0:00         ` Per Bothner
  2000-04-01  0:00           ` Bryce McKinlay
  2000-04-01  0:00         ` Alexandre Oliva
  2000-04-01  0:00         ` Godmar Back
  2 siblings, 1 reply; 33+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Tom Tromey <tromey@cygnus.com> writes:

> There are two reasons I like the way things are right now:
> 
> 1. We don't load every .so around in order to find a given class.

The proposal is to only load .so files listed in the (explicitly or
implicitly) CLASSPATH, or explicitly loaded using System.loadLibrary.
Still, there is a disadvantage in that you at least conceptuallly
have to load every .so file in the CLASSPATH at startup, even though
some .so files may be useless.

One compromize/efficiency hack:  If a .so file or a .jar.zip file
has a name that matches a certain pattern, then we know that
it can only contain classes from packages matching that pattern.
For example, we can define a convention that library named
"ONLY$java$awt.so" can only contain classes in the package java.awt
or its sub-packages; hence the system classloader can defer loading
ONLY$java$awt.so until it actually needs a class in java.awt.

> 2. We don't require the user to set his CLASSPATH to include every .so
> installed on the system.  For instance, suppose we package AWT as a
> .so ("java-awt.so") and Swing as a .so ("javax-swing.so").  So then
> the user has to add both of these to his CLASSPATH.  But then if we
> add another new package, everybody has to update CLASSPATH.

No, these are found using the default (implied) CLASSPATH, just
like Sun's Java finds classes.zip (JDK 1.1) or rt.jar (JDK 1.2) 
using a default CLASSPATH.

> With the
> current scheme, we just have to arrange to have the properly-named
> .so's appear in the appropriate directory.  (For system packagers like
> Debian or Red Hat, this means you can just drop the new .so into /lib
> and everything will magically work.)

It is worth looking at Sun's extension mechanism, specifically
"installed extensions".  See:
http://www.javasoft.com/products/jdk/1.2/docs/guide/extensions/extensions.html

The basic idea is that all .jar files in a certain "magic" directory
are automatically added to the end of the CLASSPATH.  If we have a .so
containing pre-compiled classes, it seems a natural "extension"
of the the Java2 extension model to also add all .so files in the same
magic directory to the CLASSPATH.

> I also don't think that the naming requirement is that big a burden.

Not necessarily, but I think it is less flexible.  More importantantly,
it is inconsistent to how Sun does it, which would complicate people
porting applications and extensions to gcj.

> Now it occurs to me that we'd also have to teach gcj to ignore a .so
> in CLASSPATH.  (Not a big deal.)

Actually, ideally you would not have gcj ignore a .so on the CLASSPATH;
you would gcj do a dlopen on the .so file, and get the class reflective
information from the loaded .so file.  Of course this only works for .so
files in the host machine's archicture;  it would also be more trouble
to implement than it is worth.  So ignore .so files - or issuing a
warning, make more sense.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00       ` Tom Tromey
  2000-04-01  0:00         ` Per Bothner
  2000-04-01  0:00         ` Alexandre Oliva
@ 2000-04-01  0:00         ` Godmar Back
  2000-04-01  0:00           ` Tom Tromey
  2 siblings, 1 reply; 33+ messages in thread
From: Godmar Back @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey
  Cc: Godmar Back, Kresten Krab Thorup, Tom Tromey, Matt Welsh,
	Bryce McKinlay, java-discuss

> 
> There are two reasons I like the way things are right now:
> 

Could you summarize in a paragraph or two what the current algorithm is?

For instance, how is looking up by class name and putting java.awt.*
in java-awt.so as you describe in your previous mail related?

thanks,

	- Godmar

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00 ` Tom Tromey
@ 2000-04-01  0:00   ` Matt Welsh
  2000-04-01  0:00     ` Tom Tromey
  2000-04-01  0:00     ` Bryce McKinlay
  2000-04-01  0:00   ` Kresten Krab Thorup
  1 sibling, 2 replies; 33+ messages in thread
From: Matt Welsh @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Bryce McKinlay, java-discuss

Thanks for the quick response, Tom.

> The latest HEAD libgcj supports this.  You can build this libgcj with
> either the latest gcc (unstable) or with gcc 2.95.2 if you grab
> Bryce's gcj update patches (you'll have to search the list archives
> since I don't have the URL handy).

As I mentioned in my other message, the newest libgcj doesn't compile
with gcc 2.95.2 (darn). I'm building the latest CVS egcs right now. Do I 
still need to apply Bryce's patch?

> First we try to load a .so.  Then we try to find the .class file for
> the interpreter.  This choice was fairly arbitrary.

That's what I figured - just wanted to get that documented. Maybe it's
time for someone (me?) to take a crack at a GCJ-HOWTO :-)

> Would searching CLASSPATH get right answers enough?  I'd expect
> CLASSPATH to hold mostly architecture-independent paths (on systems
> where people make this distinction -- anyway maybe we shouldn't
> encourage people to conflate the two).

Not sure - that's why I suggested we have a GCJ_CLASSPATH which overrides
that decision.

libltdl lets one specify a "user search path" which we could easily plug
with the appropriate value.

First I'll get it working and then think about the right way to do this.
It might be that what's in there now is perfectly fine; however, I have 
a large project based on GCJ and would like to make this aspect of it 
as seamless as possible (to help people migrating off of a traditional
JVM).

One cute hack would be to have the "interpreter" fork off an instance of
gcj to quietly compile a .class into a .so in the background, and load it
right from /tmp - so that someone with an existing set of .class files 
doesn't even know gcj is there :-)

Cheers -
Matt


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00   ` Kresten Krab Thorup
@ 2000-04-01  0:00     ` Godmar Back
  2000-04-01  0:00       ` Per Bothner
  2000-04-01  0:00       ` Tom Tromey
  0 siblings, 2 replies; 33+ messages in thread
From: Godmar Back @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Kresten Krab Thorup; +Cc: Tom Tromey, Matt Welsh, Bryce McKinlay, java-discuss

> 
> Tom Tromey <tromey@cygnus.com> writes:
> 
> > First we try to load a .so.  Then we try to find the .class file for
> > the interpreter.  This choice was fairly arbitrary.
> > 
> 

It seems that .so files should be treated more similar to .jar or .zip
entries in a CLASSPATH than to a .class file.  In fact, one simple
solution would just be to allow .so files alongside .zip, .jar, or
directory paths in a CLASSPATH var (or GCJ_CLASSPATH, as the case may be.)
There shouldn't have to be any relationship between the name of
the class being loaded and the name of the .so file, me thinks.

Of course, there are important differences that must be accounted for
somehow:  for instance, if you define class A from x.so, you'll have to 
define all classes that are contained in x.so from there or else your
dynamic linker will complain.
(Unlike in a .jar archive, which you can treat as a directory of files
that are not related by much more than their being part of a group.)

	- Godmar

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00       ` Tom Tromey
  2000-04-01  0:00         ` Per Bothner
@ 2000-04-01  0:00         ` Alexandre Oliva
  2000-04-01  0:00           ` Tom Tromey
  2000-04-01  0:00         ` Godmar Back
  2 siblings, 1 reply; 33+ messages in thread
From: Alexandre Oliva @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey
  Cc: Godmar Back, Kresten Krab Thorup, Matt Welsh, Bryce McKinlay,
	java-discuss

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On Feb 16, 2000, Tom Tromey <tromey@cygnus.com> wrote:

>>>>>> "Godmar" == Godmar Back <gback@cs.utah.edu> writes:
Godmar> It seems that .so files should be treated more similar to .jar
Godmar> or .zip entries in a CLASSPATH than to a .class file.

Agreed.

> First, I don't have any problem changing the current implementation if
> that is what we decide.

> There are two reasons I like the way things are right now:

Can't we have both?

-- 
Alexandre Oliva     http://www.ic.unicamp.br/~oliva/     Enjoy Guaraná
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00 ` Tom Tromey
  2000-04-01  0:00   ` Matt Welsh
@ 2000-04-01  0:00   ` Kresten Krab Thorup
  2000-04-01  0:00     ` Godmar Back
  1 sibling, 1 reply; 33+ messages in thread
From: Kresten Krab Thorup @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Matt Welsh, Bryce McKinlay, java-discuss

Tom Tromey <tromey@cygnus.com> writes:

> First we try to load a .so.  Then we try to find the .class file for
> the interpreter.  This choice was fairly arbitrary.
> 

It appears to me that this decision should be delegated to the current
classloader, i.e. the class gnu.gcj.runtime.VMClassLoader should do
the searching and call Runtime.loadLibrary accordingly.

With such a design, other programmers may implement arbitrary new
search mechanisms (such as loading a .dll from the net).

-- Kresten

 Kresten Krab Thorup           "I like my eggs ploded"
 Department of Computer Science, University of Aarhus
 Aabogade 34, DK-8200 Aarhus N, Denmark
 +45 8942 5665 (office), +45 2343 4626 (mobile)

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00         ` Per Bothner
@ 2000-04-01  0:00           ` Bryce McKinlay
  0 siblings, 0 replies; 33+ messages in thread
From: Bryce McKinlay @ 2000-04-01  0:00 UTC (permalink / raw)
  To: egcs; +Cc: java-discuss

Per Bothner wrote:

> Tom Tromey <tromey@cygnus.com> writes:
>
> > There are two reasons I like the way things are right now:
> >
> > 1. We don't load every .so around in order to find a given class.
>
> The proposal is to only load .so files listed in the (explicitly or
> implicitly) CLASSPATH, or explicitly loaded using System.loadLibrary.
> Still, there is a disadvantage in that you at least conceptuallly
> have to load every .so file in the CLASSPATH at startup, even though
> some .so files may be useless.

This makes sense since it is somewhat different to the way LD_LIBRARY_PATH is
used currently, where each of the directories in the list are searched for .so
files matching a certain pattern. But why is it necessary to use the CLASSPATH
var to do this? Why not GCJ_CLASSPATH or some such? If gcj itself needs to be
changed to ignore .so files on the classpath, then there are doubtlessly other
java compilers and runtimes that are going to complain (or worse, break) if they
find strange files on their classpath. Then again I'm not sure we want too many
different ways of potentially loading classes, I already have enough trouble
sometimes with stale .class files lurking on my classpath somewhere.

Its also worth remembering that we're allways going to need to keep .class files
around in CLASSPATH for compilation purposes. It would be annoying, or at least
strange, to be able to execute classes but not actually compile against them.
Although, if its indeed possible to compile .java source directly against .so
files, that would be a very cool feature!

> One compromize/efficiency hack:  If a .so file or a .jar.zip file
> has a name that matches a certain pattern, then we know that
> it can only contain classes from packages matching that pattern.
> For example, we can define a convention that library named
> "ONLY$java$awt.so" can only contain classes in the package java.awt
> or its sub-packages; hence the system classloader can defer loading
> ONLY$java$awt.so until it actually needs a class in java.awt.

Well, Tom's existing method doesn't need hacks like this. The classloader doesn't
need to load java-awt.so until a java.awt class is requested.

> > I also don't think that the naming requirement is that big a burden.
>
> Not necessarily, but I think it is less flexible.  More importantantly,
> it is inconsistent to how Sun does it, which would complicate people
> porting applications and extensions to gcj.

Loading class files from .so's is not something Sun have ever done. People
porting applications from traditional VM environments are going to have to adapt
to things like this regardless. CLASSPATH has been one of the biggest flaws and
source of problems in traditional VMs (which is why Sun have worked around it
somewhat in JDK 1.2 with things like the extensions directory, executable .jars,
etc).  I'd like to think we can come up with something better for gcj.

regards

  [ bryce ]


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00 Dynamic class loading Matt Welsh
@ 2000-04-01  0:00 ` Bryce McKinlay
  2000-04-01  0:00 ` Tom Tromey
  1 sibling, 0 replies; 33+ messages in thread
From: Bryce McKinlay @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Matt Welsh; +Cc: java-discuss

Matt Welsh wrote:

> Also, this description is a little confusing. First you say that if a class
> can't be found, the interpreter will be used, but now you're saying that
> a shared object will be searched for first. Maybe we should unify the
> description of the interpreter and the shared-library search mechanism.

Thanks Matt, I checked in some changes to try and make this a bit clearer.

regards

  [ bryce ]


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00             ` Bryce McKinlay
@ 2000-04-01  0:00               ` Per Bothner
  0 siblings, 0 replies; 33+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Bryce McKinlay <bryce@albatross.co.nz> writes:

> And, of course, it searches for these .so files on LD_LIBRARY_PATH,
> not CLASSPATH. Personally I'm not sure that confusing the two is
> really a good idea.  CLASSPATH is for class files, not
> system-dependent native code. And if we start putting .so's on
> there, it could potentially cause problems with existing java
> applications.

Possibly, but I'd like a specific scenario likely to cause trouble.

I don't see why CLASSPATH can't contain system-dependent native code.
CLASSPATH specifies a search path of "logical directories", i.e.
places to look for Java classes.  If you have a bunch of Java classes,
you can "install" them on your system in three ways:  as a directory
containing .class files;  as a .zip or .jar archive;  as a .so archive.
I think logically, you should use CLASSPATH for all of them.

Notice that System.loadLibrary is a separate issue.  LD_LIBRARY_PATH
is used for searching for .so files;  CLASSPATH is used for searching
for Java classes.  Native JNI methods are found using LD_LIBRARY_PATH,
unless they have been statically linked somehow.  Native CNI methods
can be found using either LD_LIBRARY_PATH, or they can be linked into
the same .so files that contains the Java Class objects, in which
case they are found using CLASSPATH.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00         ` Godmar Back
@ 2000-04-01  0:00           ` Tom Tromey
  2000-04-01  0:00             ` Bryce McKinlay
  2000-04-01  0:00             ` Godmar Back
  0 siblings, 2 replies; 33+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Godmar Back
  Cc: Tom Tromey, Kresten Krab Thorup, Matt Welsh, Bryce McKinlay,
	java-discuss

Godmar> Could you summarize in a paragraph or two what the current
Godmar> algorithm is?

Sure.

Suppose you are looking for a class quux.foo.bar.
The system class loader will first look for a .so named quux-foo-bar.so.
If that fails (either not found, or doesn't provide the class), it
will look for quux-foo.so.
Then it will look for quux.so.

If none of that works it will search for a .class file using
CLASSPATH.

Tom

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00     ` Godmar Back
@ 2000-04-01  0:00       ` Per Bothner
  2000-04-01  0:00       ` Tom Tromey
  1 sibling, 0 replies; 33+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Godmar Back; +Cc: java-discuss

Godmar Back <gback@cs.utah.edu> writes:

> It seems that .so files should be treated more similar to .jar or .zip
> entries in a CLASSPATH than to a .class file.  In fact, one simple
> solution would just be to allow .so files alongside .zip, .jar, or
> directory paths in a CLASSPATH var (or GCJ_CLASSPATH, as the case may be.)
> There shouldn't have to be any relationship between the name of
> the class being loaded and the name of the .so file, me thinks.

I agree. I thought that was the plan.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  2000-04-01  0:00         ` Alexandre Oliva
@ 2000-04-01  0:00           ` Tom Tromey
  0 siblings, 0 replies; 33+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Alexandre Oliva
  Cc: Tom Tromey, Godmar Back, Kresten Krab Thorup, Matt Welsh,
	Bryce McKinlay, java-discuss

Alexandre> Can't we have both?

I can't think of a reason why not.

Tom

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Dynamic class loading
@ 2000-10-02 23:58 Torsten Rüger
  0 siblings, 0 replies; 33+ messages in thread
From: Torsten Rüger @ 2000-10-02 23:58 UTC (permalink / raw)
  To: Java

Hi,

I have tried to compile Apache-JServ. That went ok, but it didn't run.
That is it did but produced a core dump with an endlessly big
stack. I think what happened is that the dynamic class loading doesn't
work.

Specifiaclly JServ overloads the Classloader (to load servlets) and
maybe that is the problem. I have attached the file which I would assume
to cause the problem, can anyone verify this?

Cheers

    Torsten

^ permalink raw reply	[flat|nested] 33+ messages in thread

* RE: Dynamic class loading
@ 2000-04-01  0:00 Glenn Chambers
  0 siblings, 0 replies; 33+ messages in thread
From: Glenn Chambers @ 2000-04-01  0:00 UTC (permalink / raw)
  To: 'Tom Tromey', Matt Welsh; +Cc: Bryce McKinlay, java-discuss

> Nope.  Last I heard there were some problems building the latest gcc,
> though.  I think you have to bootstrap with -fno-builtin.  You might
> want to check the recent java-discuss archives.  Bummer.

As of a few nights ago, I was able to get things to work by using
the latest CVS of both EGCS and LIBGCJ, with one sick little hack:

1.  Update CVS as normal
2.  make bootstrap (no 'special' switches)
3.  make install 
4.  delete egcs/gcc/tree.o
5.  make CFLAGS=-fno-builtin 
6.  make install

Doing the entire bootstrap with '-fno-builtin' doesn't work as
of the last CVS download I did.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  1999-05-01 16:09       ` Archie Cobbs
@ 1999-05-01 16:21         ` Per Bothner
  0 siblings, 0 replies; 33+ messages in thread
From: Per Bothner @ 1999-05-01 16:21 UTC (permalink / raw)
  To: Archie Cobbs; +Cc: java-discuss

> I'm curious to hear what evidence and/or conjecture you use to
> make this point, ie. that JNI native methods would be (on average)
> slower than interpreting the same method.

If the method body just does some arithmetic calculation, without
accessing fields of Java objects, invoking Java methods, or
indexing into Java arrays, then compiled code will be faster.
But as soon as you need to actually access *data*, if you have to
call a JNI function to do it, you will lose, because you will get
the JNI overhead.  For example, to get a contents of a field
(even a field of `this'), you have to call the GetXXXField JNI
method.  This is likely to be substantially slower than just
executing a `getfield' bytecode instruction, especially if use a JIT.

	--Per Bothner
bothner@cygnus.com     http://www.cygnus.com/~bothner

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  1999-05-01 15:31     ` Per Bothner
@ 1999-05-01 16:09       ` Archie Cobbs
  1999-05-01 16:21         ` Per Bothner
  0 siblings, 1 reply; 33+ messages in thread
From: Archie Cobbs @ 1999-05-01 16:09 UTC (permalink / raw)
  To: java-discuss; +Cc: bothner

Per Bothner writes:
> On the order hand, one could change gcj to generate code that
> is portable to any jvm that supports jni.  But there is no point
> in that either, since the resulting code will be *slower* than
> using an interpreter (due to all the required jni calls).

I'm curious to hear what evidence and/or conjecture you use to
make this point, ie. that JNI native methods would be (on average)
slower than interpreting the same method.

JNI does have a lot of overhead, etc. so it's entirely plausible.
I'm wondering however if you have actually verified this in some way.

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  1999-05-01 14:39   ` Jules Bean
@ 1999-05-01 15:31     ` Per Bothner
  1999-05-01 16:09       ` Archie Cobbs
  0 siblings, 1 reply; 33+ messages in thread
From: Per Bothner @ 1999-05-01 15:31 UTC (permalink / raw)
  To: Jules Bean; +Cc: Sean McEligot, java-discuss

> What developer A now wants to do is compile, using gcj, his classes (or
> some of them, anyway - the CPU intensive ones) into native code, but
> automatically provide jni stubs so that as far as developer B is
> concerened, they're just normal native classes.

It is not going to work, because the output of the gcj compiler is
very dependent on the run-time environment.  Thus it will not be
portable if (say) B uses the jdk.  And if it isn't portable, what's
the point?

On the order hand, one could change gcj to generate code that
is portable to any jvm that supports jni.  But there is no point
in that either, since the resulting code will be *slower* than
using an interpreter (due to all the required jni calls).

	--Per Bothner
bothner@cygnus.com     http://www.cygnus.com/~bothner

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  1999-05-01 12:45 ` Per Bothner
@ 1999-05-01 14:39   ` Jules Bean
  1999-05-01 15:31     ` Per Bothner
  0 siblings, 1 reply; 33+ messages in thread
From: Jules Bean @ 1999-05-01 14:39 UTC (permalink / raw)
  To: Per Bothner; +Cc: Sean McEligot, java-discuss

Per Bothner wrote:
> > from this create the class equivalent of:
> > public class Simple {
> >     native Simple getInstance();
> >     native void hello():
> > }
> 
> I utterly fail to see the point.

I think you're missing something here, Per (I explain below).

> 
> > I realize this is outside the purpose of gcj.
> 
> Yes - it is cmpletely unrelated to what we're trying to do.
> 
> >  Its not something I expect it to
> > do. I just think its an interesting idea that would be useful.
> 
> Why?
> 
> > If nothing else it would allow developers (or managers) to ease into
> > gcj without having to compile the entire program into an executable.
> 
> There are better way to do that.  For example add an interpreter and
> support for ClassLoader to libgcj.

Not for what Sean appears to be suggesting.

My understanding of Sean is something like this:

Developer A currently produces a class library for use by developer B. 
Developer A's class library contains a few native classes and lots of
normal, java-compiled stuff.

What developer A now wants to do is compile, using gcj, his classes (or
some of them, anyway - the CPU intensive ones) into native code, but
automatically provide jni stubs so that as far as developer B is
concerened, they're just normal native classes.

I.e. what Sean wants to do is code his java partly bytecode, partly
native, but rather than writing the native bits in C, he wants to write
them in Java too.

I can see that would be neat, too..

Jules



-- 
/----------------+-------------------------------+---------------------\
|  Jelibean aka  | jules@jellybean.co.uk         |  6 Evelyn Rd        |
|  Jules aka     |                               |  Richmond, Surrey   |
|  Julian Bean   | jmlb2@hermes.cam.ac.uk        |  TW9 2TF *UK*       |
+----------------+-------------------------------+---------------------+
|  War doesn't demonstrate who's right... just who's left.             |
|  When privacy is outlawed... only the outlaws have privacy.          |
\----------------------------------------------------------------------/

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  1999-04-30 17:51 Sean McEligot
@ 1999-05-01 12:45 ` Per Bothner
  1999-05-01 14:39   ` Jules Bean
  0 siblings, 1 reply; 33+ messages in thread
From: Per Bothner @ 1999-05-01 12:45 UTC (permalink / raw)
  To: Sean McEligot; +Cc: java-discuss

> I mean compiling java into object (.o) files as opposed to .class files.
> Then link it to a jni compatible library file (.so or .dll)

Yes, we intend to support that.  We'd need an option or a wrapper
to indicate that the native methods are jni instead of cni.  The
details have not been nailed down, as our assumption is that other
features are higher priority than jni support.

> I didn't realize that gcj has its own jni.h. I was referring to to one that
> comes with the jdk.

We have the beginnings of a jni.h.  We do have to provide our own.
But note our jni.h has to be binary compatible with the jdk one
(that is the whole point of jni).

> from this create the class equivalent of:
> public class Simple {
>     native Simple getInstance();
>     native void hello():
> }

I utterly fail to see the point.

> I realize this is outside the purpose of gcj.

Yes - it is cmpletely unrelated to what we're trying to do.

>  Its not something I expect it to
> do. I just think its an interesting idea that would be useful.

Why?

> If nothing else it would allow developers (or managers) to ease into
> gcj without having to compile the entire program into an executable.

There are better way to do that.  For example add an interpreter and
support for ClassLoader to libgcj.

	--Per Bothner
bothner@cygnus.com     http://www.cygnus.com/~bothner



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
@ 1999-04-30 17:51 Sean McEligot
  1999-05-01 12:45 ` Per Bothner
  0 siblings, 1 reply; 33+ messages in thread
From: Sean McEligot @ 1999-04-30 17:51 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

>> While we're on the topic, what about they other way around? What are your
>> ideas on generating a native interface for a compiled object file?
>
> --Per Bothner wrote
>I don't understand the question.  What is a "native interface for a
>compiled object file"?
>
I mean compiling java into object (.o) files as opposed to .class files.
Then link it to a jni compatible library file (.so or .dll)

>Notice that compiled code has full support for reflection.  (We haven't
>implemented Method.invoke yet, but we hope to soon.)  Both compiled
>code and interpreted code will use the same reflective interface.
>
>> The hard part is getting jni to recognize java::lang::Object as a jni
>> jobject.
>
>No, it's trivial:  That's how jobject is defined.

I didn't realize that gcj has its own jni.h. I was referring to to one that
comes with the jdk.

>
>> Could the compiled object file extend both? This would be usefull
>> for native compiling a small piece of processor intensive java code
without
>> having compiling the whole program.
>
>Oh, you mean:  Could a pre-compiled class extend an interpreted class?
>No reason why not, in principle, though I don't think it makes
>much sense.
>

Not exactly.

take a java source file:

public class Simple {
  public Simple getInstance() {
    return new Simple();
  }
  public void hello() {
    System.out.println("Hello World");
  }
  }

from this create the class equivalent of:

public class Simple {
    native Simple getInstance();
    native void hello():
}

... and the object (.o) equivalent of:

// simple.cc
#include <jni.h>
#include <cni.h>
#include <Simple.h>
JNIEXPORT jobject JNICALL Java_Simple_getInstance
  (JNIEnv *, jclass) {
    Simple* gcj_simple = new Simpe();
    // return a jobject that is an instance of the Simple class with native
methods above
  }

JNIEXPORT void JNICALL Java_Simple_hello
  (JNIEnv *, jobject) {
  // get gcj_simple which is somehow mapped
  // to the jobject we returned in Java_Simple_getInstance()
    gcj_simple->hello();
}


This is rough and I haven't tried any of it yet. The idea is to run this on
a Java virtual machine with a jni library (.so, .dll) created by gcj . I
realize this is outside the purpose of gcj. Its not something I expect it to
do. I just think its an interesting idea that would be useful. If nothing
else it would allow developers (or managers) to ease into gcj without having
to compile the entire program into an executable.  I want to know if anyone
else has given this thought. Maybe I'm missing something that makes this
either much easier or nearly impossible.

Sean McEligot


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  1999-04-30 15:47 Sean McEligot
@ 1999-04-30 16:05 ` Per Bothner
  0 siblings, 0 replies; 33+ messages in thread
From: Per Bothner @ 1999-04-30 16:05 UTC (permalink / raw)
  To: Sean McEligot; +Cc: java-discuss

> While we're on the topic, what about they other way around? What are your
> ideas on generating a native interface for a compiled object file?

I don't understand the question.  What is a "native interface for a 
compiled object file"?

Notice that compiled code has full support for reflection.  (We haven't
implemented Method.invoke yet, but we hope to soon.)  Both compiled
code and interpreted code will use the same reflective interface.

> The hard part is getting jni to recognize java::lang::Object as a jni
> jobject.

No, it's trivial:  That's how jobject is defined.

> Could the compiled object file extend both? This would be usefull
> for native compiling a small piece of processor intensive java code without
> having compiling the whole program.

Oh, you mean:  Could a pre-compiled class extend an interpreted class?
No reason why not, in principle, though I don't think it makes
much sense.

	--Per Bothner
bothner@cygnus.com     http://www.cygnus.com/~bothner


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
@ 1999-04-30 15:47 Sean McEligot
  1999-04-30 16:05 ` Per Bothner
  0 siblings, 1 reply; 33+ messages in thread
From: Sean McEligot @ 1999-04-30 15:47 UTC (permalink / raw)
  To: java-discuss

While we're on the topic, what about they other way around? What are your
ideas on generating a native interface for a compiled object file? The
constructor would have to be replaced with a getInstance() method since the
jvm does (to my knowledge) support native constructors. That's the easy
part. The hard part is getting jni to recognize java::lang::Object as a jni
jobject. Could the compiled object file extend both? This would be usefull
for native compiling a small piece of processor intensive java code without
having compiling the whole program.

Any plans? Ideas?

Sean McEligot




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  1999-04-30 15:00 ` Tom Tromey
@ 1999-04-30 15:06   ` Patrick Tullmann
  0 siblings, 0 replies; 33+ messages in thread
From: Patrick Tullmann @ 1999-04-30 15:06 UTC (permalink / raw)
  To: tromey, Vincent Sheffer; +Cc: java-discuss

Another option is to use Kaffe.  While Kaffe doesn't yet fully support
gcj compiled classes---there is some support---its definetly on the
todo list.  www.kaffe.org  (I'm not a member of the Kaffe Core Team,
though, so I may not know of what I speak.)

Depending on your mix of static/dynamic code gcj+dynamic-code might make
more or less sense than kaffe+static-code.

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann@cs.utah.edu
     "VR Cows are a medium rarely well done." -- someone in c.g.a

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  1999-04-30 13:49 Vincent Sheffer
  1999-04-30 14:36 ` Per Bothner
@ 1999-04-30 15:00 ` Tom Tromey
  1999-04-30 15:06   ` Patrick Tullmann
  1 sibling, 1 reply; 33+ messages in thread
From: Tom Tromey @ 1999-04-30 15:00 UTC (permalink / raw)
  To: Vincent Sheffer; +Cc: java-discuss

>>>>> "Vincent" == Vincent Sheffer <vsheffer@spinsoftware.com> writes:

Vincent> First, are there plans to support dynamic classloading?
Vincent> And, second, if there are how do you plan to support them?

As Per says, eventually we'll probably write a bytecode interpreter.

Sometime sooner than that, probably, we'll add the ability to load
compiled classes using dlopen (actually I imagine we'll use the ltdl
library from libtool).  I don't know when this will be implemented.

Tom

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Dynamic class loading
  1999-04-30 13:49 Vincent Sheffer
@ 1999-04-30 14:36 ` Per Bothner
  1999-04-30 15:00 ` Tom Tromey
  1 sibling, 0 replies; 33+ messages in thread
From: Per Bothner @ 1999-04-30 14:36 UTC (permalink / raw)
  To: Vincent Sheffer; +Cc: java-discuss

> First, are there plans to support dynamic classloading?

Yes, but I cannot say when.

> And, second, if there are how do you plan to support them?

Probably an interpreter, though a JIT is also an option.
There are some tricky issues when compiled code calls an
inpreted methods;  we plan to use "stub" functions in
between.

	--Per Bothner
bothner@cygnus.com     http://www.cygnus.com/~bothner

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Dynamic class loading
@ 1999-04-30 13:49 Vincent Sheffer
  1999-04-30 14:36 ` Per Bothner
  1999-04-30 15:00 ` Tom Tromey
  0 siblings, 2 replies; 33+ messages in thread
From: Vincent Sheffer @ 1999-04-30 13:49 UTC (permalink / raw)
  To: java-discuss

Two quick questions (well, maybe not too quick):

First, are there plans to support dynamic classloading?
And, second, if there are how do you plan to support them?

Thanks
Vincent Sheffer

^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~2000-10-02 23:58 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-01  0:00 Dynamic class loading Matt Welsh
2000-04-01  0:00 ` Bryce McKinlay
2000-04-01  0:00 ` Tom Tromey
2000-04-01  0:00   ` Matt Welsh
2000-04-01  0:00     ` Tom Tromey
2000-04-01  0:00     ` Bryce McKinlay
2000-04-01  0:00   ` Kresten Krab Thorup
2000-04-01  0:00     ` Godmar Back
2000-04-01  0:00       ` Per Bothner
2000-04-01  0:00       ` Tom Tromey
2000-04-01  0:00         ` Per Bothner
2000-04-01  0:00           ` Bryce McKinlay
2000-04-01  0:00         ` Alexandre Oliva
2000-04-01  0:00           ` Tom Tromey
2000-04-01  0:00         ` Godmar Back
2000-04-01  0:00           ` Tom Tromey
2000-04-01  0:00             ` Bryce McKinlay
2000-04-01  0:00               ` Per Bothner
2000-04-01  0:00             ` Godmar Back
  -- strict thread matches above, loose matches on Subject: below --
2000-10-02 23:58 Torsten Rüger
2000-04-01  0:00 Glenn Chambers
1999-04-30 17:51 Sean McEligot
1999-05-01 12:45 ` Per Bothner
1999-05-01 14:39   ` Jules Bean
1999-05-01 15:31     ` Per Bothner
1999-05-01 16:09       ` Archie Cobbs
1999-05-01 16:21         ` Per Bothner
1999-04-30 15:47 Sean McEligot
1999-04-30 16:05 ` Per Bothner
1999-04-30 13:49 Vincent Sheffer
1999-04-30 14:36 ` Per Bothner
1999-04-30 15:00 ` Tom Tromey
1999-04-30 15:06   ` Patrick Tullmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).