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