Bug 453

In the last week we had a number of very interesting discussions with Jim
Scheler about how to improve the allocation of CDR buffers.  First a note
on what the problem is:  TAO allocates the CDR buffers on demand, as it
marshals the arguments it discovers that more memory is needed and the it
"grows" the CDR stream.  The algorithm to grow the stream was busted, but
Jim was patient enought to discover that, so we were able to fix it.

The problem with this approach is that for large requests the are multiple
allocations.  Jim proposed to somehow estimate the size of the arguments, to
perform a single allocation *before* any marshaling, and proceed from there.
We had discuss such ideas in the past, with Andy G. and other members of the
DOC group, but Jim had several good suggestions that i will try to reproduce
here.

First Jim does not want to have a "perfect" estimate, this would be too
expensive as it would have to compute the length of strings, Anys, Typecodes,
recursive sequences, etc.  Instead he proposes to have a rough estimate of
the argument size, but in such a way that the estimate can be overriden.
Thus, applications that need a better estimate can provide a better way to
do it.

Jim proposed to add a virtual function to the IDL generated types, the
application can then override the virtual function to do what they want.
I don't like that approach very much, it is too intrusive to add virtual
functions to say an IDL generated structure, it would break the interpretive
engine (like i care).  More importantly, i'm not sure how the user could
ensure that her new types are used instead of the stock ones, think about
a sequence, the ORB allocates the IDL generated types, not what the user
provides.

I have proposed two alternatives, one is to use static functions, like this:
---------------- cut here ----------------
// IDL
struct Foo {
  long   mOne;
  long   mTwo;
  string mStr;
};

// C++
struct Foo {
  CORBA::Long   mOne;
  CORBA::Long   mTwo;
  CORBA::String mStr;

  static size_t _tao_default_EstimatedSize(const Foo&);
  static size_t (_tao_EstimatedSize*) (const Foo&);
};

// Probably i will get this syntax wrong,
// that's what compilers are for ;-)
size_t
(Foo::_tao_EstimatedSize*) (const Foo&) = Foo::_tao_default_EstimatedSize;
---------------- cut here ----------------

	Notice how this approach in unintrusive of the generated data type,
yet the application developer can override the default implementation of
the function to estimate the size.

	There is another approach,  similar to some discussions we had in
the past with Andy.  We could generate a helper class, like this:

 ---------------- cut here ----------------
       class _tao_Foo_Helper : public TAO_Helper {
	public:

	  virtual size_t estimated_size (const Foo&);

	  virtual Foo *allocate_array (size_t count);
	  virtual void deallocate_array (Foo*);

	  virtual int marshal (TAO_OutputCDR &cdr,
			       const Foo &);
	  virtual int demarshal (TAO_InputCDR &cdr,
			         Foo &);
	};
---------------- cut here ----------------

	the idea here is to keep all the helper methods on a separate class.
A default implementation of the class is kept on a singleton, but the
application can change its value if they want to.  This approach is more
extensible, as shown, we could use it to define custom allocators, or
implement the semi-interpretive marshaling engine that Andy used to like.

	Both approaches (and Jim's for that matter), can be complemented
with a per-operation helper method:

---------------- cut here ----------------
// IDL
interface Bar { void method (in Foo x); }

// C++
class Bar : public CORBA::Object
{
public:
  void method (const Foo& x) throw (CORBA::SystemException);
  void _tao_method (size_t &_tao_cdr_size, const Foo& x) {
     _tao_cdr_size = sizeof (Foo);  // Or the helper classes above
  }
};
---------------- cut here ----------------

	The stub will invoke this new helper method to get an estimate of the
CDR buffer requirements.  The application developer can use smart proxies to
override the algorithm used to compute that estimate.
	This gives *really* fine grained control over the buffer pre-allocation
strategy, but there is a cost in footprint and programming effort for the
application developer.

	As usual we really need to strategize this stuff.  In many
applications all these fancy estimates are a waste, because the
pre-allocated buffer is big enough for most cases.  In many other
applications the "grown on demand" strategy is good enough, specially
now that it is correctly implemented, when properly configured the
maximum number of allocations in that strategy can be bounded,
using exponential growth it can takes as little as 16 allocations to
take over the complete address space (more on 64-bit machines).
	Only applications that need to send large amounts of data,
and where the data is very regular would benefit from such ingenious
approaches.