[m-dev.] the compiler can't bootstrap in Java
Zoltan Somogyi
zoltan.somogyi at runbox.com
Sat Jul 13 00:32:57 AEST 2024
On Fri, 12 Jul 2024 17:56:01 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> > That's the one. I forgot what it's called, it's a
> > "static initialization block".
>
> Right, and I think the issue is that for most such blocks we generate
> we chunk the output
> in order to avoid the size limit, however
> mlds_to_java_global.output_rtti_assignments_for_java
> does *not* doing such chunking.
I think that the parts of mlds_to_{cs,java}_global.m that chunk
the definitions they output do so simply but badly. All they do
is output 1000 definitions of global variables in a chunk, *without*
looking at what initializers those definitions contain. Some definitions
do not contain any initializer, so their memory requirement is minimal.
Other definitions contain an array initializer, for which we output
one assignment statement for each array element. If the array is
long enough, I expect that a single such definition could exceed
the 64kb limit, at least in theory.
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.
The only metric that would be guaranteed to be exactly correct
would require invoking the selected java compiler and measuring
the size of its output; that is obviously bad overkill. In practice,
a metric that produces size estimates that correlate reasonably-well
with the true bytecode size would work, when coupled with a generous
factor of safety.
I don't use the JVM myself, so I am asking you: would using
the total number of lval and rval nodes in a global variable's initializer,
as well as in the scalar or array element lvals they are assigned to,
work sufficiently well as a metric? We would add new definitions
to a chunk as long at the total of this metric is below a limit;
when it would exceed that limit, we start a new chunk.
I also note that noone has responded to the part of my initial email
about testing the Java grade in rotation with the C# grade. I hope
I am not being a PHB when I say that it seems to be both worthwhile,
and reasonably simple to arrange.
Zoltan.
More information about the developers
mailing list