harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm] the big soup of VM properties (HARMONY-1626)
Date Wed, 11 Oct 2006 23:45:06 GMT
On Wednesday 11 October 2006 09:41 Mikhail Fursov wrote:
> +1 to Eugueni and Alexey and -1 to use String type in the intercomponent
> interface. + AFAIK the String type is VM internal type only.

Ok you've convinced me. +1 for const char *

> On 10/11/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> > 2006/10/11, Evgueni Brevnov <evgueni.brevnov@gmail.com>:
> > > 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 <gshimansky@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail:
> > > > harmony-dev-help@incubator.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org

-- 
Gregory Shimansky, Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message