[
https://issues.apache.org/jira/browse/IGNITE-16229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-16229:
---------------------------------------
Summary: Improve unmarshalling of immutable containers in the User Object
Serialization component (was: Improve unmarshalling of immutable collections
in the User Object Serialization component)
> Improve unmarshalling of immutable containers in the User Object
> Serialization component
> ----------------------------------------------------------------------------------------
>
> Key: IGNITE-16229
> URL: https://issues.apache.org/jira/browse/IGNITE-16229
> Project: Ignite
> Issue Type: Improvement
> Components: networking
> Reporter: Roman Puchkovskiy
> Assignee: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
>
> At the moment, we support just one type of immutable collecitons:
> singletonList, but we'll probably want to support other types like List.of(),
> Set.of() and so on.
> Immutable built-in collections pose a challenge: on the one hand, they can
> participate in cycles and hence need to be read in two phases (instantiate,
> store reference, fill), but on the other hand, they cannot be modified after
> instantiation.
> Right now, we implemented a hack: we still read immutable collections in two
> phases, but for filling them we have a custom code that breaks their
> 'immutability' invariant and pushes the values by force via reflection to
> fill such collections. It seems to work, but it's ugly and potentially
> dangerous (as we are violating the immutability invariant).
> There is another possibility.
> # Handle all the values that are not built-in immutable collections in the
> same way they are handled now
> # For immutable collections, during instantiation phase, create mutable
> placeholders instead of the immutable collection instances themselves
> # Such placeholders need to track the slots of other objects in the graph
> that reference them
> # They are filled normally on the 'fill' phase
> # After the graph is read into memory, it consists of (mainly) normal
> objects and placeholders; the placeholders need to be resolved and replaced
> with proper immutable colleciton values
> # It is impossible to create a cycle of immutable collections (without using
> hacks like Reflection), so we can find connectivity components of the graph
> (each of such component will be a tree) and then instantiate immutable
> collections from placeholders in the leaf-to-root order
> # Placeholders need to be replaced with the instantiated immutable
> collections in the graph; here, the knowledge about the set of slots which
> reference a placeholder (mentioned in item 3) will be useful
> # If we encounter a cycle comprised completely of immutable collections
> (such cycle can only be creafted using some sort of a hack), can either fail
> with an exception or use a hack (reflection) to forge just one connection of
> the cycle.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
