Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of alexei.fedotov@gmail.com
 designates 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=b5xvV7YIwvrRG75Z91aV+dGVOUG/0jdMVvpJ4XLS06LigcdkrTdNYl48WS7VRlU7lO/8q9NjGE52wvzMkmUTMWILgOINXFgODZrj0lZZ7AJNDDbtI+cx/n3oMw1DGwSRAVpt3WWjiYco0owFM6wd5cT3KOv7IdrJanMUcsp0QIM=
Message-ID: <c30d70960612081549q5e0b6638n13b31a4b3784353@mail.gmail.com>
Date: Fri, 8 Dec 2006 15:49:56 -0800
From: "Alexei Fedotov" <alexei.fedotov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][ti] thread unsafe global list of compiled stubs
In-Reply-To: <elcli0$mvi$1@sea.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <c30d70960612071712i36094b18n140978db8bd0add0@mail.gmail.com>
	 <elcli0$mvi$1@sea.gmane.org>

Gregory,

Thank you for explaining. As far as I unerstand writing to the thread
unsafe list is enough to cause segmentation fault on smp. You need to
update two fields, and this cannot be done atomically.

According to the wiki page [1] I need to cleanup CodeChunkInfo
structures anyway. Access to the code chunks is synchronized via
method locks. I believe it would be a good idea to unify these chunk
storages. Won't you object?

[1] http://wiki.apache.org/harmony/Code_Inspection%3a_compile%2ecpp

On 12/8/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> Alexei Fedotov wrote:
> > Gregory, Ilya, TI gurus,
> >
> > Could you please help me to understand why do we need a global list of
> > ia32 specific code chunks VM_Global_State::loader_env->dcList? Cannot
> > we use good old CodeChunkInfo structure?
>
> The information contained in dcList is different from CodeChunks. It
> contains generated stubs which are not compiled Java methods. It is
> necessary for GenerateEvents [1] function implementation with
> JVMTI_EVENT_DYNAMIC_CODE_GENERATED argument. An agent may request to
> receive all missed DynamicCodeGenerated events which it could have
> missed, and therefore it is necessary to store information about
> generated stubs in VM.
>
> > I have noticed that access to the list is not thread safe (you put
> > TODO comment here). Does it mean we have some intermittent crashes due
> > to this issue?
>
> Yes, this FIXME stands true. It is possible to get a race condition if
> you run a profiling JVMTI agent which uses GenrateEvents function while
> multithreaded application is executed.
>
> But in the normal mode when JVMTI is not used this list is only written,
> and never used. I think that compile_add_dynamic_generated_code_chunk
> should have a check that ti->isEnabled(), or it is just wasting the memory.
>
> [1]
> http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GenerateEvents
>
> --
> Gregory
>
>


-- 
With best regards,
Alexei,
ESSD, Intel