RFR: 8240567: MethodTooLargeException thrown while creating a jlink image [v5]

[Oliver Kopp]

On Thu, 29 Jun 2023 17:37:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The size of the generated moduleDescriptors is a function of the number of modules, the number of packages in the modules, number of exports, ... I think your approach is okay for now, meaning pick some threshold that you are confident will result in a method size < 64k.

I am very confident with 50 as 1) we tried out with a real life application using a high variation of dependencies (covering Apache libraries, Google libraries, and Oracle's JavaFX) and 2) it is half of the value of the number of modules where it broke at our software.

> It might be clearer to readers to use one threshold rather than two.

Above, the 75 was chosen, to avoid that anything in the JDK distribution is split (number was 73 to be precise, but I did want to have a "round" number). 

To be consistent, I adapted the lower split to 75. I tried it out with our app, and the app still works.

> The other limit that we will need to think about is the constant pool. That may be future work.

I am leaning towards "future work" here. Nevertheless, could you outline how that limit might be reached? It IMHO cannot be the numbmer of helper functions. The current "limit" leads to 32,000 (constant pool limit; leaving the other 32k to other things) x 75 (number of module descriptors covered) = 2.4 million module descriptors. In that case we might hit the call stack limit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1247239060