Avoid serializing ResolvedBCOs in InternalInterpreter mode
While working on !10841, I noticed that the GHCi.Message
includes the following comment:
-- | Create a set of BCO objects, and return HValueRefs to them
-- Note: Each ByteString contains a Binary-encoded [ResolvedBCO], not
-- a ResolvedBCO. The list is to allow us to serialise the ResolvedBCOs
-- in parallel. See @createBCOs@ in compiler/GHC/Runtime/Interpreter.hs.
CreateBCOs :: [LB.ByteString] -> Message [HValueRef]
Indeed, GHC.Runtime.Interpreter.createBCOs
includes a corresponding comment that says
-- Serializing ResolvedBCO is expensive, so we do it in parallel
and it uses some par
-based parallelism to serialize the BCOs in chunks of 100 at a time.
Unfortunately, this is not really the right way to implement this parallelism. Since the serialization is baked into the type of CreateBCOs
, it is always performed, even in InternalInterpreter
mode. Since the comment says it is “expensive”, this seems like it might be introducing a lot of pointless overhead for no reason!
A better approach would be to implement this parallelism in putMessage
and getMessage
, as that’s where serialization logic actually belongs. The CreateBCOs
constructor can be given the more useful type [ResolvedBCOs] -> Message [HValueRef]
, and the conversion to and from ByteString
chunks can be handled entirely in the encoding.