+1 to Eugueni and Alexey and -1 to use String type in the intercomponent
interface. + AFAIK the String type is VM internal type only.

On 10/11/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:

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]




--
Mikhail Fursov

Reply via email to