Bug 1151

Summary:	Issues with ACE_Hash_Map_Manager implementation
Product:	ACE	Reporter:	Nanbor Wang <bala>
Component:	ACE Core	Assignee:	DOC Center Support List (internal) <tao-support>
Status:	ASSIGNED ---
Severity:	normal	CC:	fhunleth
Priority:	P3
Version:	5.2.1
Hardware:	All
OS:	All
Bug Depends on:
Bug Blocks:	2181

Description Nanbor Wang 2002-02-16 09:27:28 CST

This bug report talks about issues including the ones discussed in Bug 907. 
Here are some of the issues

1. There are no Real-time characteristics in the ACE_Hash_Map. One of the main 
reasons for concluding this way is that, ACE doesnt grow the number of buckets. 
Further, the increase in the size of the map is arbitrary. This could lead to 
unpredictability. Dr. Cytron and his student have already got a working version 
in JAVA. They should be porting it to ACE shortly. Instead of modifuying the 
existing Hahs_Map, the new Hash_Map inheriting from the existing code, so that 
the interface and semantics can be maintained. This will also allow the users a 
choice of using whichever way they want to go. TAO woul also benefit from this 
two class thingy. Not all portions of TAO need this Real-time hash map. 

2. To reduce footprint, we need a (partial?) template specialization for the 
Hash_Map_Manager with a string->pointer mapping. This would reduce multiple 
instantiations of the Hash_Map_Manager and hence a reduction in footprint. We 
may also want to make carefull study of the exisiting TAO code and application 
code to see whether any other specialization would help. My gut feeling is that 
a long->pointer mapping could also be considered. This would atleast be useful 
the new Reactor design for the map of events handlers on Win32. 

3. Another issue is the heavy interface that the ACE_Hash_Map exports. Many 
application dont use the different iterators that the Hash_Map provides. But 
they have to instantiate them anyway with broken compilers. Sadly the commonly 
used OS's for DRE systems seem to use such compilers. They instantiate these 
multiple iterators which blows up the footprint. It would be nice to have a 
smaller Hash_Map and have the regular Hash_Map derive from that.  We could also 
then have RT versions of these different maps.

Comment 1 Nanbor Wang 2002-02-16 09:29:42 CST

*** Bug 907 has been marked as a duplicate of this bug. ***

Comment 2 Ravi Pratap M 2002-02-21 16:43:35 CST

Comments on plans to address this bug after the meeting between Dr.Cytron, Irfan
and Ravi.

* Instead of building in real-time characteristics by subclassing in different
ways to get the required functionality, a better way would be to implement this
using an observer [which examines the hash table's state in order to determine
if any actions like rehashing need to be done] and by encapsulating the strategy
used to rehash, within a separate class by itself. This approach seems like a
better thing to do given that subclassing would lead to arbitrarily-sized
classes. So, the same class could be used in whatever manner is deemed
necessary, with or without real-time characteristics purely by choosing what
kind of strategy is employed for rehashing [if at all].

* Special cases like string->pointer mappings could be implemented using partial
template specialization as pointed out in the original bug report. The idea
would be to write a wrapper class which would probably instantiate a class
mapping string->(void *) and perform the necessary casts when used for specific
types. Since the wrapper would be really thin, the increase in footprint with
each instantiation would be much smaller.

* To cut down on the heavy interface exported, a viable strategy would be to
have a Hash_Map_Manager_Lite class which would support the very basic operations
and then have other classes inherit from that and accordingly support whatever
iterators seem useful / necessary.