timothyjward commented on PR #215: URL: https://github.com/apache/aries/pull/215#issuecomment-1495528002
> I appreciate that my case is not typical. But if it can be supported with little to no penalty, that would be great. @wilx I don't think that there is any need to drop support for older bytecode versions, and there's nothing in this PR that would do so. > Only performance. I can add a comment to that effect but Java 8+ compiled classes are guaranteed not have JSR/RET instructions. @stiemannkj1 - that's what I thought. Can we remove those parts of this PR please? It's not good practice to mix bug fixes with feature enhancements, and it will confuse any regression analysis later if there are problems. I believe that this is also the wrong point in the code to optimise performance. > I believe weaving takes place for every class loaded after SPI-Fly is activated, so it could be quite costly to apply these unnecessary checks when the vast majority of classes are Java 8+ these days. SPI-Fly already ignores bundles that haven't opted in to weaving, which is most of them, so this isn't as big a deal as you might think. If we were looking to improve performance further then we would: 1. Need to do some measurements. If we don't do this then we have no idea if it's worth it. 2. Look at higher-level options for skipping work, e.g. a two-stage check/weave model. The current implementation writes a woven class file every time, but throws it away if there were no calls to decorate. Given that most class files don't need decoration (even in an opted-in bundle) it would be much faster to run a "check" which ignores everything but the method bodies to determine whether decoration is needed. Only if decoration is needed do we then run the full weaving code and generate the updated class bytes. The checker could also identify: * Whether any methods contain JSR instructions so that decorator is only added if needed. * Which methods need decoration so that we can avoid unnecessary re-checking in the weaving code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
