Bug 12755 - Binary Compatibility: Resolving static methods and classes is not thread safe
Summary: Binary Compatibility: Resolving static methods and classes is not thread safe
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: 4.0.0
Assignee: Tom Tromey
URL:
Keywords:
Depends on:
Blocks: 12725
  Show dependency treegraph
 
Reported: 2003-10-24 13:17 UTC by Andrew Haley
Modified: 2004-12-01 03:09 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2004-08-25 05:43:29


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Haley 2003-10-24 13:17:09 UTC
 
Comment 1 Andrew Haley 2003-10-24 13:23:50 UTC
Resolving static methods and classes is not thread safe.  We need somehow to add
interlocking.
Comment 2 GCC Commits 2004-01-09 17:08:52 UTC
Subject: Bug 12755

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	aph@gcc.gnu.org	2004-01-09 17:08:46

Modified files:
	gcc/java       : ChangeLog class.c constants.c decl.c except.c 
	                 expr.c java-tree.h jcf-parse.c lang.c parse.y 

Log message:
	2004-01-09  Andrew Haley  <aph@redhat.com>
	
	PR java/12755:
	* parse.y (java_fix_constructors):  Set output_class.
	(java_reorder_fields): Likewise.
	(java_layout_classes): Likewise.
	(java_expand_classes): Generate indirect dispatch tables.
	(java_expand_classes): Set output_class.
	(java_finish_classes): Likewise.
	* lang.c (java_init): Turn on always_initialize_class_p if we're
	using indirect dis[atch.
	(java_decl_ok_for_sibcall): Use output_class, not current_class.
	(java_get_callee_fndecl): Use class local atable.
	* jcf-parse.c
	(always_initialize_class_p): Decl moved to java-tree.h.
	(HANDLE_CLASS_INFO): Set output_class.
	(read_class): Likewise.
	(parse_class_file): Call gen_indirect_dispatch_tables.
	(parse_zip_file_entries): Set output_class.
	(java_parse_file): Set output_class.  Don't emit symbol tables.
	* java-tree.h (output_class): New.
	Remove global declarations for otable, atable, and ctable.
	(always_initialize_class_p): moved here from decl.c.
	(DECL_OWNER): New.
	(TYPE_ATABLE_METHODS, TYPE_ATABLE_SYMS_DECL, TYPE_ATABLE_DECL,
	TYPE_OTABLE_METHODS, TYPE_OTABLE_SYMS_DECL, TYPE_OTABLE_DECL,
	TYPE_CTABLE_DECL, TYPE_CATCH_CLASSES): New.
	(struct lang_type): Add otable_methods, otable_decl,
	otable_syms_decl, atable_methods, atable_decl, atable_syms_decl,
	ctable_decl, catch_classes, type_to_runtime_map.
	* expr.c (build_field_ref): Make otable, atable, and ctable class
	local rather than global.
	(build_known_method_ref): Likewise.
	(build_invokeinterface): Likewise.
	(java_expand_expr): Pass runtime type (rather than actual type) to
	expand_start_catch.
	* except.c (prepare_eh_table_type): Create TYPE_TO_RUNTIME_MAP for
	this class.  Look up each class in that map to delete duplicates.
	(expand_end_java_handler): Pass runtime type (rather than actual
	type) to expand_start_catch.
	* decl.c: (always_initialize_class_p): Decl moved to java-tree.h.
	(do_nothing): New.
	(java_init_decl_processing): Rearrange things.  Remove global
	declarations of otable, atable, and ctable.
	(java_init_decl_processing): Make lang_eh_runtime_type do_nothing.
	(java_expand_body): Set output_class.
	* constants.c (build_constant_data_ref): Use output_class, not
	current_class.
	(alloc_name_constant): Likewise.
	* class.c (gen_indirect_dispatch_tables): New.
	(build_class_ref): Generate hard reference to superclass, even if
	using indirect dispatch.
	(build_static_field_ref): Use class local atable.
	(make_class_data): Generate hard reference to superclass, even if
	using indirect dispatch.
	Generate symbolic references to interfaces when using indirect
	dispatch.
	(make_class_data): Emit otable, atable, and ctable.
	Make otable, atable, and ctable class local rather than global.
	(emit_catch_table): Make otable, atable, and ctable class local
	rather than global.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1309&r2=1.1310
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/class.c.diff?cvsroot=gcc&r1=1.174&r2=1.175
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/constants.c.diff?cvsroot=gcc&r1=1.32&r2=1.33
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/decl.c.diff?cvsroot=gcc&r1=1.174&r2=1.175
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/except.c.diff?cvsroot=gcc&r1=1.41&r2=1.42
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/expr.c.diff?cvsroot=gcc&r1=1.179&r2=1.180
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/java-tree.h.diff?cvsroot=gcc&r1=1.191&r2=1.192
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/jcf-parse.c.diff?cvsroot=gcc&r1=1.155&r2=1.156
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/lang.c.diff?cvsroot=gcc&r1=1.147&r2=1.148
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y.diff?cvsroot=gcc&r1=1.463&r2=1.464

Comment 3 Dara Hazeghi 2004-01-17 08:34:45 UTC
Andrew, is this fixed by your check-in on 1/09?
Comment 4 Andrew Haley 2004-01-17 11:31:15 UTC
It's not yet fixed; we need some minor libgcj changes.
Comment 5 Andrew Pinski 2004-03-16 16:25:30 UTC
Pushing this until 3.5.0.
Comment 6 Andrew Haley 2004-05-06 15:52:25 UTC
We need to study the Java Language Spec, look at the order in which things are
supposed to be done, and do that.

I think the initialization of the otable and otable needs to be done at the same
time as constant pool resolution.  We need to reorganize libgcj to do that.

Also, there is a kludge on the  gcj-abi-2-dev-branch where we handle the
condition  where we load an intepreted class but it hasn't been resolved. 
_Jv_Defer_Resolution() in java_interp.h does the work.  It would be excellent to
fix things so that this evil is no longer necessary.
Comment 7 Tom Tromey 2004-09-20 22:27:58 UTC
I believe this is fixed on the BC branch.
The original PR is a bit sparse... do we have a test case
or something?
Comment 8 Tom Tromey 2004-09-20 23:24:33 UTC
Mine.
Comment 9 Andrew Haley 2004-09-23 09:09:10 UTC
It's more or less impossible to test.  In short, we need to make sure
that resolution of indirect dispatch tables is correctly locked so
that it's impossible for double resolution to occur.  If resolution is
now within a class mutex, this bug may be closed.
Comment 10 Tom Tromey 2004-09-23 16:53:29 UTC
Yes, the tables are locked via a class mutex.
So, I'm closing the PR.
Comment 11 Andrew Pinski 2004-12-01 03:09:26 UTC
Fixed on the mainline by merge of the BC branch.