Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce dependencies of Dynlink #6725

Closed
vicuna opened this issue Dec 18, 2014 · 2 comments
Closed

Reduce dependencies of Dynlink #6725

vicuna opened this issue Dec 18, 2014 · 2 comments

Comments

@vicuna
Copy link

vicuna commented Dec 18, 2014

Original bug ID: 6725
Reporter: @alainfrisch
Status: closed (set by @alainfrisch on 2016-12-08T16:19:20Z)
Resolution: won't fix
Priority: normal
Severity: feature
Target version: later
Category: standard library
Tags: patch
Related to: #6790
Monitored by: @whitequark @gasche @jmeber @hcarty

Bug description

The (bytecode) Dynlink module drags a lot of compiler internal modules with it (they are packed into a Dynlinkaux module included in dynlink.cma). It seems that with some little refactoring, one could get rid of many of these dependencies. For instance, Lambda is required only because of its structured_constant type (---> one could move this definition to somewhere else, or "evaluate" structured constants into Obj.t values put in .cmo files). Fundamentally, there does not seem to be a deep reason for requiring e.g. subst.cmo, terminfo.cmo or ast_mapper.cmo in Dynlink...

Reducing dependencies will reduce binary code size and improve the structure of the source code; more importantly, it might facilitate the inclusion of dynlink in stdlib at some point (and thus its potential use in the compiler itself).

As a side remark, I'm wondering about the license on the dynlink library (the code under otherlibs is supposed to be under LGPL, but the library embeds modules from "the Compiler", which is under QPL).

File attachments

@vicuna
Copy link
Author

vicuna commented Dec 18, 2014

Comment author: @alainfrisch

I've uploaded a patch that evaluates structured constants before putting them in .cmo file (and thus simplify the life of the (dyn)linker). Possible disadvantages of doing so: (i) more difficult to print the constant in the dumpobj tool; (ii) float literals are evaluated at compile time, not link time, which might give slightly different results with dynlink, if the program is compiled and executed on different platforms; (iii) remove some opportunities for sharing constants at link time (we don't do it currently anyway).

@vicuna
Copy link
Author

vicuna commented Dec 8, 2016

Comment author: @alainfrisch

Bytecode Dynlink is now integrated in the compiler (by compiling a custom version of it), so this is less pressing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant