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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
