You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Somewhat related,
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.
The text was updated successfully, but these errors were encountered:
Sometimes it happens that"
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.Somewhat related,
DeadCodeElimination
.The text was updated successfully, but these errors were encountered: