Questions concerning -XStaticPointers

[Boespflug, Mathieu]

Hi list,

in a private email, following both our talks at HIW'14, Patrick asked
me a few follow-up questions. I think the questions and their answers
are of interest to many members of this discussion group, so I'm
copying them below, lightly edited.

> (1) How exactly is 'Static' represented now? In particular, how big is the serialised representation. When nesting Closures, as HdpH does, it is somewhat important to keep the administrative overhead of Closures small - the Static implmentation used by HdpH serializes only a Word32. (You might not get quite so compact, but a 64bit word would hopefully suffice.) Related to this: How expensive is 'unstatic'?

Static is quite large: it currently combines package name, module
name, function name and some other info, all of which gets serialized
down the wire, and all of which is required information for 'unstatic'
on the remote end, because 'unstatic' relies on the system linker to
do the lookup (thus we need to give it a symbol name).

One option here could be to somehow add custom (short) symbols into
the symbol table for each static'ed expression, and have 'unstatic'
use that. Though I'm not sure how crucial this is for performance. How
often do you send a Static across the wire, compared to sending other
messages?

> (2) CloudHaskell baked a TypeRep into Static so that unstatic could check against that TypeRep, and throw an exception on mismatch. HdpH has omitted the TypeRep for a long time because it does not need the dynamic type check. This lead to smaller Static values, and more importantly, it got rid of the monomorphism (originally, now rank1 polymorphism) restriction arising from the Typeable class.
I seem to remember you saying during the talk that you're unable to
check the TypeRep at runtime. Does that mean that you have also
omitted it? (Here's hoping.)

We are indeed also omitting the TypeRep. In Cloud Haskell, it's
largely redundant with the TypeRep in the header of the message
anyways. Simon PJ is concerned about this, because it means a
malicious adversary could remotely segfault a node by forging the
TypeRep. It's certainly an issue, though I how much of a problem this
is in an HPC environnment, where often all nodes are part of the
trusted base, and such checks are often omitted for performance
reasons. There are likely plenty of other ways to crash a remote node
anyways.

The current story is that we'll probably find a way to make the
TypeRep, so that it can be omitted for high performance workloads, but
included (probably by default) for all other workloads.

Best,

--
Mathieu Boespflug
Founder at http://tweag.io.

[Boespflug, Mathieu]

Sorry, should have re-read my email better before sending...

> The current story is that we'll probably find a way to make the
> TypeRep, so that it can be omitted for high performance workloads, but
> included (probably by default) for all other workloads.

I meant to say "we'll probably find a way to make the TypeRep optional, ...".

[Tim Watson]

Mathieu, would you like me to file a Jira issue against that? Also, are you guys tracking issues that affect you some other way? If my use of Jira is creating a stove pipe so I'm not aware of the "real" backlog then I'd rather have a discussion (on cloud-Haskell-developers?) and change my process to better support you guys.