Archived
This forum has been archived. Please start a new discussion on GitHub.
Q on Data encoding
Hello,
I am studying the data encoding convention used in ICE and I had a few questions related to reference encoding.
1° Why using negative numbers for pointers and not same value as class id n° ? Context of use leaves no ambiguity between pointer and class id. Is this a scar of ICE data encoding evolution ?
2° The classID is an arbitrary number picked by the marshaller. This gives indeed some liberty degree, except that the value must be a strictly positive number. As shown in one example (in table 40.4 of ICE doc 2.0) and explained in the algorithm presented at page 1108, the natural strategy would be to number classes from 1 to N in the order of their serialization. This numbering rule seams perfectly deterministic. So why not making this numbering rule standard and let classID be implicitely numbered by order or serialization ? This would allow to get rid of this number in the serialized data.
3° Why choosing the "delayed object serialization" and not a serialization in place of first reference ? Is it to avoid stack overflow when marshalling very deep data structures ? Shouldn't this rationale then also apply to sequences ?
4° I am a bit confused about sequences. It looks like sequences are not treated like referenced data. What happens if two arguments of a method call are in fact referencing the same array ?From the documentation fragments I red it looks like ICE marshalling process would generate two distinct copies of the sequence. So the receiver doesn't know that these are in fact the same array. I know that we can get around this, if this happens to be a problem, by encapsulating the array in an object. But CORBA handles sequences as referenced data so it would handle shared sequences properly. What about ICE ?
I am studying the data encoding convention used in ICE and I had a few questions related to reference encoding.
1° Why using negative numbers for pointers and not same value as class id n° ? Context of use leaves no ambiguity between pointer and class id. Is this a scar of ICE data encoding evolution ?
2° The classID is an arbitrary number picked by the marshaller. This gives indeed some liberty degree, except that the value must be a strictly positive number. As shown in one example (in table 40.4 of ICE doc 2.0) and explained in the algorithm presented at page 1108, the natural strategy would be to number classes from 1 to N in the order of their serialization. This numbering rule seams perfectly deterministic. So why not making this numbering rule standard and let classID be implicitely numbered by order or serialization ? This would allow to get rid of this number in the serialized data.
3° Why choosing the "delayed object serialization" and not a serialization in place of first reference ? Is it to avoid stack overflow when marshalling very deep data structures ? Shouldn't this rationale then also apply to sequences ?
4° I am a bit confused about sequences. It looks like sequences are not treated like referenced data. What happens if two arguments of a method call are in fact referencing the same array ?From the documentation fragments I red it looks like ICE marshalling process would generate two distinct copies of the sequence. So the receiver doesn't know that these are in fact the same array. I know that we can get around this, if this happens to be a problem, by encapsulating the array in an object. But CORBA handles sequences as referenced data so it would handle shared sequences properly. What about ICE ?
0
Comments
-
Questions 1-3 refer to objects by value, correct? If so, then I leave this to Michi to answer, since he wrote the object by value marshaling code. (It might take awhile until he responds, because he is currently on vacation.)
With respect to question 4, sequences are not shared, neither in Ice nor in CORBA. They do not have reference semantics. For example, in C++ a sequence of strings maps to std::vector<std::string>. If you want a sequence by reference, then you must use a class with a sequence data member. Ice is not different from CORBA in this respect.0 -
Do you mean Michi designed the class serialization encoding ?
Thank you for the clarification on sequence semantic. I should add oops... !
I should better read the Slice language specification before asking anymore questions
0 -
Yes, Michi designed the object-by-value serialization. I wrote the initial version, but it didn't support slicing. Michi then later redesigned the marshaling, so that slicing is now fully supported. He also added an object-by-value garbage collector for Ice for C++. Without this garbage collector, you get a memory leak in C++ if you receive objects that reference each other, i.e., if there are cyclic references.0
