Patch: set default library control to LIB_NEVER

Patch: set default library control to LIB_NEVER

[Thomas Fitzsimmons]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

Hi,

This patch sets the default library control to LIB_NEVER.  This saves many 
failed access() and open() calls for large applications like Eclipse. 
Applications that still need the old library control can define the 
gnu.gcj.runtime.VMClassLoader.library_control system property to "cache".

OK to commit?

Tom

2006-05-31  Thomas Fitzsimmons  <fitzsim@redhat.com>

	* java/lang/VMClassLoader.java (initialize): Set default library
	control to LIB_NEVER.

[-- Attachment #2: libgcj-disable-library-control.patch --]
[-- Type: text/x-patch, Size: 405 bytes --]

Index: java/lang/VMClassLoader.java
===================================================================
--- java/lang/VMClassLoader.java	(revision 114136)
+++ java/lang/VMClassLoader.java	(working copy)
@@ -309,7 +309,7 @@
     else if ("full".equals(p))
       lib_control = LIB_FULL;
     else
-      lib_control = LIB_CACHE;
+      lib_control = LIB_NEVER;
 
     tried_libraries = new HashSet();
   }

Re: Patch: set default library control to LIB_NEVER

[Tom Tromey]

>>>>> "Tom" == Thomas Fitzsimmons <fitzsim@redhat.com> writes:

Tom> This patch sets the default library control to LIB_NEVER.  This
Tom> saves many failed access() and open() calls for large
Tom> applications like Eclipse.  Applications that still need the old
Tom> library control can define the
Tom> gnu.gcj.runtime.VMClassLoader.library_control system property to
Tom> "cache".

Tom> OK to commit?

Yes, this is ok.

It seems like this change should be documented somewhere.  Is there a
4.2 changes page yet?  That would probably be the best place.

Tom

Re: Patch: set default library control to LIB_NEVER

[Tom Tromey]

>>>>> "Tom" == Thomas Fitzsimmons <fitzsim@redhat.com> writes:

Tom> This patch sets the default library control to LIB_NEVER.  This
Tom> saves many failed access() and open() calls for large
Tom> applications like Eclipse.  Applications that still need the old
Tom> library control can define the
Tom> gnu.gcj.runtime.VMClassLoader.library_control system property to
Tom> "cache".

Oh, btw -- I think there was a PR for this.  Not sure though... you
might check.

Tom

Re: Patch: set default library control to LIB_NEVER

[Bryce McKinlay]

Tom Tromey wrote:
> Tom> This patch sets the default library control to LIB_NEVER.  This
> Tom> saves many failed access() and open() calls for large
> Tom> applications like Eclipse.  Applications that still need the old
> Tom> library control can define the
> Tom> gnu.gcj.runtime.VMClassLoader.library_control system property to
> Tom> "cache".
>
> Tom> OK to commit?
>
> Yes, this is ok.
>
> It seems like this change should be documented somewhere.  Is there a
> 4.2 changes page yet?  That would probably be the best place.
>   

gcj.texi also needs to be updated. The default behavior mentioned in the 
documentation needs to be changed, and the section describing the 
lib-foo-bar loader should mark it as deprecated and subject to removal 
in a subsequent release.

Bryce

Re: Patch: set default library control to LIB_NEVER

[Thomas Fitzsimmons]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

Bryce McKinlay wrote:
> Tom Tromey wrote:
>> Tom> This patch sets the default library control to LIB_NEVER.  This
>> Tom> saves many failed access() and open() calls for large
>> Tom> applications like Eclipse.  Applications that still need the old
>> Tom> library control can define the
>> Tom> gnu.gcj.runtime.VMClassLoader.library_control system property to
>> Tom> "cache".
>>
>> Tom> OK to commit?
>>
>> Yes, this is ok.
>>
>> It seems like this change should be documented somewhere.  Is there a
>> 4.2 changes page yet?  That would probably be the best place.
>>   
> 
> gcj.texi also needs to be updated. The default behavior mentioned in the 
> documentation needs to be changed, and the section describing the 
> lib-foo-bar loader should mark it as deprecated and subject to removal 
> in a subsequent release.

OK, I committed the attached documentation patch.

Tom

2006-05-31  Thomas Fitzsimmons  <fitzsim@redhat.com>

	* gcj.texi (Extensions): Document the new gcj-dbtool-based
	classname-to-library resolution mechanism.
	Declare the old gnu.gcj.runtime.VMClassLoader.library_control
	mechanism deprecated.
	(libgcj Runtime Properties): Document
	gnu.gcj.runtime.VMClassLoader.library_control's new default.


[-- Attachment #2: gcj-deprecate-lib-control.patch --]
[-- Type: text/x-patch, Size: 2940 bytes --]

Index: java/gcj.texi
===================================================================
--- java/gcj.texi	(revision 114281)
+++ java/gcj.texi	(working copy)
@@ -670,16 +670,26 @@
 @xref{About CNI}, for more info on how to use this in your programs.
 
 @item
-When you compile your classes into a shared library they can be automatically
-loaded by the @code{libgcj} system classloader.  When trying to load a class
-@code{gnu.pkg.SomeClass} the system classloader will first try to load the
-shared library @file{lib-gnu-pkg-SomeClass.so}, if that fails to load the
-class then it will try to load @file{lib-gnu-pkg.so} and finally when the
-class is still not loaded it will try to load @file{lib-gnu.so}.  Note that
+When you compile your classes into a shared library using
+@code{-findirect-dispatch} then add them to the system-wide
+classmap.db file using @code{gcj-dbtool}, they will be automatically
+loaded by the @code{libgcj} system classloader.  This is the new,
+preferred classname-to-library resolution mechanism.  @xref{Invoking
+gcj-dbtool}, for more information on using the classmap database.
+
+@item
+The old classname-to-library lookup mechanism is still supported
+through the @code{gnu.gcj.runtime.VMClassLoader.library_control}
+property, but it is deprecated and will likely be removed in some
+future release.  When trying to load a class @code{gnu.pkg.SomeClass}
+the system classloader will first try to load the shared library
+@file{lib-gnu-pkg-SomeClass.so}, if that fails to load the class then
+it will try to load @file{lib-gnu-pkg.so} and finally when the class
+is still not loaded it will try to load @file{lib-gnu.so}.  Note that
 all @samp{.}s will be transformed into @samp{-}s and that searching
-for inner classes starts with their outermost outer class.  If the class
-cannot be found this way the system classloader tries to use
-the @code{libgcj} bytecode interpreter to load the class from the standard
+for inner classes starts with their outermost outer class.  If the
+class cannot be found this way the system classloader tries to use the
+@code{libgcj} bytecode interpreter to load the class from the standard
 classpath.  This process can be controlled to some degree via the
 @code{gnu.gcj.runtime.VMClassLoader.library_control} property;
 @xref{libgcj Runtime Properties}.
@@ -2787,8 +2797,8 @@
 This controls how shared libraries are automatically loaded by the
 built-in class loader.  If this property is set to @samp{full}, a full
 search is done for each requested class.  If this property is set to
-@samp{cache} (the default), then any failed lookups are cached and not
-tried again.  If this property is set to @samp{never}, then lookups
+@samp{cache}, then any failed lookups are cached and not tried again.
+If this property is set to @samp{never} (the default), then lookups
 are never done.  For more information, @xref{Extensions}.
 
 @item gnu.gcj.runtime.endorsed.dirs