Stream: t-compiler

Topic: REPL: RustcSerialize vs manual


oli (Nov 29 2019 at 16:28, on Zulip):

both the user_fn frame and the Memory need to be serialized and restored. Currently @Alexander Regueiro has implemented a manual scheme, and iirc wanted to check again why RustcSerialize and RustcDeserialize aren't used instead

Alexander Regueiro (Nov 29 2019 at 16:34, on Zulip):

So, I believe I experimented with this some time ago (you may have suggested this formerly), and basically the issue was that a) it pulled in memory from the start fn and main's params

Alexander Regueiro (Nov 29 2019 at 16:35, on Zulip):

b) the dead_alloc_map isn't something that we really want to serialise, I think

oli (Nov 29 2019 at 16:36, on Zulip):

you need the dead_alloc_map for a few operations. If it's not there you may run into trouble when doing things to dangling pointers

oli (Nov 29 2019 at 16:36, on Zulip):

and trust me, users will do evil things with a REPL :D

oli (Nov 29 2019 at 16:39, on Zulip):

about the wasted memory. Essentially the way you serialize is to serialize the frame of the closure, write down all alloc ids, serialize the corresponding Alloations for the alloc ids, again writing down all new alloc ids encountered?

Alexander Regueiro (Nov 29 2019 at 17:28, on Zulip):

hmm I see

Alexander Regueiro (Nov 29 2019 at 17:28, on Zulip):

I will look into this for sure

Alexander Regueiro (Nov 29 2019 at 17:28, on Zulip):

I don't think it affects the first couple of PRs

Alexander Regueiro (Nov 29 2019 at 17:29, on Zulip):

and a RustcSeriaze/Deserialize implementation for Memory should not be too hard. I'm sure I implemented it before and reverted it.

Alexander Regueiro (Nov 29 2019 at 17:29, on Zulip):

will do a bit more experimentation before opening the MIR PR, of course

oli (Nov 29 2019 at 18:20, on Zulip):

I think you're right in that a manual deserialization works better, because it can skip everything that is not needed

oli (Nov 29 2019 at 18:20, on Zulip):

But yea, you'll have to also preserve the dead alloc map entries that are reachable

Alexander Regueiro (Nov 29 2019 at 18:26, on Zulip):

okay, so I think we're in agreement there. I'll just make sure the dead alloc map gets serialised now! (I guess my simple test cases didn't catch problems with that, but indeed, someone would find a way to break it heh...)

bjorn3 (Nov 29 2019 at 18:53, on Zulip):

Should the stacked borrow state be serialized too?

Alexander Regueiro (Nov 29 2019 at 20:14, on Zulip):

what exactly do you mean @bjorn3 ?

bjorn3 (Nov 29 2019 at 20:28, on Zulip):

Stacked borrows is kind of a runtime version of the borrowchecker. To make it work correctly, it's state should be serialized too.

Alexander Regueiro (Nov 29 2019 at 20:32, on Zulip):

oh sorry, I parsed your sentence invalidly.

Alexander Regueiro (Nov 29 2019 at 20:32, on Zulip):

it currently is serialised for the miri backend, in fact.

Alexander Regueiro (Nov 29 2019 at 20:32, on Zulip):

it's "just" a dynamic correctness check though, as far as I'm aware? so it's not necessary for the Codegen backend.

bjorn3 (Nov 29 2019 at 20:36, on Zulip):

indeed, cg_llvm doesn't implement it either. it requires a lot of dynamic instrumentation (every call and every borrow/deref) to implement it.

Alexander Regueiro (Nov 29 2019 at 20:36, on Zulip):

yep, I think this is fine. :-)

Alexander Regueiro (Nov 29 2019 at 20:36, on Zulip):

easy enough to say "if you want this sort of dynamic correctness checking, just use the miri backend".

bjorn3 (Nov 29 2019 at 20:37, on Zulip):

yeah, it doesn't make much sense without the other UB checks anyway

Alexander Regueiro (Nov 29 2019 at 20:38, on Zulip):

true

Last update: Dec 12 2019 at 01:20UTC