[jira] [Updated] (IGNITE-16229) Improve unmarshalling of immutable containers in the User Object Serialization component

["Roman Puchkovskiy (Jira)" <ji...@apache.org>]

     [ 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)