RE: Class load order

I don't know if there is a magic answer to this quandary unfortunately. 
Giving the lazy class load behavior in most (all?) VMs you can't really make 
any assumptions here, especially for types not directly connected in the 
inheritance chain.

My quick thought is that you can either produce your instrumentation to be 
dynamic (have both paths) or to eagerly load all referenced types. Although, 
starting more class loads in the path in the path of loadClass() is a lovely 
way to produce deadlocks, and if you're doing this in a ClassFileTransformer 
you'll likely be disappointed since they are not re-entrant.

You’d have to benchmark it of course but hotspot might be able to make the 
dynamic case plenty fast enough.

> -----Original Message-----
> From: Peter Veentjer [mailto:[email protected]]
> Sent: Tuesday, January 12, 2010 9:32 AM
> To: [email protected]
> Subject: [asm] Class load order
>
>
> Hi guys,
>
> I'm struggling with an issue that is caused by the order of loading
> classes.
>
> I add additional methods to classes and this works great. If enhanced
> class A is loaded before enhanced class B, B is allowed to call these
> extra methods of A. But if class B is loaded before class A is
> loaded,  i get à verify error that i'm calling a non existing method
> on A.
>
> If i manually force loading A before B everything is allright.
>
> I would like to learn an approach to deal with this problem so that
> the instrumentation process gets more predictable.
>
> More info about the transformation. I'm building an stm and i add
> transactions to classes. This is done by creating an extra method with
> an extra argument of type transaction. All the original Logic is moved
> to this method. The code in the original method is replaced by
> transaction management code that forwards the call inclusive the
> transaction to the added method.
>
> The optimization i want to add is that if transactional methods are
> called from the original code, that the method calls are replaced by
> the version that acceps à transaction. There is no need to go through
> the transaction management and access à threadlocal to get the
> transaction.

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