Switch runtime codegen from Javassist to ByteBuddy
Description
With the recent rework of runtime-generated code (MDSAL-442, https://lf-opendaylight.atlassian.net/browse/MDSAL-443#icft=MDSAL-443, MDSAL-401), the shape of these classes ends up not containing any real logic as most of it is held in superclasses (CodecDataObject, CodecOpaqueObject and DataObjectStreamer). We are also in complete control of loading the resulting bytecode and class lookup by virtue of using CodecClassLoader.
Thus we are at a point where Javassist is providing us with no real value and its programming paradigm (i.e. the need to load class bytecode before being able to operate on it) is actually hurting us – see DataObjectStreamerBridge.
Switch to ByteBuddy, whose bytecode-oriented nature allows us to operate on java.lang.reflect-based constructs and emit pure bytecode without intermediate compilation. This should not only streamline our code by not having to deal with CtClasses, but also speed up startup (by virtue of no Exception-driven compilation in Javassist) and lower memory footprint (by virtue of not needing CtClass caches).
Also ByteBuddy will require some bytecode loading too, it seems – but that probably can be better integrated with CodecClassLoader than ClassPool.
Robert Varga April 25, 2019 at 12:54 PM
Edited
Initial prototype looks promising, one snag though is ByteBuddy's size (mostly due to its DSL and organization) – it will bump our jar size by about 2.5M, making it +1.8M even when ditch javassist completely. At any rate, the Streamers need to be finished up before we know for sure.
Medium
With the recent rework of runtime-generated code (MDSAL-442, https://lf-opendaylight.atlassian.net/browse/MDSAL-443#icft=MDSAL-443, MDSAL-401), the shape of these classes ends up not containing any real logic as most of it is held in superclasses (CodecDataObject, CodecOpaqueObject and DataObjectStreamer). We are also in complete control of loading the resulting bytecode and class lookup by virtue of using CodecClassLoader.
Thus we are at a point where Javassist is providing us with no real value and its programming paradigm (i.e. the need to load class bytecode before being able to operate on it) is actually hurting us – see DataObjectStreamerBridge.
Switch to ByteBuddy, whose bytecode-oriented nature allows us to operate on java.lang.reflect-based constructs and emit pure bytecode without intermediate compilation. This should not only streamline our code by not having to deal with CtClasses, but also speed up startup (by virtue of no Exception-driven compilation in Javassist) and lower memory footprint (by virtue of not needing CtClass caches).