harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [drlvm][ti] thread unsafe global list of compiled stubs
Date Mon, 11 Dec 2006 15:32:21 GMT
Thanks for explanation about stubs - I understand and agree. Yes,
let's not mix these dynamic code lists.

I still have a question about asynchronous list modification. I've
just checked the code - stubs are added to the list even if a tool
interface is disabled:

    dc->next = *pdcList;
    *pdcList = dc;

On a modern processor we cannot guarantee an order of these two
operations unless you are using memory barriers. Imagine that the
second assignment is propagated to memory first.

Since you are using malloc (not calloc) for an element allocation,
there could be a chance that dc->next is containing some value which
isn't NULL and still point to some protected memory page. If another
thread starts iterating over the list at this moment, we'll get a

Does it make sense?

On 12/9/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> Alexei Fedotov wrote:
> > 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.
> Writing to the list won't do any harm as long as the list is not used.
> Only the head of the list is used for writing, and if some ->next fields
> have wrong pointers it won't matter as long as no one reads the list.
> > 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?
> Yes I object. There is no reason to mix JIT generated code chunks and VM
> generated stubs. These are two totally different code areas, and over
> synchronization is not needed just because the code pieces call each
> other. As I've written, in case JVMTI is disabled,
> compile_add_dynamic_generated_code_chunk should not do anything at all,
> it should just return.
> --
> Gregory

With best regards,
ESSD, Intel

View raw message