Snapshot replay #293
Snapshot replay #293
Conversation
Signed-off-by: Stefan Marr <[email protected]>
Signed-off-by: Stefan Marr <[email protected]>
Signed-off-by: Stefan Marr <[email protected]>
Signed-off-by: Stefan Marr <[email protected]>
Signed-off-by: Stefan Marr <[email protected]>
Signed-off-by: Stefan Marr <[email protected]>
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.
daumayr
force-pushed
the
SnapshotReplay
branch
from
77cc49e to
5693642
Compare
daumayr
force-pushed
the
SnapshotReplay
branch
from
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
| @@ -112,7 +113,7 @@ protected AbstractDirectMessage(final Actor target, final SSymbol selector, | |||
| this.sender = sender; | |||
| 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
| @@ -191,17 +199,39 @@ public void initializeStructure(final MixinDefinition mixinDef, | |||
| this.isTransferObject = isTransferObject; | |||
| 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 addObjectEntry(final Object o, final long offset) { | ||
| synchronized (entries) { | ||
| entries.put(o, offset); | ||
| } | ||
| } | ||
|
|
||
| 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