groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Forax <fo...@univ-mlv.fr>
Subject Re: Old bytecode targets
Date Wed, 05 Sep 2018 11:08:31 GMT
COMPUTE_FRAMES + getCommonSuperClass is one option, calling visitFrame by yourself is the other
option, for the later usually you have more context to find the super type but it means you
have to generate the visitFrame at the right place.

Rémi

----- Mail original -----
> De: "Jochen Theodorou" <blackdrag@gmx.org>
> À: "dev" <dev@groovy.apache.org>
> Envoyé: Mercredi 5 Septembre 2018 12:44:45
> Objet: Re: Old bytecode targets

> Am 05.09.2018 um 12:36 schrieb Remi Forax:
> [...]
>> 
>> it's not free if you ask ASM (COMPUTE_FRAMES) to do the fix point algorithm
>> (which is not linear) and to infer the common supertype, if you generate the
>> StackFrames in the groovy compiler by calling explicitly visitFrame, the
>> runtime cost is not big (but you need to modify your compiler backend which has
>> development a cost).
> 
> 
> we cannot let asm just do this 100% for us. The classes under
> compilation are possibly not available through classloading, and asm
> might not even use the right classloader if they would. what we do then
> is using COMPUTE_FRAMES, but override
> 
> protected String getCommonSuperClass(String arg1, String arg2)
> 
> which does a not 100% correct calculation of the common super class.
> (not 100% correct means here to claim it is Object in some cases, where
> there would be a better fit)
> 
> bye Jochen

Mime
View raw message