Snapshot replay#293
Conversation
Signed-off-by: Stefan Marr <git@stefan-marr.de>
Signed-off-by: Stefan Marr <git@stefan-marr.de>
Signed-off-by: Stefan Marr <git@stefan-marr.de>
Signed-off-by: Stefan Marr <git@stefan-marr.de>
Signed-off-by: Stefan Marr <git@stefan-marr.de>
Signed-off-by: Stefan Marr <git@stefan-marr.de>
The result promise is serialised in another actor and therefore serialised as completed.
previously returns caused a lack of progress issue.
correct the specialization order, remove magic numbers, avoid serializing delivered messages on the wrong actor.
correct the handling of Promises, add static deserialisation option.
When the assumption becomes false while specialising, an UnsupportedSpecializationException was caused because no fallback existed.
77cc49e to
5693642
Compare
5693642 to
0c9b1b6
Compare
| // need to be careful, might interfere with promise serialization... | ||
| return -1; | ||
| @TruffleBoundary | ||
| // TODO: can we establish a structure for this? at the moment, we have an |
There was a problem hiding this comment.
The serializer is compilation final (child node of receive).
There is still some indirection of accessing fields
| this.target = target; | ||
|
|
||
| if (VmSettings.SNAPSHOTS_ENABLED) { | ||
| if (VmSettings.SNAPSHOTS_ENABLED && !VmSettings.REPLAY) { |
There was a problem hiding this comment.
Seeing these and other flags, should we try to have two distinct: SNAPSHOT_RECORDING and SNAPSHOT_REPLAY? This could possibly avoid issues with wrongly combining/testing flags?
So, I mean, instead of having SNAPSHOT_ENABLED.
There was a problem hiding this comment.
Yes, refactoring the flags probably reduces ambiguity and improves readability of the code
| this.isArray = isArray; | ||
| this.instanceClassGroup = classFactory; | ||
|
|
||
| if (VmSettings.SNAPSHOTS_ENABLED) { |
There was a problem hiding this comment.
Could this change go into its own method?
There was a problem hiding this comment.
i can make an initializeForSnapshotting method
| } | ||
|
|
||
| public void handleTodos(final SnapshotBuffer sb) { | ||
| @TruffleBoundary // TODO: convert to an approach that constructs a cache |
There was a problem hiding this comment.
only if you want to use cachedserialization nodes
| return deserialized.size(); | ||
| } | ||
|
|
||
| private void printPosition(final long current) { |
There was a problem hiding this comment.
This and the printClass methods look strange.
Are they used? Should they be implemented but have a VmSettings.DEBUG flag or something? I think there may be such a flag?
There was a problem hiding this comment.
I haven't used them for a while, we can probably remove them.
We could also use a flag, but this can produce a LOT of output.
This PR implements replay from snapshots.
It also fixes various problems with the previous snapshot implementation e.g. Outer Objects of Classses, ownership of promises and various duplication issues.
TODO: enable snapshotting/serialization tests