Separation between MemorySegment and MemoryScope

[John Rose]

On Mar 26, 2021, at 3:27 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> but at the same time i'm still mourning the fact that before this change, i really liked the fact that a MemorySegment was confined to a thread by default.

Core Java APIs must be safe-by-default.  To the extent
that Panama APIs are not safe-by-default, they will not
fit into the core of the Java ecosystem as well as (I think)
they should.  At the very least, it should be possible to take
Panama code and go through a review process that
removes dangling pointers and race conditions.
(Or at least the process should produce documentable
bounds on races and dangles.)  Something like that
is required if a Panama library is going to serve as
an invisible, reliable base library for some other
Java API.

From that POV the default settings matter.  If something
from Panama is fast and unsafe by default, you have
technical debt to pay off before you can use it as an
(invisible, reliable) base for a normal Java API.  And
there’s a moral hazard:  Maybe there’s time pressure,
and the process for removing the errors is deemed
too expensive to do before the first release of the
Java API built on top.  We all know where this goes;
we’ve lived it.

If the default is set to slow and safe, then there’s a
different technical debt to pay off and a different
moral hazard.  If you need to cut corners, you deliver
a version of the Java API (on top of your Panama code)
which is slower than it should be, and you promise to
pay off the technical debt by doing the difficult work
of marking up the Panama code with non-default
usages which are less safe, documenting as you go
why this is still OK.

Is there a third way?  I don’t think so.  And given
the choice of two kinds of technical debt, I’d take
slow-and-safe vs. shiny-fast-and-buggy any day,
for an initial release.  Either kind of tech debt
can be paid down after a first release (of a Java
API layered on top of Panama code) but the
shiny-fast-and-buggy option feels (to me) like
cheating, and if it feels to our customers like
cheating, we can lose mindshare.

Others may differ on this tradeoff, and maybe
I’ve slurred over a viable middle ground (such
as removing most dangles and most races).

I will point out, though, that as you build more
and more fundamental code (such as the VM or
or the JDK), you have less and less wiggle room
to deliver fast-and-buggy.  Conversely, as you
write stuff up the stack, that will be deployed
(say) in a datacenter where process failure is
expected and dealt with cleanly, fast-and-buggy
is a pretty good move.  If you argue for fast-and-buggy
defaults in Panama, you may be thinking of those
use cases.

All this leads me to suggest:  Whichever goal any
given Panama programmers is going for, the form
of the code *must explicitly indicate whether it is
aiming first for fast or first for safe*.  That is an
argument for requiring various kinds of fiddly
extra explicit parameters, even if a user here or
there will say, “stop making me say that stuff,
because you can always guess what I need there”.
The problem is that there are at least two sets
of mutually-contradictory ways to read and guess
about Panama code, the fast way and the safe way.
So, make it explicit.

— John