harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li (JIRA)" <j...@apache.org>
Subject [jira] Closed: (HARMONY-4165) [drlvm][gc_gen][tc] Race condition at "gc_thread.h":(136-149) at allocator_init_free_block() and alloc_context_reset() functions
Date Mon, 18 Jun 2007 05:36:26 GMT

     [ https://issues.apache.org/jira/browse/HARMONY-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Xiao-Feng Li closed HARMONY-4165.
---------------------------------

    Resolution: Won't Fix

There are just too many false alarms in GC module reported by Thread Checker. GC is design
to be parallel (and concurrent) with many parallel constructs that TC can't recognize. So
I will close these issues, and suggest to exclude GC module from TC sanity check temporarily.
 Actually I am afraid that, finally the major part of GC would be marked UNSAFE, which is
virtually the same as excluding it. Thanks.

> [drlvm][gc_gen][tc] Race condition at "gc_thread.h":(136-149) at allocator_init_free_block()
and alloc_context_reset() functions
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-4165
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4165
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>            Reporter: Ilya Leviev
>            Assignee: Xiao-Feng Li
>         Attachments: SourceViewScreenshot-1.jpg
>
>
> Race condition at "gc_thread.h":(136-149) at allocator_init_free_block() and alloc_context_reset()
functions
> TC report on thread unsafe access that result in race condition that occur during concurrent
execution of allocator_init_free_block() and alloc_context_reset() functions
> if it not affect correctness of execution I will mark it by special API for prevention
of further alarms on this race. 
> Write -> Write data-race	
> Memory write at "gc_thread.h":149 conflicts with a prior memory write at "gc_thread.h":136
> Stack Trace: 
> Context
> 	Function void interpreter(struct StackFrame &) "interpreter.cpp":2931
> 	Function Opcode_INVOKESTATIC "interpreter.cpp":2104
> 	Function interpreterInvokeStatic "interpreter.cpp":3312
> 	Function void interpreterInvokeStaticNative(struct StackFrame &,struct StackFrame
&,struct Method *) "interp_native_ia32.cpp":358
> 	Function invokeJNI "interp_native_ia32.cpp":49
> 	Function Java_java_lang_VMMemoryManager_runGC "java_lang_vmmemorymanager.cpp":138
> 	Function gc_force_gc "gc_for_vm.cpp":138
> 	Function void gc_reclaim_heap(struct GC *,unsigned int) "gc_common.cpp":300
> 	Function void gc_reset_mutator_context(struct GC *) "mutator.cpp":102
> 	Function void alloc_context_reset(struct Allocator *) "gc_thread.h":142
> Definition
> 	Function hythread_create_with_group "thread_native_basic.c":136
> 	Function os_thread_create "os_thread.c":37
> 	Function _beginthreadex "threadex.c":145
> 	Function EntryPoint "dllcrt0.c":323
> 	Function threadstartex "threadex.c":241
> 	Function thread_start_proc "thread_native_basic.c":711
> 	Function wrapper_proc "thread_java_basic.c":82
> 	Function vm_attach "thread_generic.cpp":266
> 	Function gc_thread_init "gc_for_vm.cpp":152
> 	Function void mutator_initialize(struct GC *,void *) "mutator.cpp":30
> 1st Access
> 	Function void interpreter(struct StackFrame &) "interpreter.cpp":2844
> 	Function Opcode_NEW "interpreter.cpp":1254
> 	Function struct ManagedObject * class_alloc_new_object(struct Class *) "jit_runtime_support.cpp":2589
> 	Function struct ManagedObject * Class::allocate_instance(void) "class.cpp":478
> 	Function void * vm_alloc_and_report_ti(unsigned int,unsigned int,void *,struct Class
*) "jvmti_event.cpp":1359
> 	Function gc_alloc "mutator_alloc.cpp":79
> 	Function void * nos_alloc(unsigned int,struct Allocator *) "gen.cpp":274
> 	Function void * fspace_alloc(unsigned int,struct Allocator *) "fspace_alloc.cpp":61
> 	Function fspace_alloc_block "fspace_alloc.cpp":40
> 	Function void allocator_init_free_block(struct Allocator *,struct Block_Header *) "gc_thread.h":136
> 	"133"	""	" #endif /* #ifndef ALLOC_ZEROING */"
> 	"134"	""	" "
> 	"135"	""	"     allocator->end = alloc_block->ceiling;"
> 	"136"	"*"	"     allocator->alloc_block = (Block*)alloc_block; "
> 	"137"	""	"     "
> 	"138"	""	"     return;"
> 2nd Access
> 	Function void interpreter(struct StackFrame &) "interpreter.cpp":2931
> 	Function Opcode_INVOKESTATIC "interpreter.cpp":2104
> 	Function interpreterInvokeStatic "interpreter.cpp":3312
> 	Function void interpreterInvokeStaticNative(struct StackFrame &,struct StackFrame
&,struct Method *) "interp_native_ia32.cpp":358
> 	Function invokeJNI "interp_native_ia32.cpp":49
> 	Function Java_java_lang_VMMemoryManager_runGC "java_lang_vmmemorymanager.cpp":138
> 	Function gc_force_gc "gc_for_vm.cpp":138
> 	Function void gc_reclaim_heap(struct GC *,unsigned int) "gc_common.cpp":300
> 	Function void gc_reset_mutator_context(struct GC *) "mutator.cpp":102
> 	Function void alloc_context_reset(struct Allocator *) "gc_thread.h":149
> 	"147"	""	"     block->free = allocator->free;"
> 	"148"	""	"     block->status = BLOCK_USED;"
> 	"149"	"*"	"     allocator->alloc_block = NULL;"
> 	"150"	""	"   }"
> See also Source View screenshots. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message