tree f4c9110a6c4fc47ec0045b34cb0181c256cb2be1
parent 0dc631a98c7d6d449d417877d1826bdd92b037bb
author David Chisnall <github@theravensnest.org> 1718190891 +0100
committer David Chisnall <davidchisnall@users.noreply.github.com> 1718303604 +0100

Use @jrtc27's approach to enable large sealed objects.

Allocating large sealed objects is difficult because sealed objects have
a header that contains the virtual sealing type and both the full
(sealed) object including the header and the (unsealed) part with the
header excluded must be representable.

@jrtc27 pointed out that there's no real need for the header to be at
the start of the allocation.  This neat trick lets us lay out the
objects as:

```
|Padding|Header|Unsealed Object|
        ^
        Address of sealed capability is here.
```

As long as we first round up the size of the unsealed object to be
representable, we can always then create a larger allocation that
contains padding at the start to preserve representability of the sealed
object.

This removes the restriction that we can't have sealed objects larger
than 4072 bytes, which will eliminate some annoying redirection in a few
places.

Fixes #242