harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm][ti] thread unsafe global list of compiled stubs
Date Mon, 11 Dec 2006 15:44:36 GMT
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


Mime
View raw message