Hello All,
I finished implementation and refactoring described in
Harmony-1925. In H-1925 You can find some details and patch file
(whole_properties_patch.zip). Any comments are welcome.
I observe the following further improvements (Items for other JIRA-s?):
- In function read_properties
Hi Dmitry,
Could I ask you what is the table_number in your interface?
On 10/20/06, Dmitry Yershov [EMAIL PROTECTED] wrote:
Hi All,
I finished implementation of new properties module for DRL VM.
Also, HARMONY-1925 was created to track the progress. You can
find some details and patch
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
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
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:
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.
Dmitry,
I support your idea to clean up VM properties code. I do not like the
current state of the implementation too.
But I have a couple of questions:
1) Who is responsible to deallocate memory for hidden properties? E.g. the
same const char* value could be allocated with malloc or new or
[snip]
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.
Agree.
..
2006/10/10, Dmitry Yershov [EMAIL PROTECTED]:
[snip]
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
2006/10/10, Mikhail Fursov [EMAIL PROTECTED]:
Dmitry,
I support your idea to clean up VM properties code. I do not like the
current state of the implementation too.
But I have a couple of questions:
1) Who is responsible to deallocate memory for hidden properties? E.g. the
same const char*
On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
I think there is correlation between these 2 questions :). If we use
const char*, we simply copy key and value when setting a property.
And this is impossible with void*.
Ok, this way it does works!
BTW, there is alternative
[snip]
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.
2006/10/10, Mikhail Fursov [EMAIL PROTECTED]:
On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
I think there is correlation between these 2 questions :). If we use
const char*, we simply copy key and value when setting a property.
And this is impossible with void*.
Ok, this way it
I don't think it is good idea to use -Dvm.dlls for setting up DRLVM
specific properties. It should be much safer to use somthing like
-Xvm.dlls. In that case it is really user's responisbility.
Evgueni
On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Dmitry,
Why do we need to hide the
2006/10/10, Evgueni Brevnov [EMAIL PROTECTED]:
I don't think it is good idea to use -Dvm.dlls for setting up DRLVM
specific properties. It should be much safer to use somthing like
-Xvm.dlls. In that case it is really user's responisbility.
I tend to agree - we have freedom to extend command
IMO vm.dlls property is useless today and should be removed at all. So we
need more precise example :)
+ I do not actually feel the difference between -X and -D options. Could
anyone explain when it's better to use -X and when -D?
On 10/10/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
I don't
On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Mikhail,
BTW, what would you say if all JIT-specific properties were kept
separately? E.g. if there were JAVA, VM, JIT types of properties
storage, would it be of some convenience to JIT side? Just curious :)
I think it would be
BTW what if we will have Java component in future (E.g. MMTk's GC)? Will the
hidden properties accessible from Java?
On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Mikhail,
BTW, what would you say if all JIT-specific properties
2006/10/10, Mikhail Fursov [EMAIL PROTECTED]:
BTW what if we will have Java component in future (E.g. MMTk's GC)? Will the
hidden properties accessible from Java?
AFAIU the point is to separate namespaces completely, so that user
could utilize any property name and it would not affect JVM in
On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/10/10, Mikhail Fursov [EMAIL PROTECTED]:
BTW what if we will have Java component in future (E.g. MMTk's GC)? Will
the
hidden properties accessible from Java?
AFAIU the point is to separate namespaces completely, so that user
could
Dmitry Yershov wrote:
[snip]
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
Alexey Varlamov wrote:
2006/10/10, Dmitry Yershov [EMAIL PROTECTED]:
2) Don't hardcode 'hidden' into the API, as we may have other types
down
the road. Make it an argument
Ok. So, the latest list of interface functions should be:
void set_property(const char * key, const char *
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
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
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
+1 to Eugueni and Alexey and -1 to use String type in the intercomponent
interface. + AFAIK the String type is VM internal type only.
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
Here info about EM and JIT modules:
1) org.apache.harmony.vm.vmdir - EM uses this property to locate JIT
libraries.
2) vm.use_interpreter - EM uses this property to detect if it's
interpreter only mode.
3) em.* all EM properties. Actually there are only two today: a)
em.properties - the same as
On Oct 9, 2006, at 8:47 AM, Mikhail Fursov wrote:
Here info about EM and JIT modules:
1) org.apache.harmony.vm.vmdir - EM uses this property to locate JIT
libraries.
2) vm.use_interpreter - EM uses this property to detect if it's
interpreter only mode.
3) em.* all EM properties. Actually
There are my thoughts about VM properties. I observe some problem with
current VM properties implementation:
1) The current VM properties initialization is rather chaotic:
* Some properties stored into two places: Properties class and array of
VmStandardProperty structure. A certain
So one of the interesting things that jumped out of me is the number of
various library and boot classpath properties that we have floating
around, and I'd like to
1) understand this
2) get rid of all the ones that we don't need
Is there a defined set we need to support? Anyone have
30 matches
Mail list logo
