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

Julien Fischer jfischer at opturion.com
Tue Aug 8 22:18:04 AEST 2017

Hi Zoltan,

On Tue, 8 Aug 2017, Zoltan Somogyi wrote:

> 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

> 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?

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

> 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.


More information about the developers mailing list