Set and Map multibindings may generate methods which are too large

[damianw]

When using Set or Map multibindings, Dagger may generate methods which are too large to be compiled. We are only experiencing this when using dagger.fastInit. This appears to be caused by the expressions generated in SetRequestRepresentation here and MapRequestRepresentation here.

For example, in our case a large Set multibinding generates ImmutableSet.<...>of(expressions) where expressions is extremely long and causes the Java compiler to produce a code too large error. For sets, a workaround is to shard the multibindings and then have ElementsIntoSet bindings for each shard into the primary set. Maps can use a similar strategy, but won't have compile-time key checking across the different shards.

[bcorso]

Thanks for reporting! Ah, yes we recently fixed a similar issue for the non-fastInit case (a35a822).

There's a TODO to fix this for the fastInit case but I haven't had time to prioritize it.

I'll try to find some time next week to look into this.

[damianw]

Thanks for reporting! Ah, yes we recently fixed a similar issue for the non-fastInit case (a35a822).

Also great to hear! I noticed that and was excited to see it, but surprised that it didn't make it into the release notes. We'll be happy to be able to remove our -Xss flags once it's handled for fastInit too.

Does that fix also partition the body of the method, or just change from using a single builder expression to multiple statements? It wasn't clear to me from the commit if that's something that ShardImplementation can automatically refactor or something. This issue in particular is not about having a single expression that's so long that the compiler needs a lot of stack space, but rather that the method body contains too many instructions to be encoded in a class file.

[bcorso]

This issue in particular is not about having a single expression that's so long that the compiler needs a lot of stack space, but rather that the method body contains too many instructions to be encoded in a class file.

The fix does two things

1. moves the creation of the Map/Set into a separate function
2. puts each call to the builder's put/add methods as a separate statement

It sounds like this is indeed a different issue and the same fix won't necessarily fix your issue. However, it definitely could help, e.g. if you have multiple multibindings being created in the same initialize method, moving each to their own separate method will reduce the body size. Given you don't have this issue with the default mode, I'm guessing the same fix would work for your current case, though both modes could fail in the future if you continue to add more multibindings.