Re: native java libraries
On Tue, Mar 29, 2005 at 12:45:01PM +0200, spam2005@meeque.de wrote:
> Hi list.
>
>
> >>When these .so files are present (in the correct location,
> >>registered with the correct mechanism) gij will load them automatically
> >>and use them in the place of the corresponding .jar file.
>
> Though I don't know too much about GCJ/GIJ, I've followed the discussion about native java labraries
> with interest. IMO, all of this sounds interesting, but it should be an optional feature. The users
> should be able to decide whether to use it or not.
>
>
> Philipp Hug wrote:
> >Why don't we optionally compile the jars when the package is installed on the users machine?
>
> Isn't that similar to the way Python files are now handled in Debian? There it is source-files (*.py)
> vs. byte-code-files (*.pyc), whereas for Java it is byte-code-files (*.jar) vs. native-files (*.so).
> But otherwise the problem seems analog.
>
> I don't know exactly, how those compiled Python libraries are handled in Debian, but I've got the
> impression that they are compiled, when the package is installed. Maybe someone would mind to figure
> out if that's correct? Then you could ask the python guys for implementation details...
>
>
> Though in Debian the Python byte-code-files seem to be compiled on installation, the usual approach
> of a python interpreter is to compile such files on demand. I think, such an approach would be a good
> idea for native java libraries.
>
> So here is my proposal:
> Since the use of native java libraries is a feature of GCJ/GIJ only, the handling of those libraries
> should be left to those. GIJ should first check if there is native version of a java library. If not,
> it should compile one the first time it is needed, and persistently add it to a cache of native
> libraries (e.g. in somewhere in /var). This would mean a performance loss the first time a library is
> loaded, but might improve loading speed on future access.
>
> Such a feature could probably be implemented in some Debian-specific wrapper scripts for GIJ. Or
> someone could propose this feature to the upstream developers of GCJ/GIJ. Also, this feature should
> be optional, e.g. controlled by some configuration file or by an environment variable. Additionally
> some tools could be offered to monitor and manipulate the cache of native libraries manually.
>
> I havn't thought to much about implementation details yet, since I don't have enough knowledge
> anyway. But I think my approach should be possible somehow. The big benefit would be, that it does
> not have any impact on the archive space or the on disk space of users who can't benefit from it
> anyway. On the other hand, it would still offer easy access to native java libraries for all GIJ
> users who want that feature.
Have you looked into GCJ upstream sources? It does already most of what
you describe and Fedora uses it.
BTW: The Fedora people decided after a long discussion to compile to
native at build time of a package.
> Please tell me, if any of the above sounds reasonable! In any case, I'd advice to evaluate that
> native java libraries stuff carefully, before letting it have too much impact on *all* Java packages
> in Debian.
Well, it sounds reasonable but at as long as there are cases where
GCJ-4.0 compiles over 30 minutes on a recent system with 512MB of RAM
and then exits with an OutOfMemoryError this is more or less useless.
As said and decided before we need a proof that we really gain something
from compiling to native and not only get new problems.
Michael
--
Homepage: http://www.worldforge.org/
Reply to: