Re: [MirageOS-devel] Size of MirageOS, too big now?

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

From a quick look at the symbol map, I suspect that moving the OS module
to module aliases and Dune virtual_modules will help eliminate some hard
dependencies.  The 500KB->960KB isn’t too far off the mark; there are links
to Ipaddr and Lwt that would account for the increase.

It would be helpful to know what you’re aiming for — as small as possible
without a performance hit? Bytecode (as we experimented with in the ASPLOS
paper) is very slow for production use, and so hasn’t been maintained in
ocaml-freestanding.  For native, how small is small enough for your purposes?

best,
Anil

> On 13 Feb 2019, at 00:01, Hiroshi Doyu <hiroshi.doyu@xxxxxxxxxxxx> wrote:
> 
> Hi,
> 
> I'm trying to reduce the size of MirageOS so that it could run on some
> resource constraint MCUs with appropriate backend implemented, where
> the smaller the better.
> 
> I read the following info:
> - http://anil.recoil.org/papers/2013-asplos-mirage.pdf (bytecode)
> - https://discuss.ocaml.org/t/reducing-mirageos-image-size-using-ocamlc
> lean/2481
> 
> And tried "-use-lto"(4.06.1+lto switch) with tweaking mirage code to
> enable lto as:
> https://gist.github.com/ehirdoy/461731eb55b6c567a8018c1cc66ab26f
> 
> For Mirage-skelton, "noop.hvt" after stripped, it's 960KB. It was 
> 
>   -rwxrwxr-x 1 ehirdoy ehirdoy 2498544 Feb 13 07:40 noop.hvt # w/o lto
>   -rwxrwxr-x 1 ehirdoy ehirdoy 2271256 Feb 13 07:40 noop.hvt # stripped
> 
>   -rwxrwxr-x 1 ehirdoy ehirdoy 1124080 Feb 13 07:44 noop.hvt # w/ lto
>   -rwxrwxr-x 1 ehirdoy ehirdoy 982056 Feb 13 07:44 noop.hvt  # stripped
> 
> This 982056B(960KB) look still too big even if it's a native "noop". I
> heard that it used to be 500KB previously. I attached the output of
> "nm" command to list all symbols in this binary. Is there something
> wrong here?
> 
> Here are some questions:
> (1) Why is "noop.hvt"(native w/ lto) 960KB after stripped?
> (2) How can I dynamically enable "-use-lto" in Mirage build?
>     Can OCAMLPARAM do? If so what to set in?
> (3) Can I still build MirageOS as bytecode now?
> (4) Is there any "ocamlclean" equivalent tool for native code?
> 
> Any hint would be really appreciated.
> <noop.hvt.map>_______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/mirageos-devel


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/mirageos-devel