Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <19612328.1182145107174.JavaMail.jira@brutus>
Date: Sun, 17 Jun 2007 22:38:27 -0700 (PDT)
From: "Xiao-Feng Li (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Closed: (HARMONY-4176) [drlvm][gc_gen][tc] Race condition at
 "gc_thread.h":(119-147) at allocator_init_free_block() and
 alloc_context_reset() functions
In-Reply-To: <20296832.1181835088425.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Xiao-Feng Li closed HARMONY-4176.
---------------------------------

    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":(119-147) at allocator_init_free_block() and alloc_context_reset() functions
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-4176
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4176
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>            Reporter: Ilya Leviev
>            Assignee: Xiao-Feng Li
>            Priority: Minor
>         Attachments: SourceViewscreenshot-1.jpg
>
>
> Race condition at "gc_thread.h":(119-147) 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. 
> Read -> Write data-race	
> Memory write at "gc_thread.h":147 conflicts with a prior memory read at "gc_thread.h":119
> 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 main "cmain.c":146
> 	Function gpProtectedMain "main.c":391
> 	Function invocation "main.c":668
> 	Function JNI_CreateJavaVM "jni.cpp":499
> 	Function int vm_init1(struct JavaVM_Internal *,struct JavaVMInitArgs *) "vm_init.cpp":693
> 	Function gc_init "gc_for_vm.cpp":56
> 	Function void gc_gen_initialize(struct GC_Gen *,unsigned int,unsigned int) "gen.cpp":210
> 	Function void gc_nos_initialize(struct GC_Gen *,void *,unsigned int,unsigned int) "gen.h":125
> 	Function void fspace_initialize(struct GC *,void *,unsigned int,unsigned int) "fspace.cpp":52
> 	Function void * vm_commit_mem(void *,unsigned int) "gc_platform.h":225
> 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":119
> 	"118"	""	"     /* set allocation context */"
> 	"119"	"*"	"     void* new_free = alloc_block->free;"
> 	"120"	""	"     allocator->free = new_free;"
> 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":147
> 	"146"	""	"     assert(block->status == BLOCK_IN_USE);"
> 	"147"	"*"	"     block->free = allocator->free;"
> 	"148"	""	"     block->status = BLOCK_USED;"
> 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.