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. 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
-- With best regards, Alexei, ESSD, Intel
