public inbox for java-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Fitzsimmons <fitzsim@redhat.com>
To: Bryce McKinlay <mckinlay@redhat.com>
Cc: tromey@redhat.com, java-patches@gcc.gnu.org
Subject: Re: Patch: set default library control to LIB_NEVER
Date: Wed, 31 May 2006 23:15:00 -0000	[thread overview]
Message-ID: <447E2367.7090205@redhat.com> (raw)
In-Reply-To: <447DDD4A.5060001@redhat.com>

[-- 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

  reply	other threads:[~2006-05-31 23:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-31 15:44 Thomas Fitzsimmons
2006-05-31 17:32 ` Tom Tromey
2006-05-31 18:15   ` Bryce McKinlay
2006-05-31 23:15     ` Thomas Fitzsimmons [this message]
2006-05-31 17:32 ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=447E2367.7090205@redhat.com \
    --to=fitzsim@redhat.com \
    --cc=java-patches@gcc.gnu.org \
    --cc=mckinlay@redhat.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).