[m-dev.] the compiler can't bootstrap in Java

[Julien Fischer]

On Fri, 12 Jul 2024 at 17:25, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
>
> On Fri, 12 Jul 2024 17:17:14 +1000, Julien Fischer <jfischer at opturion.com> wrote:
>
> > On Fri, 12 Jul 2024 at 16:43, Peter Wang <novalazy at gmail.com> wrote:
> > >
> > > On Fri, 12 Jul 2024 15:36:48 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > > > I am just testing a diff that changes the representation of builtin ops.
> > > > Since such a diff affects all the backends, I want to test it on all the backends
> > > > before sending it for review. But my attempt to do so in the java grade
> > > > failed for a reason unrelated to my diff: the code of some predicate
> > > > in options.m has become too large for the JVM to handle.
> > > >
> > > > The recent changes to options.m, probably my additions of the options
> > > > controlling color, or Peter's addition of warn_redundant_coerce, probably
> > > > were the straw that broke the camel's back. Unfortunately, I have no idea
> > > > how to get the Java ecosystem to tell where *exactly* the actual problem is.
> > > > There is an error message with a context, but it seems wrong to me.
> > > > The message you get when you try to link the stage 2 compiler is:
> > > >
> > > > Making Java class files
> > > > Mercury/javas/jmercury/libs__options.java:15: error: code too large
> > > >   private static final jmercury.runtime.TypeInfo_Struct pair__pti_pair_2__plain_libs__options__type_ctor_info_option_0__plain_builtin__type_ctor_info_string_0 = new jmercury.runtime.TypeInfo_Struct();
> > > >
> > > > Line 15 is the first non-comment line in that file (which is attached),
> > > > but it does not seem like it can itself be considered too big in any respect.
> > > > Do any of you have any ideas for how to find out exactly *what* is too big,
> > > > so we can try to slim it down?
> > > >
> > >
> > > I manually edited Mercury/javas/jmercury/libs__options.java.
> > > It looks like if we break up the first "static" block (currently 8486
> > > lines long), that is enough to get through libs__options.java.
>
> Sorry, I don't understand. I see lots of things in that file for which
> "static" block would be a fair description; which did you have in mind,
> and how did you break it up?

Presumably, Peter means the one that starts on around line 789,

 static {
    //
    //
    //
    //
    pair__pti_pair_2__plain_libs__options__type_ctor_info_option_0__plain_builtin__type_ctor_info_string_0.init(
      pair.pair__type_ctor_info_pair_2,
      new /* XXX init_array */ Object[] {
        (jmercury.runtime.PseudoTypeInfo)
libs__options.libs__options__type_ctor_info_option_0,
        (jmercury.runtime.PseudoTypeInfo)
builtin.builtin__type_ctor_info_string_0
      }
    ); ...

and concludes around 8000 lines later.  (This is the static
initializer we generate to initialize all
of the RTTI data structures.)

> > Static initializers in Java are subject to the same 64kb byte code size
> > limit that methods are.
>
> That still does not tell me *which initializer* exceeded that limit.
> The one on line 15 couldn't have; typeinfo structures are all *small*.

Extracting that information from the Java compiler seems to be more difficult
than it should be :-(

Julien.