[m-dev.] question about --num-reserved-objects

[Zoltan Somogyi]

I am working on a change that would remove module- and type-
qualification from local variables in the MLDS. This diff simplifies
a lot of code in the MLDS backend, and leads to a speedup that
I measured at around 2% (though I think in practice it is likely
to be somewhat smaller), but in its current form it does break
--num-reserved-objects.

The default value of --num-reserved-objects is 0, and its documentation
explicitly states that this option is not for general use. My current diff
generates bit-identical output in Java and C# grades compared to the
current compiler, with both using the default 0 reserved objects.
I am pretty that wouldn't be the case if both used a nonzero number
of reserved objects. My question is: does that matter? Should we keep
supporting using reserved object tags? Does anyone use them now,
or see using themselves using them in the future?

Using reserved objects (or reserved numeric addresses) as tags requires
all tests of the *other* tags in the type to test for the reserved tags *first*,
so I don't think that using them is a performance win, though I don't believe
we have measured this in a long time. And it is an implementation detail;
no program should *depend* on using reserved objects.

I can complete the diff either by effectively withdrawing support for
--num-reserved-objects, or by changing the diff to generate bit-identical
Java and C# code with nonzero reserved objects. The first can be done
by either simply commenting out num-reserved-objects (and maybe
num-reserved-addresses) and its /their documentation, or by adding code
to handle_options.m to report an explicit error message if they have been
set to any nonzero value. (Both would need an entry in NEWS as well).
The second would require adding a new kind of mlds_rval, which is more work.

What do people think?

Zoltan.

[Julien Fischer]

Hi Zoltan,

Post by Zoltan Somogyi
I am working on a change that would remove module- and type-
qualification from local variables in the MLDS. This diff simplifies
a lot of code in the MLDS backend, and leads to a speedup that
I measured at around 2% (though I think in practice it is likely
to be somewhat smaller), but in its current form it does break
--num-reserved-objects.
The default value of --num-reserved-objects is 0, and its documentation
explicitly states that this option is not for general use. My current diff
generates bit-identical output in Java and C# grades compared to the
current compiler, with both using the default 0 reserved objects.
I am pretty that wouldn't be the case if both used a nonzero number
of reserved objects.

No, we generate the reserved objects in that case. To the best my
knowledge no-one has actually tried either the C# or Java grades. with
them.

Post by Zoltan Somogyi
My question is: does that matter?

No.

Post by Zoltan Somogyi
Should we keep supporting using reserved object tags?

No.

Post by Zoltan Somogyi
Does anyone use them now, or see using themselves using them in the
future?

I'd forgotten they even existed until I read this mail! (I don't
anticipate using them having been remind of their existence.)

Post by Zoltan Somogyi
Using reserved objects (or reserved numeric addresses) as tags requires
all tests of the *other* tags in the type to test for the reserved tags *first*,
so I don't think that using them is a performance win, though I don't believe
we have measured this in a long time. And it is an implementation detail;
no program should *depend* on using reserved objects.
I can complete the diff either by effectively withdrawing support for
--num-reserved-objects, or by changing the diff to generate bit-identical
Java and C# code with nonzero reserved objects. The first can be done
by either simply commenting out num-reserved-objects (and maybe
num-reserved-addresses) and its /their documentation, or by adding code
to handle_options.m to report an explicit error message if they have been
set to any nonzero value. (Both would need an entry in NEWS as well).
The second would require adding a new kind of mlds_rval, which is more work.
What do people think?

I can see no convincing reason for keeping them.

Julien.