CORBA25 — tk_indirect

I don't understand why tk_indirect isn't allowed as a top-level typecode.
This causes servere performance penalties for RMI-IIOP because the Java to IDL
mapping requires that Java objects of declared type java.lang.Object are
marshalled as CORBA anys. In the case of a Vector or HashTable with 100
elements, this means that 100 anys must be marshalled. If all of these are
of actual type foo, the restriction on tk_indirect means that all 100 of
these data values must repeat the typeCode for foo, which could be very large.
This causes very substantial overheads, since the space and time needed to
marshal the TypeCode for foo can greatly exceed that needed to marshal the
data for foo.

I understand why a nested tk_indirect cannot refer to any TypeCode outside
the scope of its enclosing top-level TypeCode. However, I don't think this
restriction needs to apply to a top-level TypeCode. We have made this
change experimentally without any adverse effects and we have discovered that
using tk_indirect for all the top-level foo TypeCodes after the first one can
speed up some common scenarios by at least a factor of 5 on end-to-end
measurements. There seems to be no downside to making this change.

I would therefore like to propose the following change to the section headed
"Indirection: Recursive and Repeated TypeCodes" within section 15.3.5.1:

Change the first bullet from:

The indirection applies only to TypeCodes nested within some “top-level”
TypeCode. Indirected TypeCodes are not “freestanding,” but only exist inside
some other encoded TypeCode.

by the following words:

The indirection applies only to TypeCodes nested within some “top-level”
TypeCode, or from one top-level TypeCode to another. Indirected TypeCodes
nested within a top-level TypeCode can only reference TypeCodes that are part
of the same top-level TypeCode, including the top-level TypeCode itself.
Indirected top-level TypeCodes can reference other top-level TypeCodes but
cannot reference TypeCodes nested within some other top-level TypeCode.

If this change finds favour, then we need to work out how it can be brought
into GIOP without causing problems interoperating with older ORBs that insist
on the stronger restriction of the current spec. This could perhaps be
added to the "wish list" for GIOP 1.3.

Close this issue and add it to the GIOP wish list