The runtime system itself will be able to choose how these structures are laid out, whether the data needs to be placed before the code, how much padding is required and so on. Depending on weather the program is compiled or interpreted, and how it is interpreted we may need to address the security and performance challenges of mixing code and writable data. Obviously if code is interpreted by a token-oriented interpreter (like the one we have now) then this and the CPU cache and pipeline issues are not a problem. However if we use any call-threaded execution, or compilation then these are a problem. We may be able to avoid some of this by allocating closures into different areas on the heap and allowing them to have different protection levels. For stronger security it’d be better to Exclude execute and write on the same pages at the same time. It will also make users lives easier since they’re less likely to need to break the security rules of their system. See also Code loading. Therefore being able to switch memory from writable to executable between the time a closure is created and when it’s executed may help. The challenge in this case is now knowing, at the granularity of a page, when to change permissions. There are a number of ways to do this, some static and some dynamic. We could have the compiler analyse when a good point to move closures from the closure nursery (where they are writable) into an older closure space. This could be combined with tag bits (adding a minor cost to all indirect function calls) or by trapping page faults when execution fails and moving the closures then.