From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27406 invoked by alias); 2 Jan 2003 10:06:03 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 27376 invoked by uid 71); 2 Jan 2003 10:06:02 -0000 Resent-Date: 2 Jan 2003 10:06:02 -0000 Resent-Message-ID: <20030102100602.27375.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, java-prs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, mark@klomp.org Received: (qmail 25691 invoked by uid 61); 2 Jan 2003 09:58:49 -0000 Message-Id: <20030102095849.25690.qmail@sources.redhat.com> Date: Thu, 02 Jan 2003 10:06:00 -0000 From: mark@klomp.org Reply-To: mark@klomp.org To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) Subject: libgcj/9125: VMClassLoader should cache the result of Runtime.(internal)loadLibrary() X-SW-Source: 2003-01/txt/msg00114.txt.bz2 List-Id: >Number: 9125 >Category: libgcj >Synopsis: VMClassLoader should cache the result of Runtime.(internal)loadLibrary() >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Thu Jan 02 02:06:01 PST 2003 >Closed-Date: >Last-Modified: >Originator: mark@klomp.org >Release: unknown-1.0 >Organization: >Environment: >Description: When you have a lot of classes that need to be interpreted then loading of the classes is very slow because the VMClassLoader keeps tries to load new classes first by first trying to open the lib-sub-package-class.so files. But since there are no natively compiled classes it keeps falling back to the interpreter. We must cache the result of Runtime.(internal)loadLibrary() somewhere. See also: http://gcc.gnu.org/ml/java/2002-12/msg00285.html >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: