Gregory,

My 2cents:

1cent) I think we should not integrate property module so tight (by
using StringPool) with VM internals. Let it be independent enough.
2cent) I also don't think we should pollute StringPool any further.
Instead I would like to see if we can get it smaller.... say by
splitting into two pools whatever...

Evgueni

On 10/11/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
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]



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to