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" <[email protected]> > À: "dev" <[email protected]> > 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
