Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of pmcfirst@gmail.com designates
 66.249.82.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=SQzeOygF6ZNmNqygo7Xvx3mLofmhxT5uYE+sj9W7MHDTGTt4585asOa7XwOR8BzRcRu6RkRIMY1P91zRHxbhMC0WZtk+551/pvjCqT/W6z/tlIsbd7hQOEWBR6dZ+8ezdp3YEpdb51iFAaMaXPZe8QZAvgNZcyhkjsNQUdXdaI0=
Message-ID: <e0f125db0710220502l7959933bw7d8fc7bce75ae23a@mail.gmail.com>
Date: Mon, 22 Oct 2007 16:02:21 +0400
From: "Pavel Pervov" <pmcfirst@gmail.com>
To: dev@harmony.apache.org
Subject: Re: The way to increase the SPECjAppServer2004 score by 20%
In-Reply-To: <bd8d07180710220439r6e4be49au81dbc8f9298fb2a5@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_21561_16036578.1193054541929"
References: <bd8d07180710220439r6e4be49au81dbc8f9298fb2a5@mail.gmail.com>

------=_Part_21561_16036578.1193054541929
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Looking at the Java Virtual Machine Specification there are two terms:
initiating loader and defining loader.

Initiating loader is the class loader which was first asked to load class in
delegation chain (CL2 in your example).

Defining loader is the class loader which has found bytes for class
definition and called to JNI->DefineClass.

Lets review the following delegation model.

CL1<-CL2<-CL3

CL4<-CL2<-CL5

There is nothing wrong with CL2: its delegation model simply assumes
switching delegation parent depending on some external property.

Different versions of class Foo are available from CL1 and CL4. Now, we do
something like CL3.loadClass("Foo") and CL5.loadClass("Foo").
If CL2 will cache the class Foo, then the call to CL5 will return wrong
result.

So the caching is possible, but it is only allowed to register class in
initiating loader and in defining loader. Otherwise, you may have wrong
classes returned to your application.

Determining defining loader is simple. Can you suggest some working idea on
how to determine initiating loader for a class?

WBR,
    Pavel.

On 10/22/07, Sergey Dmitriev <sergey.v.dmitriev@gmail.com> wrote:
>
> Hello
>
> This letter is actually about HARMONY-4965, I just changed a little
> bit a subject. :)
>
> During my play with SPECjAppServer2004 on OC4J I've found out that we
> have a way to optimize the class loader. Or in other words currently
>
> Lets say we have class loaders CL1 and CL2, and CL2.getParent() ==
> CL1. And lets say we have a class C which is loaded by the CL1 (the
> parent one). And then we try to load class via the class loader CL2:
> of course CL2 first of all tries to load it via its parent CL1 and
> succeed in it. When we try to load class C via CL2 again we will have
> the same chain of calls: CL2 -> CL1. But if CL2 have support of
> caching of classes loaded by not itself - the chain can become much
> shorter - it could end at CL2.findFinishedClass().
>
> For example RI behaves like this. See JIRA's demo.
>
> Back to the SPECjAppServer2004 @ OC4J. In this case we have a deeper
> chain: we have a concrete class which is been searched so deep that we
> looking for this class in boot strap class path. And this is what we
> have in steady state of the benchmark. Don't you think it is useless?
> :)
>
> Talking about numbers: my measurements show that we can take up to 20%
> of burst having this bug fixed. Could some competent guy take a look
> into this?
>
>
> Thanks
> Sergey
>


-- 
Pavel Pervov,
Intel Enterprise Solutions Software Division

------=_Part_21561_16036578.1193054541929--