RFR: 8369654: javac OutOfMemoryError for complex intersection type [v2]

[Maurizio Cimadamore]

On Wed, 29 Oct 2025 22:30:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor changes
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 4077:
> 
>> 4075:             List<Type> mec = null;
>> 4076:             if (lubWillBeErased && !cl.isEmpty()) {
>> 4077:                 cl = List.of(cl.head);
> 
> we don't need to deal with the whole list of types from here as it will be erased

This seems a bit unsound because we're just picking the first erased supertype. Maybe it's ok because all closures are sorted by subtyping (so all supertypes come _after_ subtypes).

Another possible approach would be not to bother with lub, and to have a simpler routine in Code that:
* obtains all the erased supers of both types
* "minimize" them, to find the smallest set of common erased supertypes
* pick randomly one element in the minimized set

(because lub is a bit of an overkill is then we're going to erase the result anyway). Perhaps it would be good to write both versions, and then decide on which one seems minimally invasive. Of course it's a tricky trade off -- on the one hand by doubling down on lub, we can reuse some of the machinery there, but we also pull in more than we should.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28050#discussion_r2478170340