[MDSAL-444] Switch runtime codegen from Javassist to ByteBuddy Created: 24/Apr/19  Updated: 30/Apr/19  Resolved: 30/Apr/19

Status: Resolved
Project: mdsal
Component/s: Binding runtime
Affects Version/s: None
Fix Version/s: 4.0.1

Type: Improvement Priority: Medium
Reporter: Robert Varga Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by MDSAL-401 Teach AbstractStreamWriterGenerator t... Resolved
is blocked by MDSAL-443 Inline CodecDataObject's NodeContextS... Confirmed

 Description   

With the recent rework of runtime-generated code (MDSAL-442, 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).



 Comments   
Comment by Robert Varga [ 25/Apr/19 ]

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.

Comment by Robert Varga [ 25/Apr/19 ]

Also ByteBuddy will require some bytecode loading too, it seems – but that probably can be better integrated with CodecClassLoader than ClassPool.

Generated at Wed Feb 07 20:09:49 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.