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

[Zoltan Somogyi]

On Sat, 13 Jul 2024 00:32:57 +1000 (AEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> What I think we need is a metric that 
> 
> - correlates as well as possible with the size of the JVM bytecode
>   generated for a definition, while
> 
> - being as simple as possible.

I implemented a simpler metric, which estimates the size cost
of a global var definition as a simple linear function of the number
of fields (for a structure initializer) or of the number of array elements
(for an array initializer). The news is not good. The attached file
is the new Java code for the same module that Java couldn't handle
in its original form. It breaks up the rtti definitions into minimal sized chunks,
and *even then*, we get the same error as before:

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();

With three exceptions, all the static initializer blocks for the rtti data are now tiny
and cannot possibly be a problem. The three large blocks each contain the definition
of one global var, whose initializer is a 745-element array. All the array element initializers
consist of a single value.

Can someone tell me what exactly is javac complaining about *this* time?
Peter, you said that breaking up the original 8400+ line static block worked for you;
how exactly did you do that breakup?

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libs__options.java.20.gz
Type: application/gzip
Size: 135120 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/developers/attachments/20240714/7e0ff936/attachment-0001.gz>