This is the mail archive of the
mailing list for the GCC project.
Re: Java: [BC] Implement type assertion table
- From: Bryce McKinlay <mckinlay at redhat dot com>
- To: tromey at redhat dot com
- Cc: java-patches at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Fri, 05 Nov 2004 09:22:49 -0500
- Subject: Re: Java: [BC] Implement type assertion table
- References: <418ABDEA.firstname.lastname@example.org> <email@example.com>
Tom Tromey wrote:
Bryce> Index: link.cc
[ ... ]
Bryce> +_Jv_Linker::verify_type_assertions (jclass klass)
Everything in _Jv_Linker should be independent of the execution engine
(there's one bogus exception). That's why all the interpreter-related
code is in interpret.cc. So it seems a little weird to put this code
Doing the work to lay out indirect-dispatch tables and such is also
"linking", but I agree that having the distinction between generic class
layout and that which is specific to the BC-ABI may make sense. However,
there is already native-code/BC-ABI-specific functions are already in
_Jv_Linker - link_symbol_table(), link_exception_table(), etc. We could
separate these out into some other class/file, specific to the BC-ABI?
OTOH if we plan to support this field in Class independent of theNo, I do think this is native code/BC-ABI specific.
engine, then we might as well just inline the code into
Bryce> + if (assertion_code == 0)
Bryce> + // End of the table.
Bryce> + return;
Should probably use JV_ASSERT_END_OF_TABLE instead of "0" here.