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 22:02:27 GMT
Gregory, Ilya,

I can see that currently dcList in the implementation of
st_print_stack() function. It looks like these stubs are used to
iterate via native frames in a loop. Does it mean we need to record
all stubs regardless if TI is enabled or not?


On 12/11/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> Alexei Fedotov wrote:
> > Gregory,
> > 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
> > crash.
>
> Another thread won't iterate over the list because AFAIK it is not used
> if JVMTI is not enabled. Actually I think the list should not be updated
> at all to save the memory.
>
> > 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
> >>
> >>
> >
> >
>
>
> --
> Gregory
>
>


-- 
With best regards,
Alexei,
ESSD, Intel

Mime
View raw message