[fpc-devel] Remnants of VMT regeneration

[Sven Barth]

Am 01.12.2019 um 19:33 schrieb Blaise at blaise.ru:
> 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