In the current Foreign Memory Access API, a MemoryAddress can be linked to a MemorySegment; if that's the case, the address is said to be "checked" and can be thought of as an offset into a given segment. Such checked addresses are always safe to dereference, since the attached segment dictates the spatial/temporal properties of the address derived from it.

This also means that, when an address is _not_ attached to a segment, it cannot be dereferenced. These addresses are known as "unchecked" addresses. This is the case, for instance, for an address obtained with the MemoryAddress::ofLong factory, of for an address obtain when interacting with a native method handle.

While this design is sound, the fact that the same class (MemoryAddress) can be used to represent both a dereferenceable address and a non-dereferenceable one can lead to confusion. To be safe, clients that wish to dereference a certain address have always to protect against the fact that the address might, in fact, have no associated segment, thus being "unchecked".

Looking closer, it seems like a more natural interpretation of the API is possible: let MemorySegment be the unit of memory dereference operation, and let MemoryAddress be a dumb wrapper around an unsafe Object/long dereference pair.

This way, users always have to have a segment in order to dereference memory, which seems to make a lot of sense (after all, a segment is what makes the dereference operation safe).

If a client receives a MemoryAddress and wishes to dereference it, under the new model, the client could either try to use an existing segment (and compute the offset of the address relative to the existing segment using the MemoryAddress::segmentOffset routine). Or, it could just make up a new restricted segment, with given size. Or, it could just use (again, unsafely) the "everything" segment.