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.
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? [1] http://wiki.apache.org/harmony/Code_Inspection%3a_compile%2ecpp On 12/8/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Alexei Fedotov wrote: > Gregory, Ilya, TI gurus, > > Could you please help me to understand why do we need a global list of > ia32 specific code chunks VM_Global_State::loader_env->dcList? Cannot > we use good old CodeChunkInfo structure? The information contained in dcList is different from CodeChunks. It contains generated stubs which are not compiled Java methods. It is necessary for GenerateEvents [1] function implementation with JVMTI_EVENT_DYNAMIC_CODE_GENERATED argument. An agent may request to receive all missed DynamicCodeGenerated events which it could have missed, and therefore it is necessary to store information about generated stubs in VM. > I have noticed that access to the list is not thread safe (you put > TODO comment here). Does it mean we have some intermittent crashes due > to this issue? Yes, this FIXME stands true. It is possible to get a race condition if you run a profiling JVMTI agent which uses GenrateEvents function while multithreaded application is executed. But in the normal mode when JVMTI is not used this list is only written, and never used. I think that compile_add_dynamic_generated_code_chunk should have a check that ti->isEnabled(), or it is just wasting the memory. [1] http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GenerateEvents -- Gregory
-- With best regards, Alexei, ESSD, Intel
