harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitry Yershov" <dmitry.yers...@gmail.com>
Subject Re: [drlvm] the big soup of VM properties (HARMONY-1626)
Date Wed, 18 Oct 2006 02:53:03 GMT
2006/10/17, Mikhail Fursov <mike.fursov@gmail.com>:
> Is there any progress in this area?
> Just an interest, because I think that properties refactoring is rather
> important task.

Yes, I'm working on it. I'll provide first patch soon. This patch will
introduce new properties module according my proposal and yours
advises. Then I'll provide second patch which does full re factoring
in VM properties area.

>
>
> + 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?

I don't know the answer, but current implementation does not store JIT
settings into VM properties. It enables these settings through
function:
    (*jit)->next_command_line_argument("-Xjit", arg);  (see parse_arguments.cpp)

Dmitry

>
>
> 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
>
>

---------------------------------------------------------------------
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