[
https://issues.apache.org/jira/browse/IGNITE-16229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-16229:
---------------------------------------
Description:
At the moment, we support just one type of immutable containers
(singletonList), but we'll probably want to support other types like List.of(),
Set.of() and so on.
Immutable built-in containers 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 containers 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 containers. 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 containers in the same
way they are handled now
# For immutable containers, during instantiation phase, create mutable
placeholders instead of the immutable container 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 container values
# It is impossible to create a cycle of immutable containers (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
containers from placeholders in the leaf-to-root order
# Placeholders need to be replaced with the instantiated immutable containers
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 containers (such
cycle can only be creafted using some sort of a hack), we can either fail with
an exception or use a hack (reflection) to forge just one connection of the
cycle.
This is a hybrid approach of
* always having 'real' objects in the graph - which is not realistic when we
have immutable containers
* and always constructing a graph of placeholders first and then turning them
into real objects (this is what Spring does with Bean Definitions and then
Beans) - which seems to incur too much overhead, especially having in mind that
most of the objects are not immutable containers and hence do not need
placeholders to represent them in the intermediate graph
was:
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.
> 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 containers
> (singletonList), but we'll probably want to support other types like
> List.of(), Set.of() and so on.
> Immutable built-in containers 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 containers 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 containers. 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 containers in the
> same way they are handled now
> # For immutable containers, during instantiation phase, create mutable
> placeholders instead of the immutable container 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 container values
> # It is impossible to create a cycle of immutable containers (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
> containers from placeholders in the leaf-to-root order
> # Placeholders need to be replaced with the instantiated immutable
> containers 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 containers (such
> cycle can only be creafted using some sort of a hack), we can either fail
> with an exception or use a hack (reflection) to forge just one connection of
> the cycle.
> This is a hybrid approach of
> * always having 'real' objects in the graph - which is not realistic when we
> have immutable containers
> * and always constructing a graph of placeholders first and then turning
> them into real objects (this is what Spring does with Bean Definitions and
> then Beans) - which seems to incur too much overhead, especially having in
> mind that most of the objects are not immutable containers and hence do not
> need placeholders to represent them in the intermediate graph
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
