2006/10/17, Mikhail Fursov <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]> 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 <[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]
>
> --
> 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]
>
>
--
Mikhail Fursov
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
