On Tuesday 10 October 2006 11:36 Geir Magnusson Jr. wrote: > Inline > > Dmitry Yershov wrote: > > [snip] > > > VM properties proposal > > ====================== > > > > The general purpose of VM Properties subcomponent is to provide > > centralized access to a common properties table. A property is meant > > as a pair of <key> and <value>. The properties stored in VM Properties > > table represent configuration settings for a separate component (such > > as VMCore, GC, JIT etc) or for the whole system. Another use case for > > the properties is communication between different components. > > > > Requirements > > ============ > > > > 1) The <key> and <value> are represented as string (i.e. char*). > > and I propose that on each operation, a copy is made, so that the caller > frees the string that they got or gave.
Hmm... I thought of another type. VM has a String class which represents an internal strings implementation. String pointers all refer to the same interned const char * memory location so comparing them is faster, you just compare pointers. Would it be better to have key and value be String * instead of const char *? It would save memory allocation, copying and comparing and lookup in properties hash table could be done using a pointer. I don't think it is a very performance critical place, properties aren't accessed very often, but at least it may reduce memory footprint and will cause less memory leaks when someone forgets to free a returned copy. On the other hand, String storage is global to the whole VM, so there are tons of strings kept inside of it. Lookup inside of a small hash table like properties may be much faster than lookup through all the strings that VM keeps... Hmm now I am not sure I want to suggest this way, just want it to be considered. -- Gregory Shimansky, Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
