Re: ASM 5.2 ?

in closure-templates we ran into a number of issues with this and instead
of computing our own frames we created a custom implementation of
getCommonSuperclass

https://github.com/google/closure-templates/blob/master/java/src/com/google/template/soy/jbcsrc/SoyClassWriter.java#L162

in our case it wasn't possible to supply a classpath since the types in
question didn't exist (well, yet).  this was for a compiler that was
generating classes from scratch instead of modifying them and our classes
could have circular dependencies.  This workaround was a pretty easy way to
solve the problem.  I think even if our generated types did have complex
subtyping relationships with each other we could have still implemented
this ourselves with some minor modifications to our symbol table
datastructures.

On Sun, Dec 18, 2016 at 3:48 PM, Evgeny Mandrikov <[email protected]>
wrote:

> Hi Rob,
>
> "ClassWriter.getCommonSuperClass" is needed for computation of stack map
> frames, i.e. when you specify ClassWriter.COMPUTE_FRAMES as flag for
> ClassWriter.
> If you don't request this computation explicitly, carefully track them and
> perform updates for them as we do in JaCoCo, then the only case to trigger
> call of this method - is to trigger resizing in ASM by a big method as
> described in https://github.com/jacoco/jacoco/pull/177
> After fix for ASM #317630 , resizing won't cause this - that's what we see
> in JaCoCo tests.
> So "getCommonSuperClass" is still here, but only for the case when you
> explicitly request computation of stack map frames with flag mentioned
> above. And I doubt that there is a way to get rid of it in such case or to
> implement it without having actual classes. You right - access to classes
> is problematic, especially in OSGi environment, and that's why in JaCoCo we
> track and modify stack map frames by ourselves.
> That's my understanding, but maybe ASM developers can confirm.
>
> Hope this helps.
>
> Evgeny
>
> On Mon, Dec 12, 2016 at 12:04 AM Rob Bygrave <[email protected]>
> wrote:
>
>> Hi,
>>
>> Apologies if this is slightly off topic.
>>
>> *> jacoco/issues/177 <https://github.com/jacoco/jacoco/issues/177>*
>>
>> With this issue I see the mention of ClassWriter.getCommonSuperClass(Unknown
>> Source) ... and the issue of ASM needing to load classes to re-calculate
>> the stack frames. As an ASM user (for Ebean ORM) I hit this issue a lot and
>> we try to ensure the agent has access to the appropriate classpath such
>> that it can load classes for ClassWriter.getCommonSuperClass().
>>
>> Sometimes depending on the context (more specifically enhancement running
>> as an IDE plugin for IDEA and Eclipse etc) it is hard to build and supply
>> this classpath for the agent/enhancement.
>>
>> Is there a plan to remove this classpath requirement (ie. change the
>> implementation of ClassWriter.getCommonSuperClass() such that it doesn't
>> need the actual Classes) ?
>>
>> If there was that would be very welcome indeed and yes I'd love to see a
>> 5.2 release with that change.
>>
>> Apologies if I have completely missed the topic here.
>>
>>
>> Cheers, Rob.
>>
>
>
>
> --
> 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
>
>


-- 
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