Re: ClassFileTransformer and ClassWriter

----- Mail original -----
> De: "offbynull-asm" <[email protected]>
> À: "Remi Forax" <[email protected]>
> Cc: [email protected]
> Envoyé: Dimanche 5 Mars 2017 20:23:46
> Objet: Re: [asm] ClassFileTransformer and ClassWriter

> Hi Remi,
> 
> I gave your first suggestion a try (ClassLoader.getResource) and it
> seems to work well. Can you elaborate a bit more on why you think the
> second suggestion (manually patching existing stackmaps) is a more
> fitting solution?

It depends if your transformation creates/inject types or not.
If you do not creates new types, or use new types but never mix them with existing types,
it's better to try to express your transformation in term of stackmap modifications too,
- it's faster, the algorithm that re-generate stackmaps in ASM is a fixed point algorithm so it may be slow,
- you do not have to compute a super type because all super types are already computed in the existing stack frame,
  you just have to insert/remove the types required by your transformation.

But it may be harder to express your transformation in term of stackmaps modifications than to recompute the stackframes. 

> 
> Thank you for the quick response + all your work on ASM.

:)

Rémi

> 
> On 3/5/2017 3:30 AM, Remi Forax wrote:
>> Hi !
>>
>> ----- Mail original -----
>>> De: "offbynull-asm" <[email protected]>
>>> À: [email protected]
>>> Envoyé: Samedi 4 Mars 2017 23:23:26
>>> Objet: [asm] ClassFileTransformer and ClassWriter
>>> I noticed that if ClassFileTransformer.transform() calls Class.forName()
>>> for a class that hasn't been passed to that transformer yet, that class
>>> will never get passed to that transformer.
>>>
>>> It looks like ClassWriter uses Class.forName() when it computes frames.
>>> How is it that people can use ClassWriter within a ClassFileTransformer
>>> without running in to this problem? Is there special logic somewhere in
>>> ASM that handles this?
>> If you want to write Java 1.6 compatible code, you have to generate stackmap
>> frames,
>> ASM can do that for you but it needs to know how to find the common supertype of
>> two types,
>> this is needed by example when you merge variables that comes from the two
>> branches of an if
>> (if you know the SSA form, you need that everywhere you have a phi).
>>
>> ASM provides a default implementation, ClassWriter.getCommonSuperType() that
>> relies on Class.forName,
>> which as you said is not something you should do if you are inside a
>> ClassFileTransformer
>> (which is not re-entrant).
>>
>> To cope with that issue, you can load the classfile using
>> classloader.getResources(), use ASM to find the supertypes and compute the
>> common super types.
>>
>> But i suppose that you already know all of this, (you are the author of
>> coroutines, right ?) so to answer to your question, no, ASM does not provide
>> any code for dealing with that, you have to write your own.
>>
>> The other solution, which i think in your case is the right solution, is to not
>> ask ASM to generate the stackmap for you, but read the existing stackmap and
>> patch them (in MethodVisitor.vuisitFrame),
>> it's painful, but in your case, it's the only way i see to do your
>> transformations properly.
>>
>> ASM can call visitFrame with two forms:
>>    - the compressed form which is how a frame is encoded in the bytecode (the
>>    stackframe may be defined as the delta from the last stackframe in the
>>    bytecode), this form is not suitable for patching
>>    - the expanded form, which get you the types of the local variables + stack
>>    which is easier to patch.
>> To get the expanded form, you have to pass EXPAND_FRAMES to the ClassReader.
>>
>> regards,
>> Rémi


-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws