570919 - Improved runtime option configuration mechanism.

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Virtual Machine, enhancement)

Description

[Krzysztof Palacz]

Currently VM runtime options are specified through various shell command parameters. While this approach works, it requires a certain amount of repetitive command line parsing whenever a new option is introduced, handling of complex options (multivalues, key-value pairs etc) has to be reinvented, and other mechanisms are needed when the VM is embedded (e.g., in the Flash Player).

A reusable, open-ended mechanism for handling structured VM configuration data would be handy. Example applications include ad hoc experimentation, debugging ("here's a list of methods whose compilation should be logged, excluded unconditionally, delayed until compilation count is x"), specification of instrumentation points, perhaps replacement for some of command line arguments.

Comment 1

[Lars T Hansen]

+1

Comment 2

[Krzysztof Palacz]

Attachment: Support for XML property list files via the built-in E4X parser.

The natural choice for config file syntax would be JSON, but it would require a parser available in all configurations. The one parser that is already available in all configurations is the E4X parser. This patch reuses the E4X parser to handle config files written in a subset of the XML property list format, http://en.wikipedia.org/wiki/Property_list. It's used extensively on the Mac, but the implementation does not rely on platform-specific libraries. 
The mechanism needs working GC, so it can't be used to configure it, but it does not depend on  traits and toplevels.

I don't like XML either, but the format does exactly I think we need, there are various tools for it on many platforms, and XCode handles it natively and displays in a property sheet format. 
I'm looking for feedback on the general idea, before I spend more time on it.

Comment 3

[Lars T Hansen]

Seems like a weakness that we can't control the GC - the VM/MMgc split is a bit of a fiction I'm trying to discourage, and the GC has a lot of config options too.

Comment 4

[Edwin Smith]

+1 to the bug, and here's another use case: bug 570803.  Generically: a module implementation (not interface) needs parameters unique to the implementation and preferrably encapsulated as much as possible.  In the case of execmgr, an option would choose which implementation to use, which in turn would determine which options are valid/available.

Perhaps the XML parser can be templatized to allow configurable allocation. (malloc works at boot, shell bloat isn't a problem).  It seems important that the option code be able to get up and running without much of the rest of the system existing yet, since modules will want to query their options at startup.

Comment 5

[Rick Reitmaier]

Comment on attachment 450069 [details] [diff] [review]
Support for XML property list files via the built-in E4X parser.

I like it! 

I'm curious to see more examples of the kind you mentioned in the description as this is where the real benefit lies.

Also, we'll need to address how this fits in with flash's configuration system, as that system is line oriented. 

Also, as Ed mentioned above encapsulating the interpretation of the parameters in the module that uses them, makes a lot of sense and I'm guessing that this is what you intend to do anyway and just for illustrative purposes at this point have centralized it all in the shell.

Comment 6

[Krzysztof Palacz]

> 
> Perhaps the XML parser can be templatized to allow configurable allocation.
> (malloc works at boot, shell bloat isn't a problem).  It seems important that
> the option code be able to get up and running without much of the rest of the
> system existing yet, since modules will want to query their options at startup.

I'm looking into templatizing the XML parser, the problem is that it also needs Strings and AvmCore to intern them. This may indeed be doable, but is quite complex (e.g., it involves allocating Strings in a different memory management regime).

Comment 7

[Krzysztof Palacz]

(In reply to comment #5)
> (From update of attachment 450069 [details] [diff] [review])
> I like it! 
> 
> I'm curious to see more examples of the kind you mentioned in the description
> as this is where the real benefit lies.
> 
> Also, we'll need to address how this fits in with flash's configuration system,
> as that system is line oriented. 
> 
> Also, as Ed mentioned above encapsulating the interpretation of the parameters
> in the module that uses them, makes a lot of sense and I'm guessing that this
> is what you intend to do anyway and just for illustrative purposes at this
> point have centralized it all in the shell.
The idea is that the config file is parsed into a hierarchical structure, and each module can look for its options under its chosen place in that structure. I started sketching a convention that (perhaps unimaginatively) uses namespace and class names to structure the config structure, so jitordie is under
avmplus.AvmCore.Config.jitordie 
The option-specific logic in the shell is indeed only for demonstration. 
Of course, there could be more then one config file and config structure, I wanted to make it convenient to just drop in a new config file while debugging and throw it away when not needed.

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Tamarin is a dead project now. Mass WONTFIX.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.