Affects Version/s: None
Fix Version/s: None
Sometimes it happens that"
- an anon-closure's apply() gets inlined (let's call that method A), but
- a sibling method invoked by A (ie also owned by A's owner) doesn't get inlined (that sibling method is usually an specialized apply).
In general, whenever the instance of the anon-closure-class is used somehow.
As a result, the anon-closure-class can't be eliminated, and we end up emitting code duplicates (for the method/s that did get inlined). When compiling the compiling under -optimize about 600 anon-closure-classes are prone to this. In these cases it would be best not to inline at all.
- private members of anon-closure-classes that aren't used in their owning classes could be removed by DeadCodeElimination.
- more aggressively, any synthetic private member that can't be accessed from a non-private member could be removed (no statistics gathered yet on the eventual bytecode reduction).
- doing that for non-synthetic private members would go too far.