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
