Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mike.fursov@gmail.com designates
 66.249.92.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=FvUcWk+7IWOa+f87ErsewOLcmX3hc4GWjKfJ3FeP1EtZJlLX7MxQDMaSgj6HPkR6RC1bDDzWrUgwPn+u0RAwDHzqVNfXygtvQsoFRoZqUVjQghXmxmqNtDu5p0FY6FgOH7jkRXj9BXjOzBSEwnsChnITUhs4cfJBoURywbu6l3o=
Message-ID: <bc79dd600610170543q5d55ae82re41def7eb642b132@mail.gmail.com>
Date: Tue, 17 Oct 2006 19:43:51 +0700
From: "Mikhail Fursov" <mike.fursov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] the big soup of VM properties (HARMONY-1626)
In-Reply-To: <200610120345.07133.gshimansky@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_56934_11540364.1161089031974"
References: <4525EB2E.6020301@pobox.com>
	 <f944d83d0610102224n6f6394bhd8e28216a7a51045@mail.gmail.com>
	 <bc79dd600610102241i77a25db6q4f9ed5e917f3bb61@mail.gmail.com>
	 <200610120345.07133.gshimansky@gmail.com>

------=_Part_56934_11540364.1161089031974
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Is there any progress in this area?
Just an interest, because I think that properties refactoring is rather
important task.


+ Does anybody knows the answer on the following question:
All JIT settings are VM properties. User can change the behaviour by
redefining them. Does it affect TCK certification?


On 10/12/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>
> 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
>
>


-- 
Mikhail Fursov

------=_Part_56934_11540364.1161089031974--