belliottsmith commented on code in PR #7:
URL: https://github.com/apache/cassandra-accord/pull/7#discussion_r1012668795
##########
accord-core/src/main/java/accord/local/Node.java:
##########
@@ -361,8 +318,7 @@ private <T> void send(Shard shard, Request send, Set<Id>
alreadyContacted)
public <T> void send(Collection<Id> to, Request send)
{
- for (Id dst: to)
- send(dst, send);
+ to.forEach(dst -> send(dst, send));
Review Comment:
I actually expect this to be better heap-allocated than an iterator, though
I have not experimented to find out. Since `to` is an interface, the compiler
does not know what type the iterator will be.
Escape analysis doesn't operate nicely on variables that are updated, so
iirc types like iterators don't generally behave nicely. I haven't updated my
understanding in a while, in fairness, but my heuristic is that - even if the
allocation of the `Iterator` is inlined, and the foreach loop hoisted inside
the scope of the monomorphic/bimorphic call-site optimisation (as, otherwise,
it could not assume the type of the `Iterator` is invariant), the likelihood is
that the `Iterator` would not be stack allocated.
However, a lambda function is very stack-allocation friendly, as there is no
internal state to update, so the lambda may easily be stack allocated via
scalar replacement. You may still require that the allocation of the lambda is
hoisted inside the scope of the monomorphic/bimorphic call-site optimisation,
so it's unclear in practice which will do so more preferentially (if either).
We should experiment to find out, and refresh our understanding of the JDK
codebase on escape analysis and scalar replacement.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
