2006/10/11, Evgueni Brevnov <[EMAIL PROTECTED]>:
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...
Agreed. Besides properties are used in VM almost solely during init,
no performance gain here. So -1 to using Strings for properties.
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]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
