Am 01.12.2019 um 19:33 schrieb [email protected]:
TVMTBuilder.generate_vmt has
_class.resetvmtentries;
and TVMTBuilder.generate_vmt_def has
{ the VMT definition may already exist in case of generics }
if assigned(try_search_current_module_type(vmtdefname)) then
exit;
Thus, it appears that VMT regeneration used to be supported/required.
1) In actuality, such regeneration does not currently happen:
generate_vmt_def is private and is only invoked from generate_vmt, and
generate_vmt is only invoked from:
types_dec :objectdef
generate_specialization_phase2 :objectdef
jvm_maybe_create_enum_class
jvm_create_procvar_class_intern
I.e. for any given def VMT generation happens only once.
2) Since SVN r41884, in which the insertion of hidden parameters was
tightly coupled with VMT generation, the regeneration as-is cannot
happen anyway: the call to insert_struct_hidden_paras from
generate_vmt would yield
Error: Duplicate identifier "$self"
3) From the performance standpoint, VMT regeneration is bad.
Given the above, I propose the remnants of VMT regeneration (or
whatever this is) be removed.
Aside from leaner code, we will get a speed-up from not invoking
try_search_current_module_type(vmtdefname) for every VMT generation
(which would do addsymref, which looks suspicious to me in the context
of skipping the creation of vmtdef in case of VMT regeneration).
Applied in r43628.
Regards,
Sven
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
