VM overriding default Options

[wks]

The VM may want to provide a different set of default values for MMTk options than those defined in src/util/options.rs. For example,

• In mmtk-core, the default plan is NoGC, and the default heap_size is 512MiB 50% of the physical memory.
• The Ruby binding wants to set the default plan to MarkSweep, and the default heap_size to 80% the physical memory (since the GCTrigger feature is available) dynamically resizing between 1MiB to 80% of the physical memory.

But the Ruby binding still allows the user to set those options via command line options or environment variables. For example,

• If the user specified --mmtk-plan=Immix or set env var MMTK_PLAN=Immix, MMTk should use the Immix plan; and
• if the user specified --mmtk-max-heap=16MiB or set env var THIRD_PARTY_HEAP_LIMIT=16777216, the heap size should be 16MiB.

So we shall have the following 4 ways to set MMTK options, with increasing priorities:

mmtk-core defaults < Ruby defaults < environment variables < command line arguments

The current MMTk core does not allow us to put Ruby defaults between mmtk-core defaults and environment variables, because when the Options struct is created using Options::default(), it populates the instance with mmtk-core defaults, and immediately look for environment variables, leaving no time in between.

One way to solve this problem is provide two methods:

1. One method creates an Options struct, and populates it with the default values defined in src/util/options.rs, and
2. The other method, possibly an instance method on Options, applies MMTK_* env vars to the Options instance.

By doing this, Ruby can inject its own defaults between (1) and (2).

Example

Let's use Ruby as an example. Ruby wants to override the default plan and the default gc trigger to dynamic resizing. The mmtk-ruby binding should do the following:

1. The mmtk-ruby binding instantiates an mmtk::util::Options structure filled with default values.
2. The mmtk-ruby binding overrides the default values:
   • sets Options::plan to MarkSweep, and
   • sets Option::gc_trigger to Dynamic
3. The mmtk-ruby calls a function provided by mmtk-core (for example, Options::parse_from_env_var) to parse environment variables and update the fields of Options
   • For example, if the env var MMTK_PLAN=Immix is set, it changes Options::plan to Immix; if not, it remains to be MarkSweep.
4. The mmtk-ruby parses its own command line arguments and sets options
   • For example, if the user added --mmtk-plan=Immix to the command line, it sets the plan to Immix; otherwise the plan remains what's set by the env var (if exists) or the default value.
5. The mmtk-ruby instantiates MMTK using the Options instance.

[qinsoon]

I think the problem is setting options by env vars. If we do not allow that, or a user never uses it, there would be no problem. A binding could create Options, immediately set the binding's default values to it, and then parse command line options.

Using environment variables to set options was a temporary hack to allow two things: 1. to work around the initialization issue (which was resolved by #625), and 2. to allow a binding to set options for MMTk without the need to implement anything for it (which could be useful when a binding is in early development). At this moment, we do not have any necessary reason to keep this. We could just abandon the support for setting options through env vars (or make it a optional feature).

[wks]

While we may remove the support of setting options via environment variables, it is still a useful feature in the early development stages of a VM binding, because it may be complicated to customise the VM's command-line parsing mechanism.

We may make it an optional feature. Alternative, mmtk-core can provide a function to load options via environment variables (the lower half of Options::default()), but mmtk-core doesn't call it by default. If a VM needs it, it can call it at the appropriate time (such as after the MMTKBuilder is called, but before the MMTK instance is built). This function may still need to be generated by mmtk-core because it is currently generated using the macro.