[bitc-dev] Type Classes: Pragmatics Questions
Mark P Jones
mpj at cse.ogi.edu
Fri Jul 22 01:56:55 EDT 2005
| This makes me inclined to rule out specialization, because it
| also seems to rule out *dynamic* linking. In the BitC context,
| our objectives are not restricted to compiling a microkernel.
| There are certainly cases where we will engage in whole-program
| analysis, but I would prefer a design that does not obligate us
| to do so to obtain reasonable results.
I'm not sure that it rules out dynamic linking altogether, but
I think you would need to add some kind of "dynamic specialization"
to make the combination work. For example:
- The source for program P contains an overloaded function f
that gets used at two different types, t1 and t2.
- The executable for program P contains:
1) code for f that has been specialized to type t1
2) code for f that has been specialized to type t2
3) code that will generate new versions of f, on demand,
for other types. (Maybe 1 and 2 were created by
running this function twice when P was first loaded).
- An extension E that is going to be linked in dynamically to
the running program P requires instances of f at type t1 and
- When the extension E is loaded, the linker notices that we
already have a version of f at type t1 (item 1 above) that it
can reuse, but it must run the code generator (item 3 above)
to produce a new version of the code for f at type t3.
- Creating new specializations of f may also require the creation
of new specializations of other functions that are used in the
definition of f. A dynamic linker must take steps to make sure
that all the necessary specializations are created. Think of
this as JIT specialization (and you'd probably want JIT optimization
Conclusion: I don't think that dynamic linking and specialization are
fundamentally incompatible. (But yes, the combination comes at the
price of some more sophisticated machinery than we get with current,
off-the-shelf dynamic linking mechanisms.)
All the best,
More information about the bitc-dev