Re: [drlvm] too tired, need help
File vm/vmcore/src/init/vm_main.cpp, line 68.
Global_Env env(m, properties);
On 06/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I know the type. The question is where is that variable env declared
and set?
geir
Weldon Washburn wrote:
The first parameter to create_vm() is of type Global_Env.
Global_Env is defined in environment.h
vm_init() in vm_init.cpp initializes a bunch of Globla_Env's members.
On 10/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure how it
gets to us...), and I'm too tired, too dumb, or both to figure this
out.
Launcher calls JNI_CreateJavaVM. In our vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void *vm_args)
{
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be useless
here...
geir
-
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]
--
Best regards,
Pavel Rebriy
Re: [drlvm] too tired, need help
Thank you.
How does the compiler know this when compiling jni.cpp? is there an
extern defn somewhere?
geir
Pavel Rebriy wrote:
File vm/vmcore/src/init/vm_main.cpp, line 68.
Global_Env env(m, properties);
On 06/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I know the type. The question is where is that variable env declared
and set?
geir
Weldon Washburn wrote:
The first parameter to create_vm() is of type Global_Env.
Global_Env is defined in environment.h
vm_init() in vm_init.cpp initializes a bunch of Globla_Env's members.
On 10/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure how it
gets to us...), and I'm too tired, too dumb, or both to figure this
out.
Launcher calls JNI_CreateJavaVM. In our vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void *vm_args)
{
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be useless
here...
geir
-
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]
Re: [drlvm] too tired, need help
I got it - thanks to Pavel.
There's an extern in init.h, and it's declared in vm_main.cpp.
Would anyone mind if I renamed it something less innocuous like
global_env
vm_global_env
Something that gives the reader the hint that it's not a local var.
geir
Geir Magnusson Jr. wrote:
Thank you.
How does the compiler know this when compiling jni.cpp? is there an
extern defn somewhere?
geir
Pavel Rebriy wrote:
File vm/vmcore/src/init/vm_main.cpp, line 68.
Global_Env env(m, properties);
On 06/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I know the type. The question is where is that variable env declared
and set?
geir
Weldon Washburn wrote:
The first parameter to create_vm() is of type Global_Env.
Global_Env is defined in environment.h
vm_init() in vm_init.cpp initializes a bunch of Globla_Env's members.
On 10/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure how it
gets to us...), and I'm too tired, too dumb, or both to figure this
out.
Launcher calls JNI_CreateJavaVM. In our vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void
*vm_args)
{
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be useless
here...
geir
-
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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] too tired, need help
Geir,
Please don't do that until HARMONY-1582 integration. It can introduce
many conflicts.
Tnanks in advance.
Evgueni
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I got it - thanks to Pavel.
There's an extern in init.h, and it's declared in vm_main.cpp.
Would anyone mind if I renamed it something less innocuous like
global_env
vm_global_env
Something that gives the reader the hint that it's not a local var.
geir
Geir Magnusson Jr. wrote:
Thank you.
How does the compiler know this when compiling jni.cpp? is there an
extern defn somewhere?
geir
Pavel Rebriy wrote:
File vm/vmcore/src/init/vm_main.cpp, line 68.
Global_Env env(m, properties);
On 06/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I know the type. The question is where is that variable env declared
and set?
geir
Weldon Washburn wrote:
The first parameter to create_vm() is of type Global_Env.
Global_Env is defined in environment.h
vm_init() in vm_init.cpp initializes a bunch of Globla_Env's members.
On 10/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure how it
gets to us...), and I'm too tired, too dumb, or both to figure this
out.
Launcher calls JNI_CreateJavaVM. In our vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void
*vm_args)
{
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be useless
here...
geir
-
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]
-
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]
Re: [drlvm] too tired, need help
Lets make a deal. If you do a fresh diff using svn diff for 1582 so I
can commit the thing, I'll wait ;)
geir
Evgueni Brevnov wrote:
Geir,
Please don't do that until HARMONY-1582 integration. It can introduce
many conflicts.
Tnanks in advance.
Evgueni
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I got it - thanks to Pavel.
There's an extern in init.h, and it's declared in vm_main.cpp.
Would anyone mind if I renamed it something less innocuous like
global_env
vm_global_env
Something that gives the reader the hint that it's not a local var.
geir
Geir Magnusson Jr. wrote:
Thank you.
How does the compiler know this when compiling jni.cpp? is there an
extern defn somewhere?
geir
Pavel Rebriy wrote:
File vm/vmcore/src/init/vm_main.cpp, line 68.
Global_Env env(m, properties);
On 06/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I know the type. The question is where is that variable env
declared
and set?
geir
Weldon Washburn wrote:
The first parameter to create_vm() is of type Global_Env.
Global_Env is defined in environment.h
vm_init() in vm_init.cpp initializes a bunch of Globla_Env's
members.
On 10/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure
how it
gets to us...), and I'm too tired, too dumb, or both to figure
this
out.
Launcher calls JNI_CreateJavaVM. In our
vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void
*vm_args)
{
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined
or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be
useless
here...
geir
-
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]
-
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]
Re: [drlvm] too tired, need help
And it would only introduce a few, as far as I can tell, as only jni.cpp
and vm_main.cpp actually include init.h, and therefore are the only
files that depend on that global
geir
Evgueni Brevnov wrote:
Geir,
Please don't do that until HARMONY-1582 integration. It can introduce
many conflicts.
Tnanks in advance.
Evgueni
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I got it - thanks to Pavel.
There's an extern in init.h, and it's declared in vm_main.cpp.
Would anyone mind if I renamed it something less innocuous like
global_env
vm_global_env
Something that gives the reader the hint that it's not a local var.
geir
Geir Magnusson Jr. wrote:
Thank you.
How does the compiler know this when compiling jni.cpp? is there an
extern defn somewhere?
geir
Pavel Rebriy wrote:
File vm/vmcore/src/init/vm_main.cpp, line 68.
Global_Env env(m, properties);
On 06/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I know the type. The question is where is that variable env
declared
and set?
geir
Weldon Washburn wrote:
The first parameter to create_vm() is of type Global_Env.
Global_Env is defined in environment.h
vm_init() in vm_init.cpp initializes a bunch of Globla_Env's
members.
On 10/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure
how it
gets to us...), and I'm too tired, too dumb, or both to figure
this
out.
Launcher calls JNI_CreateJavaVM. In our
vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void
*vm_args)
{
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined
or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be
useless
here...
geir
-
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]
-
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]
Re: [classlib][pack200] Unpacked my first archive today!
Great news! 2006/10/6, Alex Blewitt [EMAIL PROTECTED]: I managed to unpack a Pack200 file completely today for the first time, so that by the end of it there were no bytes left in the queue. Unfortunately, it wasn't a spectacularly exciting archive -- just one interface with no methods (about as exciting as java.lang.Serializable, in fact) but I think that I've unlocked the next stage in the process for decompressing the attributes that are left (including things like bytecodes, etc.). At the moment, the data is just in an unpacked state; I've not yet looked at re-assembling the data into their constituent .class files (need to get hold of the class bytecode format for that) or even reconstituting the Jar file. I'm thinking of using ZipEntry and ZipOutputStream (or corresponding Jar variants) for building the resulting Jar file. I'm not sure whether they are implemented or not in the current trunk or not, but I might start working against the ZipOutputStream/ZipEntry APIs. Onward and upward ... Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko 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]
Re: [classlib][test] Site to collect classlib test statistics
Anton, Many thanks for exploring this area, it looks quite promising. An idea: this service would become more valuable if presented transparent search/comparison of results for particular tests over all uploaded runs. Let user enter name of a test and show in one table all known results for this test, or even better, provide a table of all ever failed tests with links to individual consolidated tables. This would help analyzing failures very much. -- Regards, Alexey 2006/10/4, Anton Luht [EMAIL PROTECTED]: Hello, Could you tell about it in more detail? 1) Who can upload test results? Everyone - no authorization is needed, you can include file upload to your regular builds if you want - authorized users can remove them later if something goes wrong :) If you want to modify uploaded tests' data - add JIRA issues to failures, add comments, etc - please send me login/password and I'll create an account. 2) How are you going to develop this site, structure, data base and etc.? I'll try to implement all feature requests that community members will express. One of possible directions I see is support for new test suites - currently it recognises only Harmony classlib JUnit tests output. If you have another test suite you want to upload to that site - just send me an archive and I'll try to add support for this kind of tests. Sources of that app are not in SVN now - if you want to review/fix/improve something - I can send you an archive. -- Regards, Anton Luht, 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]
Re: [drlvm] too tired, need help
I can't provide you with the fresh patch right now. I want to restrore
cunit tests first.
If it doesn't introduce many changes then go ahead and commit. It
should be easy to merge then.
Evgueni
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
And it would only introduce a few, as far as I can tell, as only jni.cpp
and vm_main.cpp actually include init.h, and therefore are the only
files that depend on that global
geir
Evgueni Brevnov wrote:
Geir,
Please don't do that until HARMONY-1582 integration. It can introduce
many conflicts.
Tnanks in advance.
Evgueni
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I got it - thanks to Pavel.
There's an extern in init.h, and it's declared in vm_main.cpp.
Would anyone mind if I renamed it something less innocuous like
global_env
vm_global_env
Something that gives the reader the hint that it's not a local var.
geir
Geir Magnusson Jr. wrote:
Thank you.
How does the compiler know this when compiling jni.cpp? is there an
extern defn somewhere?
geir
Pavel Rebriy wrote:
File vm/vmcore/src/init/vm_main.cpp, line 68.
Global_Env env(m, properties);
On 06/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I know the type. The question is where is that variable env
declared
and set?
geir
Weldon Washburn wrote:
The first parameter to create_vm() is of type Global_Env.
Global_Env is defined in environment.h
vm_init() in vm_init.cpp initializes a bunch of Globla_Env's
members.
On 10/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure
how it
gets to us...), and I'm too tired, too dumb, or both to figure
this
out.
Launcher calls JNI_CreateJavaVM. In our
vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void
*vm_args)
{
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined
or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be
useless
here...
geir
-
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]
-
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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] too tired, need help
;)
I'll wait - I was just teasing. I'm going to bed now...
geir
Evgueni Brevnov wrote:
I can't provide you with the fresh patch right now. I want to restrore
cunit tests first.
If it doesn't introduce many changes then go ahead and commit. It
should be easy to merge then.
Evgueni
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
And it would only introduce a few, as far as I can tell, as only jni.cpp
and vm_main.cpp actually include init.h, and therefore are the only
files that depend on that global
geir
Evgueni Brevnov wrote:
Geir,
Please don't do that until HARMONY-1582 integration. It can introduce
many conflicts.
Tnanks in advance.
Evgueni
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I got it - thanks to Pavel.
There's an extern in init.h, and it's declared in vm_main.cpp.
Would anyone mind if I renamed it something less innocuous like
global_env
vm_global_env
Something that gives the reader the hint that it's not a local var.
geir
Geir Magnusson Jr. wrote:
Thank you.
How does the compiler know this when compiling jni.cpp? is there an
extern defn somewhere?
geir
Pavel Rebriy wrote:
File vm/vmcore/src/init/vm_main.cpp, line 68.
Global_Env env(m, properties);
On 06/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I know the type. The question is where is that variable env
declared
and set?
geir
Weldon Washburn wrote:
The first parameter to create_vm() is of type Global_Env.
Global_Env is defined in environment.h
vm_init() in vm_init.cpp initializes a bunch of Globla_Env's
members.
On 10/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure
how it
gets to us...), and I'm too tired, too dumb, or both to figure
this
out.
Launcher calls JNI_CreateJavaVM. In our
vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void
*vm_args)
{
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined
or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be
useless
here...
geir
-
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]
-
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]
-
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]
Re: Wonka, Mika, and Apache
On Thursday 05 October 2006 18:38, Geir Magnusson Jr. wrote: w00t :) Don't get too excited - it wouldn't be the first time that I've got no answer to such a mail. But I'll follow up with a phone call on Monday if no reply by then. Do we need them to make a bulk contribution, or can we handle them as an other contributor? I can testify to the provenance of the code, as I was project leader at Acunia from the very beginning. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wonka, Mika, and Apache
On Thursday 05 October 2006 19:06, Tim Ellison wrote: Apologies for drifting off-topic... Is there a spec for the shape and behavior of headless SE and embeddable SE etc.? I have only seen passing references to what they are and how they act like SE. SFAIK a headless SE is simply one for which java.awt.headless has been set true; that tells the JRE to implement image operations in software instead of using the graphical capabilities of the underlying platform. Embedded SE seems to refer to a build for PowerPC that Sun demoed at ESC. If it's distributed on the same licence terms as normal JavaSE then it won't be legal to distribute stripped versions which only contain the packages needed by the application. (Presumably the same restriction will apply to certified versions of Harmony once these exist). [geir] I fully expect that over time, this project will have multiple virtual machines, as well as multiple builds for classlib to support various deployment platforms. and potentially configurations, though to tackle ME would require the ability to subset the behavior of the existing types as well. For CLDC, yes. For CDC it should be possible to just subset the classlib. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] too tired, need help
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure how it
gets to us...), and I'm too tired, too dumb, or both to figure this out.
Geir,
To avoid possible duplication - there is HARMONY-1626 about smth very
similar, and I'm ready to submit a patch, just waiting for H-1582.
Launcher calls JNI_CreateJavaVM. In our vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void *vm_args) {
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be useless here...
geir
-
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]
Re: [drlvm] too tired, need help
Alexey Varlamov wrote:
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure how it
gets to us...), and I'm too tired, too dumb, or both to figure this out.
Geir,
To avoid possible duplication - there is HARMONY-1626 about smth very
similar, and I'm ready to submit a patch, just waiting for H-1582.
Ah - I was looking at this very JIRA. I didn't realize you were working
on it. PLease submit the patch now just so i can see it so i can to to
bed w/ a peaceful mind.
You can submit another after 1582 - also, please link to 1582
geir
Launcher calls JNI_CreateJavaVM. In our vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void *vm_args) {
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be useless
here...
geir
-
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]
Re: Wonka, Mika, and Apache
Chris Gray wrote: On Thursday 05 October 2006 18:38, Geir Magnusson Jr. wrote: w00t :) Don't get too excited - it wouldn't be the first time that I've got no answer to such a mail. But I'll follow up with a phone call on Monday if no reply by then. Do we need them to make a bulk contribution, or can we handle them as an other contributor? I can testify to the provenance of the code, as I was project leader at Acunia from the very beginning. Who owns the copyright and can therefore make the donation? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HARMONY-1317) [classlib][internationalization]Internationalization of the rmi module
Hi committers! Could someone look into the patch with [rmi] internationalization HARMONY-1317? Patch affects many source files and it would be great to apply it ASAP (if it is OK of course:)) to avoid conflicts with another changes in the Harmony svn. Thanks, Ilya. On 10/4/06, Ilya Okomin (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-1317?page=all ] Ilya Okomin updated HARMONY-1317: - Attachment: rmi.diff Wow, it was really hard work! Please try this patch. [classlib][internationalization]Internationalization of the rmi module -- Key: HARMONY-1317 URL: http://issues.apache.org/jira/browse/HARMONY-1317 Project: Harmony Issue Type: Sub-task Components: Classlib Reporter: Ilya Okomin Priority: Trivial Attachments: rmi.diff [rmi] module should be internationalized with the scheme suggested in HARMONY-1308 issue [1]. [1] http://issues.apache.org/jira/browse/HARMONY-1308 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- -- Ilya Okomin Intel Middleware Products Division
Re: [drlvm] too tired, need help
I have this almost done so that it uses the boot classpath generated by
luni. Only remaining peace is to add kernel.jar to it, and I'll do that
so it comes from the VMDIR - we wanted to move kernel.jar there anyway
for cleaner deployment.
I just couldn't stop... no mental peace. :)
Geir Magnusson Jr. wrote:
Alexey Varlamov wrote:
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure how it
gets to us...), and I'm too tired, too dumb, or both to figure this out.
Geir,
To avoid possible duplication - there is HARMONY-1626 about smth very
similar, and I'm ready to submit a patch, just waiting for H-1582.
Ah - I was looking at this very JIRA. I didn't realize you were working
on it. PLease submit the patch now just so i can see it so i can to to
bed w/ a peaceful mind.
You can submit another after 1582 - also, please link to 1582
geir
Launcher calls JNI_CreateJavaVM. In our vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void *vm_args) {
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be useless
here...
geir
-
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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
Thank you for your message - Id been round 10 times before I received it. ;) Fedotov, Alexei A wrote: BTW, I really enjoyed the last item of the Quick Start section: 7. If building the DRLVM fails, read this README and follow building instructions to the point. A hardcore programmer can loop infinitely here. :-) With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Fedotov, Alexei A Sent: Friday, October 06, 2006 12:20 AM To: =SMTP:[EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org Subject: RE: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Hi, Nadya, I tried to build DRLVM, faced the issue from the thread below, and filed a JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1730. Does the patch worth to be applied to the README.txt? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Spark Shen [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 9:56 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Thank you, I am trying :-). 2006/9/22, Vladimir Gorr [EMAIL PROTECTED]: On 9/22/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. Sorry for the late reply. JIRA 1500 is due to discussion [1] on the dev mailing list. I can not build DRLVM on my desktop. (Windows XP, RI JDK1.5.0, ant 1.6.5). So I could not reproduce the bug The prompted error message is: C:\spark\drlvm\trunk\build\make\build.xml:238: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:289: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:291: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:462: Warning: Could not find file C:\spark\drlvm\trunk\build\make\no_settings_in_config_or_environment to copy. This is the first time I build DRLVM, would you give me some hint about this error message. It seems you didn't run the *build.bat update* before starting the build. We need to run the following steps (sorry if you're aware about this): - svn checkout classlib - svn checkout drlvm - build classlib (cd classlib/trunk; ant fetch-depend; ant) - cd drlvm/trunk/build - build.bat update (you need to slightly some time here :-) ) - build.bat Thanks, Vladimir. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony- dev/200609.mbox/[EMAIL PROTECTED] . com%3e Best regards Gang, it'd be not bad to run DRLVM testing for any commits to SVN repository. Otherwise we will be very hard to catch any errors like this. Any thoughts? Thanks, Vladimir. On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty ( UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java :2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace( UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle .init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. I am looking into this issue. Is there any progress here? Did you managed to reproduce it? Same issue is also mentioned for other thread (*Trouble Building DRLVM*). Thanks in advance, Vladimir. Best regards Thanks, Vladimir. -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL
RE: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
Thanks for the fix, Alexei. I think this is a good start for updating the README. I've looked at the current version, and many other things are out-of-date (such as ij as the name of our executable). Some things are also duplicated - we now have the nice Quick Help pages for users [1] and developers [2]. As I see it, the Quick Start you've been referring to roughly matches [1], whereas [2] is for those who have to 'read this README and follow building instructions to the point.' :) I suggest that we edit the README file more to improve it. What do you think? Do you think we can use JIRA 1730 for these changes? [1] http://incubator.apache.org/harmony/quickhelp_users.html [2] http://incubator.apache.org/harmony/quickhelp_contributors.html Best regards, Nadya Morozova -Original Message- From: Fedotov, Alexei A Sent: Friday, October 06, 2006 12:23 AM To: Morozova, Nadezhda Cc: harmony-dev@incubator.apache.org Subject: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 BTW, I really enjoyed the last item of the Quick Start section: 7. If building the DRLVM fails, read this README and follow building instructions to the point. A hardcore programmer can loop infinitely here. :-) With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Fedotov, Alexei A Sent: Friday, October 06, 2006 12:20 AM To: =SMTP:[EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org Subject: RE: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Hi, Nadya, I tried to build DRLVM, faced the issue from the thread below, and filed a JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1730. Does the patch worth to be applied to the README.txt? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Spark Shen [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 9:56 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Thank you, I am trying :-). 2006/9/22, Vladimir Gorr [EMAIL PROTECTED]: On 9/22/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. Sorry for the late reply. JIRA 1500 is due to discussion [1] on the dev mailing list. I can not build DRLVM on my desktop. (Windows XP, RI JDK1.5.0, ant 1.6.5). So I could not reproduce the bug The prompted error message is: C:\spark\drlvm\trunk\build\make\build.xml:238: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:289: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:291: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:462: Warning: Could not find file C:\spark\drlvm\trunk\build\make\no_settings_in_config_or_environment to copy. This is the first time I build DRLVM, would you give me some hint about this error message. It seems you didn't run the *build.bat update* before starting the build. We need to run the following steps (sorry if you're aware about this): - svn checkout classlib - svn checkout drlvm - build classlib (cd classlib/trunk; ant fetch-depend; ant) - cd drlvm/trunk/build - build.bat update (you need to slightly some time here :-) ) - build.bat Thanks, Vladimir. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony- dev/200609.mbox/[EMAIL PROTECTED] . com%3e Best regards Gang, it'd be not bad to run DRLVM testing for any commits to SVN repository. Otherwise we will be very hard to catch any errors like this. Any thoughts? Thanks, Vladimir. On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty ( UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java :2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace( UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle .init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for
Re: [classlib] enabling AWT/Swing by default
Oleg Khaschansky wrote: So what happens to the patch on HARMONY-1723. My opinion is that it is OK. Consider the following: 1. Applications bounded to the RI behavior (e.g. obtaining the descriptors for read-only properties without construction of getter name) won't fail. 2. Construction of the default getter/setter names could be incapsulated in the PropertyDescriptor. For now there's no possibility of getting a descriptor for one read-only/write-only property without constructing its getter/setter name outside of the PropertyDescriptor. 3. Don't think that it is bad if PropertyDescriptor would lookup for reasonable defaults if provided names are invalid. I'd like to hear another opinion. If somebody will disagree I'll make another fix for the TransferHandler, whithout touching beans. Me too -- I was following your logic above and agreed, but I got the impression that Alexey disagreed with that approach, so was holding off. I have the patch applied in my workspace but will wait before committing it. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] too tired, need help
seems like we got our patches in w/in 2 minutes of one another.
Take a look.
I'm going to bed.
I have a peace of mind now...
geir
Geir Magnusson Jr. wrote:
I have this almost done so that it uses the boot classpath generated by
luni. Only remaining peace is to add kernel.jar to it, and I'll do that
so it comes from the VMDIR - we wanted to move kernel.jar there anyway
for cleaner deployment.
I just couldn't stop... no mental peace. :)
Geir Magnusson Jr. wrote:
Alexey Varlamov wrote:
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure how it
gets to us...), and I'm too tired, too dumb, or both to figure this
out.
Geir,
To avoid possible duplication - there is HARMONY-1626 about smth very
similar, and I'm ready to submit a patch, just waiting for H-1582.
Ah - I was looking at this very JIRA. I didn't realize you were
working on it. PLease submit the patch now just so i can see it so i
can to to bed w/ a peaceful mind.
You can submit another after 1582 - also, please link to 1582
geir
Launcher calls JNI_CreateJavaVM. In our vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void
*vm_args) {
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be useless
here...
geir
-
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]
-
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]
Re: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
I was looking at the patch, and think we should just chuck the whole README.txt, salvage what's good, put it on the website, and put a pointer in the README.txt to the website. geir Morozova, Nadezhda wrote: Thanks for the fix, Alexei. I think this is a good start for updating the README. I've looked at the current version, and many other things are out-of-date (such as ij as the name of our executable). Some things are also duplicated - we now have the nice Quick Help pages for users [1] and developers [2]. As I see it, the Quick Start you've been referring to roughly matches [1], whereas [2] is for those who have to 'read this README and follow building instructions to the point.' :) I suggest that we edit the README file more to improve it. What do you think? Do you think we can use JIRA 1730 for these changes? [1] http://incubator.apache.org/harmony/quickhelp_users.html [2] http://incubator.apache.org/harmony/quickhelp_contributors.html Best regards, Nadya Morozova -Original Message- From: Fedotov, Alexei A Sent: Friday, October 06, 2006 12:23 AM To: Morozova, Nadezhda Cc: harmony-dev@incubator.apache.org Subject: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 BTW, I really enjoyed the last item of the Quick Start section: 7. If building the DRLVM fails, read this README and follow building instructions to the point. A hardcore programmer can loop infinitely here. :-) With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Fedotov, Alexei A Sent: Friday, October 06, 2006 12:20 AM To: =SMTP:[EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org Subject: RE: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Hi, Nadya, I tried to build DRLVM, faced the issue from the thread below, and filed a JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1730. Does the patch worth to be applied to the README.txt? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Spark Shen [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 9:56 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Thank you, I am trying :-). 2006/9/22, Vladimir Gorr [EMAIL PROTECTED]: On 9/22/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. Sorry for the late reply. JIRA 1500 is due to discussion [1] on the dev mailing list. I can not build DRLVM on my desktop. (Windows XP, RI JDK1.5.0, ant 1.6.5). So I could not reproduce the bug The prompted error message is: C:\spark\drlvm\trunk\build\make\build.xml:238: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:289: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:291: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:462: Warning: Could not find file C:\spark\drlvm\trunk\build\make\no_settings_in_config_or_environment to copy. This is the first time I build DRLVM, would you give me some hint about this error message. It seems you didn't run the *build.bat update* before starting the build. We need to run the following steps (sorry if you're aware about this): - svn checkout classlib - svn checkout drlvm - build classlib (cd classlib/trunk; ant fetch-depend; ant) - cd drlvm/trunk/build - build.bat update (you need to slightly some time here :-) ) - build.bat Thanks, Vladimir. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony- dev/200609.mbox/[EMAIL PROTECTED] . com%3e Best regards Gang, it'd be not bad to run DRLVM testing for any commits to SVN repository. Otherwise we will be very hard to catch any errors like this. Any thoughts? Thanks, Vladimir. On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty ( UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java :2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace( UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at
Re: [drlvm] too tired, need help
Oh, I'd had not such happy lunch time knowing about your torments ;(
I thought I indicated my intentions about this on the list and did'n
bother to state this in the JIRA.
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I have this almost done so that it uses the boot classpath generated by
luni. Only remaining peace is to add kernel.jar to it, and I'll do that
so it comes from the VMDIR - we wanted to move kernel.jar there anyway
for cleaner deployment.
I just couldn't stop... no mental peace. :)
Geir Magnusson Jr. wrote:
Alexey Varlamov wrote:
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure how it
gets to us...), and I'm too tired, too dumb, or both to figure this out.
Geir,
To avoid possible duplication - there is HARMONY-1626 about smth very
similar, and I'm ready to submit a patch, just waiting for H-1582.
Ah - I was looking at this very JIRA. I didn't realize you were working
on it. PLease submit the patch now just so i can see it so i can to to
bed w/ a peaceful mind.
You can submit another after 1582 - also, please link to 1582
geir
Launcher calls JNI_CreateJavaVM. In our vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void *vm_args) {
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be useless
here...
geir
-
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]
-
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]
Re: [drlvm] too tired, need help
not a worry - I learned a lot
Take a look at what I did and see if it's right :)
geir
Alexey Varlamov wrote:
Oh, I'd had not such happy lunch time knowing about your torments ;(
I thought I indicated my intentions about this on the list and did'n
bother to state this in the JIRA.
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I have this almost done so that it uses the boot classpath generated by
luni. Only remaining peace is to add kernel.jar to it, and I'll do that
so it comes from the VMDIR - we wanted to move kernel.jar there anyway
for cleaner deployment.
I just couldn't stop... no mental peace. :)
Geir Magnusson Jr. wrote:
Alexey Varlamov wrote:
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure how it
gets to us...), and I'm too tired, too dumb, or both to figure
this out.
Geir,
To avoid possible duplication - there is HARMONY-1626 about smth very
similar, and I'm ready to submit a patch, just waiting for H-1582.
Ah - I was looking at this very JIRA. I didn't realize you were
working
on it. PLease submit the patch now just so i can see it so i can to to
bed w/ a peaceful mind.
You can submit another after 1582 - also, please link to 1582
geir
Launcher calls JNI_CreateJavaVM. In our vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void
*vm_args) {
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be useless
here...
geir
-
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]
-
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]
RE: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
+1 PS: we have a pointer to README, but it goes into SVN. I don't see anything wrong with that - there should be some docs with sources. Best regards, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, October 06, 2006 1:18 PM To: harmony-dev@incubator.apache.org Subject: Re: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 I was looking at the patch, and think we should just chuck the whole README.txt, salvage what's good, put it on the website, and put a pointer in the README.txt to the website. geir Morozova, Nadezhda wrote: Thanks for the fix, Alexei. I think this is a good start for updating the README. I've looked at the current version, and many other things are out-of-date (such as ij as the name of our executable). Some things are also duplicated - we now have the nice Quick Help pages for users [1] and developers [2]. As I see it, the Quick Start you've been referring to roughly matches [1], whereas [2] is for those who have to 'read this README and follow building instructions to the point.' :) I suggest that we edit the README file more to improve it. What do you think? Do you think we can use JIRA 1730 for these changes? [1] http://incubator.apache.org/harmony/quickhelp_users.html [2] http://incubator.apache.org/harmony/quickhelp_contributors.html Best regards, Nadya Morozova -Original Message- From: Fedotov, Alexei A Sent: Friday, October 06, 2006 12:23 AM To: Morozova, Nadezhda Cc: harmony-dev@incubator.apache.org Subject: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 BTW, I really enjoyed the last item of the Quick Start section: 7. If building the DRLVM fails, read this README and follow building instructions to the point. A hardcore programmer can loop infinitely here. :-) With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Fedotov, Alexei A Sent: Friday, October 06, 2006 12:20 AM To: =SMTP:[EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org Subject: RE: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Hi, Nadya, I tried to build DRLVM, faced the issue from the thread below, and filed a JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1730. Does the patch worth to be applied to the README.txt? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Spark Shen [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 9:56 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Thank you, I am trying :-). 2006/9/22, Vladimir Gorr [EMAIL PROTECTED]: On 9/22/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. Sorry for the late reply. JIRA 1500 is due to discussion [1] on the dev mailing list. I can not build DRLVM on my desktop. (Windows XP, RI JDK1.5.0, ant 1.6.5). So I could not reproduce the bug The prompted error message is: C:\spark\drlvm\trunk\build\make\build.xml:238: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:289: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:291: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:462: Warning: Could not find file C:\spark\drlvm\trunk\build\make\no_settings_in_config_or_environment to copy. This is the first time I build DRLVM, would you give me some hint about this error message. It seems you didn't run the *build.bat update* before starting the build. We need to run the following steps (sorry if you're aware about this): - svn checkout classlib - svn checkout drlvm - build classlib (cd classlib/trunk; ant fetch-depend; ant) - cd drlvm/trunk/build - build.bat update (you need to slightly some time here :-) ) - build.bat Thanks, Vladimir. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony- dev/200609.mbox/[EMAIL PROTECTED] . com%3e Best regards Gang, it'd be not bad to run DRLVM testing for any commits to SVN repository. Otherwise we will be very hard to catch any errors like this. Any thoughts? Thanks, Vladimir. On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException
Re: Wonka, Mika, and Apache
On Friday 06 October 2006 09:29, Geir Magnusson Jr. wrote: Who owns the copyright and can therefore make the donation? Copyright in the original Wonka code belonged to Acunia, and hence now belongs to Punch Telematix; there were also a few small contributions from outsiders whom I'm fairly confident I can track down. Copyright in all changes since late 2003 belong to me or to a company called Proveo, who should also be willing to contribute their stuff (I'm writing to them now). Do you require the same docucmentation to be completed by all authors, or is there a distinction between main and subsidiary contributors? Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HARMONY-1317) [classlib][internationalization]Internationalization of the rmi module
On 10/6/06, Mark Hindess [EMAIL PROTECTED] wrote: On 6 October 2006 at 9:57, Tim Ellison [EMAIL PROTECTED] wrote: Mark beat me to it, so you are in good hands. And slightly regretting it... it's a big patch and one that's worth being careful with ... mixing up messages would be very confusing. It is interesting to note that many of the messages are for logging and output to the console. When it comes to some of the other big modules you could do it incrementally, i.e. submit patches that migrate packages to the new framework; they should work fine in parallel during the transition. Agreed. That might make it easier to check the patches too. Also agree with you guys. Last modules (except misc and tools) have huge number of messages and it is a real help to have a number of patches instead of one(e.g devided by packages). It is easier for committers and for developers as well. However there is messages.properties file, that is common for all these patches. Applying this file for every sub-patch I suppose will rise snv conflict. Committers who are going to apply these patches should take this into account and be ready to resolve such conflicts every time:) Keep up the good work. Yes. These must be even more painful to generate than they are too read. Many thanks for doing this. I've spotted a couple of minor issues reading the patch[0] but I'll probably submit it as is unless I spot anything serious and fix them in a later commit. Mark, good catch! I fixed some of these minor issues during preparing this patch, unfortunately there left few of them I'd missed. Regards, Ilya. Regards, Mark. [0] Such as rmi.log.8D which is only used in an exception not a logging call. I wouldn't want this to break if/when Tim removes the logging. Ilya Okomin wrote: Hi committers! Could someone look into the patch with [rmi] internationalization HARMONY-1317? Patch affects many source files and it would be great to apply it ASAP (if it is OK of course:)) to avoid conflicts with another changes in the Harmony svn. Thanks, Ilya. On 10/4/06, Ilya Okomin (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-1317?page=all ] Ilya Okomin updated HARMONY-1317: - Attachment: rmi.diff Wow, it was really hard work! Please try this patch. [classlib][internationalization]Internationalization of the rmi module -- Key: HARMONY-1317 URL: http://issues.apache.org/jira/browse/HARMONY-1317 Project: Harmony Issue Type: Sub-task Components: Classlib Reporter: Ilya Okomin Priority: Trivial Attachments: rmi.diff [rmi] module should be internationalized with the scheme suggested in HARMONY-1308 issue [1]. [1] http://issues.apache.org/jira/browse/HARMONY-1308 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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] -- -- Ilya Okomin Intel Middleware Products Division
SPECjbb2005 fails in debug mode
Hi guys, I obtained an assertion failure in EdgeProfiler.cpp:408 on IA32/Windows/SPECjbb2005 with the attached config file. Seems like not complicated bug. Nikolay A. Sidelnikov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
On 10/5/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Ivan, could this enumeration scenario be possible? 1) JIT reports a base to GC 2) GC relocates the base and updates references. 3) JIT reports MPTR, looks for the base, founds the patched base on the stack and the resulting offset becomes invalid? The previous GC (gcv4) did not relocate object during the enumeration process. If gcv4.1 does this is the reason of the problem. ? I see. Here is the problem. The reason of the behaviour was: Root set size can be quite large on some workloads. It can consume a lot of memory if would keep it. Why don't we update roots just when it was reported? Thus we don't need to keep large array of roots and it can also have positive influence on d-cache utilization (need to proof this). There is a command line switch: -Dgc.remember_root_set=true which will cause GC to retrieve root set before any operations on heap. -- Ivan 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]
Re: SPECjbb2005 fails in debug mode
Hi Nikolay, The patch for this bug is in http://issues.apache.org/jira/browse/HARMONY-1689 The current version of edge profiler can really lead to a crush in server mode. On 10/6/06, Sidelnikov, Nikolay A [EMAIL PROTECTED] wrote: Hi guys, I obtained an assertion failure in EdgeProfiler.cpp:408 on IA32/Windows/SPECjbb2005 with the attached config file. Seems like not complicated bug. Nikolay A. Sidelnikov - 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
Re: [drlvm] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
Ivan, the problem is described in the example in H1682, I can add it to the email thread to invite other GC/JIT gurus to participate in the discussion. The example: JIT has 2 references to report. Both of them point to the same object. JIT expects that both references are updated when GC moves object. 1) JIT reports reference 1 2) GC moves object and updates reference 1. 3) JIT reports reference 2, but the reference points to the old place where the object was. This is almost the same situation we have today. On 10/6/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Why don't we update roots just when it was reported? Thus we don't need to keep large array of roots and it can also have positive influence on d-cache utilization (need to proof this). -- Mikhail Fursov
[drlvm] passing extra options to vm fails on Widows XP
I failed to run any application with -Xem:jet (and -Xem:opt as well) set in harmonyvm.properties on my Windows XP while I succeeded on Windows 2003. I even copied that file from Windows 2003 machine to XP machine but this did not help. java Test gives me the following: An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 ExceptionCode=c005 ExceptionAddress=004020DF ContextFlags=0001003f Handler1=00401010 Handler2=11105CE0 InaccessibleAddress=0550 EDI= ESI=001531F0 EAX= EBX= ECX=004044F4 EDX=4C25 EIP=004020DF ESP=0013F970 EBP=0550 Module=C:\users\esemukhi\svn1\drlvm\trunk\build\deploy\jre\bin\java.exe Module_base_address=0040 Offset_in_DLL=20df This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. -- Thanks, Elena
Re: [drlvm] passing extra options to vm fails on Widows XP
I'm glad I do not update classlib files more then once per day and do it almost every hour for drlvm only. So if you do not need the latest changes from classlib you can try to take an older version: This one is about 16 hour old and worked for me yesterday: svn update -r 453209 On 10/6/06, Elena Semukhina [EMAIL PROTECTED] wrote: I failed to run any application with -Xem:jet (and -Xem:opt as well) set in harmonyvm.properties on my Windows XP while I succeeded on Windows 2003. I even copied that file from Windows 2003 machine to XP machine but this did not help. java Test gives me the following: An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 ExceptionCode=c005 ExceptionAddress=004020DF ContextFlags=0001003f Handler1=00401010 Handler2=11105CE0 InaccessibleAddress=0550 EDI= ESI=001531F0 EAX= EBX= ECX=004044F4 EDX=4C25 EIP=004020DF ESP=0013F970 EBP=0550 Module=C:\users\esemukhi\svn1\drlvm\trunk\build\deploy\jre\bin\java.exe Module_base_address=0040 Offset_in_DLL=20df This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. -- Thanks, Elena -- Mikhail Fursov
Re: [drlvm] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
This is not the same. In your example, if the second reference points to previous position of object it will be automatically updated according to installed forwarding pointer. We have different problem. The reported offset within object is incorrect, as the base is taken from new location of object, but interior pointer points to old object location. Here is algorithm. before GC: *interior_pointer == base + offset after GC: *interior_pointer_updated == new_base + offset Reported offset should be: offset = *interior_pointer - base; But we have: offset' = *interior_pointer - new_base; After GC interior_pointer should be updated: *interior_pointer_updated = new_base + offset But in our case it will be: *interiour_pointer_updated' = new_base + offset' = new_base + *interior_pointer - new_base = *interior_pointer So, interior_pointer will not be updated. -- Ivan On 10/6/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Ivan, the problem is described in the example in H1682, I can add it to the email thread to invite other GC/JIT gurus to participate in the discussion. The example: JIT has 2 references to report. Both of them point to the same object. JIT expects that both references are updated when GC moves object. 1) JIT reports reference 1 2) GC moves object and updates reference 1. 3) JIT reports reference 2, but the reference points to the old place where the object was. This is almost the same situation we have today. On 10/6/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Why don't we update roots just when it was reported? Thus we don't need to keep large array of roots and it can also have positive influence on d-cache utilization (need to proof this). -- 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]
Re: [classlib][test] Site to collect classlib test statistics
Alexey, I've added both options - search by test name and list of tests that ever failed. The second one is very big because of results you've uploaded for DRLVM/Linux with 554 errors. Please tell me if you want to change anything in the interface. On 10/6/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Anton, Many thanks for exploring this area, it looks quite promising. An idea: this service would become more valuable if presented transparent search/comparison of results for particular tests over all uploaded runs. Let user enter name of a test and show in one table all known results for this test, or even better, provide a table of all ever failed tests with links to individual consolidated tables. This would help analyzing failures very much. -- Regards, Alexey 2006/10/4, Anton Luht [EMAIL PROTECTED]: Hello, Could you tell about it in more detail? 1) Who can upload test results? Everyone - no authorization is needed, you can include file upload to your regular builds if you want - authorized users can remove them later if something goes wrong :) If you want to modify uploaded tests' data - add JIRA issues to failures, add comments, etc - please send me login/password and I'll create an account. 2) How are you going to develop this site, structure, data base and etc.? I'll try to implement all feature requests that community members will express. One of possible directions I see is support for new test suites - currently it recognises only Harmony classlib JUnit tests output. If you have another test suite you want to upload to that site - just send me an archive and I'll try to add support for this kind of tests. Sources of that app are not in SVN now - if you want to review/fix/improve something - I can send you an archive. -- Regards, Anton Luht, 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] -- Regards, Anton Luht, 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]
Re: [drlvm][jet] Could you please look into HARMONY-1678?
Egor, I've marked this bug with 'minor' priority because it didn't affect any known application and didn't cause crash. Seems that Alexey struggles for absence of JUnit tests failures because of DRLVM bugs, that's why he promoted the bug. P.S. you are promoting a low-priority bug while there are a lot of critical crashes flying around. Is it marked as Minor by mistake? -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Anton Luht, 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]
Re: [classlib][test] Site to collect classlib test statistics
Thanks for prompt response! Those 554 errors on interpreter are due to fork mode=once, it is a single error affecting the whole run. Is there a way to delete an uploaded run? Better yet, to be able select a range of runs to include to analysis. The appetite comes with eating :) Criteria to select can vary, one of many possible is execution engine - it would be nice to have such characteristic of a run ... 2006/10/6, Anton Luht [EMAIL PROTECTED]: Alexey, I've added both options - search by test name and list of tests that ever failed. The second one is very big because of results you've uploaded for DRLVM/Linux with 554 errors. Please tell me if you want to change anything in the interface. On 10/6/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Anton, Many thanks for exploring this area, it looks quite promising. An idea: this service would become more valuable if presented transparent search/comparison of results for particular tests over all uploaded runs. Let user enter name of a test and show in one table all known results for this test, or even better, provide a table of all ever failed tests with links to individual consolidated tables. This would help analyzing failures very much. -- Regards, Alexey 2006/10/4, Anton Luht [EMAIL PROTECTED]: Hello, Could you tell about it in more detail? 1) Who can upload test results? Everyone - no authorization is needed, you can include file upload to your regular builds if you want - authorized users can remove them later if something goes wrong :) If you want to modify uploaded tests' data - add JIRA issues to failures, add comments, etc - please send me login/password and I'll create an account. 2) How are you going to develop this site, structure, data base and etc.? I'll try to implement all feature requests that community members will express. One of possible directions I see is support for new test suites - currently it recognises only Harmony classlib JUnit tests output. If you have another test suite you want to upload to that site - just send me an archive and I'll try to add support for this kind of tests. Sources of that app are not in SVN now - if you want to review/fix/improve something - I can send you an archive. -- Regards, Anton Luht, 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] -- Regards, Anton Luht, 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]
Re: [classlib] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/d
Hi Oleg,
On the other hand, why don't we allow Harmony to accept invalid names
and provide a default replacements for them if there is a set/get/is
method for the specified property? It seems to me more user-friendly
then throw IntrospectionException in this situation. It looks like the
specification doesn't require PropertyDescriptor to throw an exception
in this case.
Well, the specification states here:
==
public PropertyDescriptor(String propertyName,
Class? beanClass,
String readMethodName,
String writeMethodName)
throws IntrospectionException
...
Parameters:
...
readMethodName - The name of the method used for reading the
property value. May be null if the property is write-only.
writeMethodName - The name of the method used for writing the
property value. May be null if the property is read-only.
Throws:
IntrospectionException - if an exception occurs during introspection.
==
So we have the description of the valid parameter case, null parameter
case and the exception that can be thrown. IMHO the natural conclusion
from that is that the exception will be thrown in case of invalid
parameter. Moreover, if the implementation does not validate method
names it will never throw IntrospectionException. But it is described
by the spec.
BTW, PropertyDescriptor(String, Method, Method) validates both methods
and throws IntrospectionException if something is wrong.
This will also prevent us from breaking applications
that uses this RI behavior.
Actually I don't belive they exist in our world. :) May be we can
leave the current functionality for now and get back to this if
encounter one of such apps?
Regards,
2006/10/5, Oleg Khaschansky [EMAIL PROTECTED]:
Alexey,
Agree. I haven't noticed that RI doesn't accept invalid write method.
Then its behavior looks illogical. Actually, I asked about comments
especially because I expected a feedback from beans authors. Thank
you.
On the other hand, why don't we allow Harmony to accept invalid names
and provide a default replacements for them if there is a set/get/is
method for the specified property? It seems to me more user-friendly
then throw IntrospectionException in this situation. It looks like the
specification doesn't require PropertyDescriptor to throw an exception
in this case. This will also prevent us from breaking applications
that uses this RI behavior.
What is your opinion?
On 10/5/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Oleg,
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with a patch for the both issues?
I've already written my thoughts about this issue in [1]. In short: I
don't think we should follow the RI behavior since it is inconsistent.
Why it accepts invalid read method and throws exception on invalid
write method? No logic.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL
PROTECTED]
Thanks,
2006/10/4, Oleg Khaschansky [EMAIL PROTECTED]:
I found the reason of this failure. It is an IntrospectionException
while executing a following method from the TransferHandler class:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
return result;
}
It tries to get the PropertyDescriptor for the class JButton and
property name insets, but fails because there's no setInsets method.
So, flavors array stays uninitialized and getTransferDataFlavors
method returns null which is a cause of a NPE.
The quick fix for this issue could be changing this method to the following:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
return result = new PropertyDescriptor(propertyName,
c.getClass());
} catch (IntrospectionException e) {
}
try {
return result = new PropertyDescriptor(propertyName,
c.getClass(), 1, null);
} catch (IntrospectionException e) {
}
return result;
}
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with a patch for the both issues?
Thanks,
Oleg
On 10/4/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/10/4, Mark Hindess [EMAIL PROTECTED]:
On 4 October 2006
Re: [drlvm] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
Ivan, I'm agree that the problem we have is more complicated then my example. And I'm glad to hear that there are no problem with the scenario from my example today. Jitrino.OPT uses 3 interface methods to report GC root set: 1. VMEXPORT void vm_enumerate_root_reference(Managed_Object_Handle *ref, Boolean is_pinned); 2. VMEXPORT void vm_enumerate_root_interior_pointer(void **slot, int offset, Boolean is_pinned); 3. VMEXPORT void vm_enumerate_root_interior_pointer_with_base(void **slot_root, void **slot_base, Boolean is_pinned); The method 1 is used for bases The method 2 is used for mptrs with offset known at compilation time The method 3 is used for mptrs with dynamic offset that is computed only in runtime In our case JIT reports the pair: new_base and old_mptr. JIT does not report offset here. So if you could process this situation with 'forwarding' pointer we have the half of the problem solved. The other half of the problem is finding a base for the mptr with unknown offset. The current implementation in JIT looks for a base right before reporting the mptr: it selects the nearest one. So if base pointer was updated by GC the search will produce incorrect results. I see the following solutions in our problem 1) Fix in GC and JIT: GC is learned how to deal with mptrs reported with outdated base + fix in JIT in base searching algorithm (here we have a lot of variants) 2) Fix in JIT only: precache all offsets and then report. In this case JIT will always use only method1 and method2. I vote for the item 2 and can provide a fix in a day. But in this case I propose to remove the method3 from GC-JIT interface at all, as deprecated. On 10/6/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: This is not the same. In your example, if the second reference points to previous position of object it will be automatically updated according to installed forwarding pointer. We have different problem. The reported offset within object is incorrect, as the base is taken from new location of object, but interior pointer points to old object location. Here is algorithm. before GC: *interior_pointer == base + offset after GC: *interior_pointer_updated == new_base + offset Reported offset should be: offset = *interior_pointer - base; But we have: offset' = *interior_pointer - new_base; After GC interior_pointer should be updated: *interior_pointer_updated = new_base + offset But in our case it will be: *interiour_pointer_updated' = new_base + offset' = new_base + *interior_pointer - new_base = *interior_pointer So, interior_pointer will not be updated. -- Ivan On 10/6/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Ivan, the problem is described in the example in H1682, I can add it to the email thread to invite other GC/JIT gurus to participate in the discussion. The example: JIT has 2 references to report. Both of them point to the same object. JIT expects that both references are updated when GC moves object. 1) JIT reports reference 1 2) GC moves object and updates reference 1. 3) JIT reports reference 2, but the reference points to the old place where the object was. This is almost the same situation we have today. On 10/6/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Why don't we update roots just when it was reported? Thus we don't need to keep large array of roots and it can also have positive influence on d-cache utilization (need to proof this). -- 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] -- Mikhail Fursov
Re: [classlib] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/d
Ok. I am testing another patch for the TransferHandler which won't affect beans.
On 10/6/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Hi Oleg,
On the other hand, why don't we allow Harmony to accept invalid names
and provide a default replacements for them if there is a set/get/is
method for the specified property? It seems to me more user-friendly
then throw IntrospectionException in this situation. It looks like the
specification doesn't require PropertyDescriptor to throw an exception
in this case.
Well, the specification states here:
==
public PropertyDescriptor(String propertyName,
Class? beanClass,
String readMethodName,
String writeMethodName)
throws IntrospectionException
...
Parameters:
...
readMethodName - The name of the method used for reading the
property value. May be null if the property is write-only.
writeMethodName - The name of the method used for writing the
property value. May be null if the property is read-only.
Throws:
IntrospectionException - if an exception occurs during introspection.
==
So we have the description of the valid parameter case, null parameter
case and the exception that can be thrown. IMHO the natural conclusion
from that is that the exception will be thrown in case of invalid
parameter. Moreover, if the implementation does not validate method
names it will never throw IntrospectionException. But it is described
by the spec.
BTW, PropertyDescriptor(String, Method, Method) validates both methods
and throws IntrospectionException if something is wrong.
This will also prevent us from breaking applications
that uses this RI behavior.
Actually I don't belive they exist in our world. :) May be we can
leave the current functionality for now and get back to this if
encounter one of such apps?
Regards,
2006/10/5, Oleg Khaschansky [EMAIL PROTECTED]:
Alexey,
Agree. I haven't noticed that RI doesn't accept invalid write method.
Then its behavior looks illogical. Actually, I asked about comments
especially because I expected a feedback from beans authors. Thank
you.
On the other hand, why don't we allow Harmony to accept invalid names
and provide a default replacements for them if there is a set/get/is
method for the specified property? It seems to me more user-friendly
then throw IntrospectionException in this situation. It looks like the
specification doesn't require PropertyDescriptor to throw an exception
in this case. This will also prevent us from breaking applications
that uses this RI behavior.
What is your opinion?
On 10/5/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Oleg,
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with a patch for the both
issues?
I've already written my thoughts about this issue in [1]. In short: I
don't think we should follow the RI behavior since it is inconsistent.
Why it accepts invalid read method and throws exception on invalid
write method? No logic.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL
PROTECTED]
Thanks,
2006/10/4, Oleg Khaschansky [EMAIL PROTECTED]:
I found the reason of this failure. It is an IntrospectionException
while executing a following method from the TransferHandler class:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
return result;
}
It tries to get the PropertyDescriptor for the class JButton and
property name insets, but fails because there's no setInsets method.
So, flavors array stays uninitialized and getTransferDataFlavors
method returns null which is a cause of a NPE.
The quick fix for this issue could be changing this method to the
following:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
return result = new PropertyDescriptor(propertyName,
c.getClass());
} catch (IntrospectionException e) {
}
try {
return result = new PropertyDescriptor(propertyName,
c.getClass(), 1, null);
} catch (IntrospectionException e) {
}
return result;
}
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any
Re: [classlib][test] Site to collect classlib test statistics
Hello, Those 554 errors on interpreter are due to fork mode=once, it is a single error affecting the whole run. Is there a way to delete an uploaded run? I've added a possibility to delete run for a registered user. Please send me login/password if you want to have such possibility. Better yet, to be able select a range of runs to include to analysis. The appetite comes with eating :) Criteria to select can vary, one of many possible is execution engine - it would be nice to have such characteristic of a run ... The latest Web 2.0 fashion trend is to use tags for this (same as keywords in Bugzilla) :) Will it do for you if tags support is implemented? Examples of tags I can can think of are: msvc, gcc, Linux, Windows, SP2, RedHat, Single_Core, Multi_Core, etc. We can have an editable list to avoid typos but to be able to add new tags easily. Alexey, I've added both options - search by test name and list of tests that ever failed. The second one is very big because of results you've uploaded for DRLVM/Linux with 554 errors. Please tell me if you want to change anything in the interface. On 10/6/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Anton, Many thanks for exploring this area, it looks quite promising. An idea: this service would become more valuable if presented transparent search/comparison of results for particular tests over all uploaded runs. Let user enter name of a test and show in one table all known results for this test, or even better, provide a table of all ever failed tests with links to individual consolidated tables. This would help analyzing failures very much. -- Regards, Alexey 2006/10/4, Anton Luht [EMAIL PROTECTED]: Hello, Could you tell about it in more detail? 1) Who can upload test results? Everyone - no authorization is needed, you can include file upload to your regular builds if you want - authorized users can remove them later if something goes wrong :) If you want to modify uploaded tests' data - add JIRA issues to failures, add comments, etc - please send me login/password and I'll create an account. 2) How are you going to develop this site, structure, data base and etc.? I'll try to implement all feature requests that community members will express. One of possible directions I see is support for new test suites - currently it recognises only Harmony classlib JUnit tests output. If you have another test suite you want to upload to that site - just send me an archive and I'll try to add support for this kind of tests. Sources of that app are not in SVN now - if you want to review/fix/improve something - I can send you an archive. -- Regards, Anton Luht, 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] -- Regards, Anton Luht, 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] -- Regards, Anton Luht, 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]
Re: [drlvm][gc/threading] need the two lsb's from object header for MMTk port
Weldon, All
Here is the updated vm/vmcore/sync_bit.h header file.
That, I think, describes current state of the object header.
I olso try define rules: How to update the header correctly.
Welcome to discussion on them.
#ifndef _sync_bits_H
#define _sync_bits_H
/**
* These defines describe the current state of the object header (object_info)
* (the second DWORD of any java object)
*
* Here is except form the object_layout.h:
* typedef struct ManagedObjectCompressedVtablePtr {
uint32 vt_offset;
uint32 obj_info;
*
* The obj_info(also known as obj_header, lockword) is mostly used
for java monitor implementation (22bit) in ThreadManager. The other 10
bits could be shared among other components.
* At this time, the vmcore uses 6 bits to store hash code, and GC
uses some bits for marking purposes.
*
* Because there are 3 component that share the same DWORD.
* Here is a rules for this header usage.
*
* Rationale:
* The monitor implementation uses CAS32 (lock cmpxcg) to set the LOCK_ID bits.
* (acquires lock). if LOCK_ID is equals THREAD_ID of the current thread,
* the dword is updated with regular store command (for example in
monitor exit)
* So to update the other header bits carefully anyone should follows
next rules:
*
* 1. All updates should be done in hythread_suspend_disable().
* Elsewhere the GC could move the object while you are preparing for
* writing.
* 2. It is safe to update the field in there stop_the_world_fase of GC
* (after hythread_suspend_all_threads() call). No one else
actives at that point.
* 3. It is safe to update, if the thread is the owner of the object monitor
*hythread_thin_monitor_get_owner(header_ptr) == hythread_self().
* 3a. The monitor owner could be suspended or monitor could be
acquired, before the update in case of 3.
* 4. If the monitor have been inflated to fat monitor,
*hythread will not update the header. So you could update it.
*is_fat_monitor(*header_ptr) == TRUE.
*
* 5. in case of 3 or 4, it is recommended to use CAS, because more
then one thread could still update the header.
* 6. if THREAD_ID==0, the monitor is not owned or reserved, CAS
should be used to update data.
*
*
*/
// the TM monitor implementation bits.
// 1100
#define LOCKWORD_MASK (0x ^ 0x3FF)
// THREAD_ID
#define THREAD_ID_MASK (0x)
// 6bit default hashcode
// 0110
// custom hashcode algorithm could free these bits
#define HASH_MASK 0x7e
// free bits for GC usage
// 0011 1001
#define GC_BIT_MASK (0x ^ (LOCKWORD_MASK | HASH_MASK))
Thanks
Artem
On 10/6/06, Weldon Washburn [EMAIL PROTECTED] wrote:
From reading current svn HEAD, it looks like thread_native_thin_monitor.c
reserves the bottom 10 bits of the object's lock word for object hashcode.
If this is true, I'd like to take the bottom two bits for MMTk port. Please
tell me what #defines I need to change to make this happen.
Thanks
--
Weldon Washburn
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]
RE: [classlib][test] Site to collect classlib test statistics
Alexey, Thank you for your response. As I understood I'm working on the same problem, I write scripts to run different tests(cunit, classlib, smoke, kernel, specjvm98) and collect statistics. I do it to track patch which was reason of failure of any test. So bug propagation would be stopped. The final result is presented like table with name and state (passed/failed). My next step was to use mysql database, php and Apache server to make my system user-friendly. Also I need to think out algorithm to find guilty revision. Now I run tests only on Windows and only on my machine. I think it's a good idea to keep in touch and collaborate! It's useful to have this system on Harmony, because each contributor can see how his patch effect the virtual machine!!! With best regards, Vera! -Original Message- From: Alexey Varlamov [mailto:[EMAIL PROTECTED] Sent: Friday, October 06, 2006 4:14 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][test] Site to collect classlib test statistics Thanks for prompt response! Those 554 errors on interpreter are due to fork mode=once, it is a single error affecting the whole run. Is there a way to delete an uploaded run? Better yet, to be able select a range of runs to include to analysis. The appetite comes with eating :) Criteria to select can vary, one of many possible is execution engine - it would be nice to have such characteristic of a run ... 2006/10/6, Anton Luht [EMAIL PROTECTED]: Alexey, I've added both options - search by test name and list of tests that ever failed. The second one is very big because of results you've uploaded for DRLVM/Linux with 554 errors. Please tell me if you want to change anything in the interface. On 10/6/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Anton, Many thanks for exploring this area, it looks quite promising. An idea: this service would become more valuable if presented transparent search/comparison of results for particular tests over all uploaded runs. Let user enter name of a test and show in one table all known results for this test, or even better, provide a table of all ever failed tests with links to individual consolidated tables. This would help analyzing failures very much. -- Regards, Alexey 2006/10/4, Anton Luht [EMAIL PROTECTED]: Hello, Could you tell about it in more detail? 1) Who can upload test results? Everyone - no authorization is needed, you can include file upload to your regular builds if you want - authorized users can remove them later if something goes wrong :) If you want to modify uploaded tests' data - add JIRA issues to failures, add comments, etc - please send me login/password and I'll create an account. 2) How are you going to develop this site, structure, data base and etc.? I'll try to implement all feature requests that community members will express. One of possible directions I see is support for new test suites - currently it recognises only Harmony classlib JUnit tests output. If you have another test suite you want to upload to that site - just send me an archive and I'll try to add support for this kind of tests. Sources of that app are not in SVN now - if you want to review/fix/improve something - I can send you an archive. -- Regards, Anton Luht, 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] -- Regards, Anton Luht, 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]
Re: [drlvm] too tired, need help
Ok - I'll grab your -Xbootclasspath stuff...
Alexey Varlamov wrote:
(Cross-posted from JIRA):
OK, we should combine both patches. The
-Dorg.apache.harmony.vm.vmdir= of yours is logical continuation
towards multiVM-WS feature. And my patch more correctly handles
-Xbootclasspath[/ap]: options.
Will refresh patch after 1582 if your mind is easy now :)
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
not a worry - I learned a lot
Take a look at what I did and see if it's right :)
geir
Alexey Varlamov wrote:
Oh, I'd had not such happy lunch time knowing about your torments ;(
I thought I indicated my intentions about this on the list and did'n
bother to state this in the JIRA.
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I have this almost done so that it uses the boot classpath
generated by
luni. Only remaining peace is to add kernel.jar to it, and I'll do
that
so it comes from the VMDIR - we wanted to move kernel.jar there anyway
for cleaner deployment.
I just couldn't stop... no mental peace. :)
Geir Magnusson Jr. wrote:
Alexey Varlamov wrote:
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure
how it
gets to us...), and I'm too tired, too dumb, or both to figure
this out.
Geir,
To avoid possible duplication - there is HARMONY-1626 about smth
very
similar, and I'm ready to submit a patch, just waiting for H-1582.
Ah - I was looking at this very JIRA. I didn't realize you were
working
on it. PLease submit the patch now just so i can see it so i can
to to
bed w/ a peaceful mind.
You can submit another after 1582 - also, please link to 1582
geir
Launcher calls JNI_CreateJavaVM. In our
vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void
*vm_args) {
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined
or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be
useless
here...
geir
-
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]
-
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]
-
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]
Re: Wonka, Mika, and Apache
Chris Gray wrote: On Friday 06 October 2006 09:29, Geir Magnusson Jr. wrote: Who owns the copyright and can therefore make the donation? Copyright in the original Wonka code belonged to Acunia, and hence now belongs to Punch Telematix; there were also a few small contributions from outsiders whom I'm fairly confident I can track down. Copyright in all changes since late 2003 belong to me or to a company called Proveo, who should also be willing to contribute their stuff (I'm writing to them now). Do you require the same docucmentation to be completed by all authors, or is there a distinction between main and subsidiary contributors? There really is no distinction in our process. I could easily be argued that someone who offered a change that was entirely a derivative work (say offering a patch that made a post-decrement a pre-decrement) doesn't need one, but we're really trying to stay out of the situation where we'd have to argue anything with anyone :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] passing extra options to vm fails on Widows XP
joke What did the application's support team say? /joke? Elena Semukhina wrote: I failed to run any application with -Xem:jet (and -Xem:opt as well) set in harmonyvm.properties on my Windows XP while I succeeded on Windows 2003. I even copied that file from Windows 2003 machine to XP machine but this did not help. java Test gives me the following: An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 ExceptionCode=c005 ExceptionAddress=004020DF ContextFlags=0001003f Handler1=00401010 Handler2=11105CE0 InaccessibleAddress=0550 EDI= ESI=001531F0 EAX= EBX= ECX=004044F4 EDX=4C25 EIP=004020DF ESP=0013F970 EBP=0550 Module=C:\users\esemukhi\svn1\drlvm\trunk\build\deploy\jre\bin\java.exe Module_base_address=0040 Offset_in_DLL=20df This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][build]Stale object files are linked to DRLVM
Salikh Zakirov wrote:
Currently DRLVM build system suffers from a deficiency,
which gets in the way quickly if you experiment a lot with patches.
If you apply a patch that creates a new file, and build DRLVM, and
then unapply the patch, and rebuild again,
the stale .obj file will still get linked to the executable.
Usually, this leads to the spurios linker errors.
Can anyone with Ant/DRLVM build system experience propose a solution?
I've spent some time reading Ant manual in all conceivable directions,
trying to make ant remove stale .obj files, i.e. .obj files
that do not have corresponding .cpp file anymore.
The only thing I could come up with was something like
delete
fileset dir=. includes=*.obj
none
present targetdir=vm/vmcore/src present=both
mapper type=glob from=*.obj to=*.cpp/
/present
present targetdir=vm/vmcore/src/class_support present=both
mapper type=glob from=*.obj to=*.cpp/
/present
...
/none
/fileset
/delete
To make this operation clean up stale.obj files, one would
need to list all directories, where .cpp files come from. And there exist .c
and .asm files too.
So, it looks vastly impractical.
Too bad Ant doesn't allow to make operations with filesets, like add, subtract,
intersect, map, etc.
There always is an option to make a custom Ant task, e.g.
for creating a new fileset from existing filesets and a mapper,
or for subtracting filesets, but I would not go that way
until I know for sure there is no others.
Dreaming for a moment, if the following construct was possible in Ant,
fileset id=sources ... /fileset
fileset id=objects
transform filesetref=sources
chainedmapper
flattenmapper/
globmapper from=*.cpp to=${objdir}/*.obj/
/chainedmapper
/transform
/fileset
then the original problem would have been solved by using this objects
fileset in the link task.
Geir replied:
make?
I know you are teasing (^_-)
I can easily propose a couple of ways to use make
for building DRLVM (i.e. running C++ compiler and linker). The last thing I
played
with was using shell-script for generating Makefiles using the source file list.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] enabling AWT/Swing by default
Tim, I attached a patch which doesn't have side effects to HARMONY-1723 :) -- Oleg On 10/6/06, Tim Ellison [EMAIL PROTECTED] wrote: Oleg Khaschansky wrote: So what happens to the patch on HARMONY-1723. My opinion is that it is OK. Consider the following: 1. Applications bounded to the RI behavior (e.g. obtaining the descriptors for read-only properties without construction of getter name) won't fail. 2. Construction of the default getter/setter names could be incapsulated in the PropertyDescriptor. For now there's no possibility of getting a descriptor for one read-only/write-only property without constructing its getter/setter name outside of the PropertyDescriptor. 3. Don't think that it is bad if PropertyDescriptor would lookup for reasonable defaults if provided names are invalid. I'd like to hear another opinion. If somebody will disagree I'll make another fix for the TransferHandler, whithout touching beans. Me too -- I was following your logic above and agreed, but I got the impression that Alexey disagreed with that approach, so was holding off. I have the patch applied in my workspace but will wait before committing it. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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]
[DRLVM][GC] first generational version of GCv5 is submitted
The submitted revision is downloadable in JIRA-1428 at:
http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip
Attached in this email is the gc.xml file I am using that replaces
existing one for building gc.
Below is the submission description:
Attached file gcv5-r0.10.zip is first version of the generational
mark-compaction GC for GCv5, which combines previous two submitted
collectors as planned. That is, a trace-forward collector for minor
collection and a mark-compaction collector for major collection. An
additon of a copying algorithm is also developed that copies nursery
live objects to mature space during a major collection.
This revision has subtantial improvement in threading part. Although
it's still single threaded collector, the framework for multithreading
is ready. Basically, it has mutators and collectors to model the
application threads and collection threads.
A major design concept in this revision that was not made very clear
in previous submissions is space. GC is a concept of a full (or
standalone) garbage collector design. One GC can have multiple spaces,
each of which can employ different collection policy. With this
design idea in mind, the previous trace-forward GC is adapted to be
the collection policy for the nursery space, and the mark-compaction
GC is adapted to be the collection policy of the mature space.
As an embodiment of the design idea, GCv5 eliminates the global gc
variable in existing Harmony GC, and different space managements only
need to know a general gc data structure, instead of the generational
gc structure.
This revision has been tested on Windows with SPECJVM98. As the first
actual generational GC, any comments (or questions) are welcome!
-xiaofeng
[DRLVM] first batch of files for GCv5, a trace-forward copying collector
Key: HARMONY-1428
URL: http://issues.apache.org/jira/browse/HARMONY-1428
Project: Harmony
Issue Type: Improvement
Components: DRLVM
Environment: These files were only tested on Windows with VS.NET 2003.
Reporter: Xiao-Feng Li
Assigned To: weldon washburn
Attachments: gc_v5.001.zip, GCv5-mc001.zip, gcv5-r0.10.zip
This archive has a couple of files implementing an early version of a
trace-forward copying collector for GCv5. It's only a starter with very basic
functionalities. It is a generational GC reqiures write barrier implemented in
JIT. It was tested with JET, and ran SPECJBB2000 and SPECJVM98.
The algorithm is depth-first tracing of From-space, and forwarding live objects
to To-space (It can forward part of the From-space). The To-space has no real
management except for the accomodation of forwarded objects and large objects.
So the To-space is going to be replaced by a mark-compaction GC, and the large
objects will be managed by a LOS GC.
In order to minimize the changes to other components of DRLVM, the codes here
comply with the original contract between GCv4 and other components. I also
borrowed some routine code from GCv4 to avoid repetitive labor work.
GCv5 is under active development, so please expect quick and big changes to
this submitted code base. I will submit new codes from time to time when they
are worth a submission. Any comments or codes are more than welcome.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
?xml version=1.0 encoding=ISO-8859-1?
!--
Copyright 2005-2006 The Apache Software Foundation or its licensors, as applicable.
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
--
!--
Author: Marina V. Goldburt, Dmitry B. Yershov
Version: $Revision: 1.1.1.1 $
--
!--
This is build descriptor for the component vm.gc.
Please refer to make/components/README.txt for details about the component
build descriptor structure.
--
project name=vm.gc
target name=init depends=common_vm
property name=build.depends value=extra.apr,vm.vmcore /
property name=outtype value=shared /
property name=libname value=gc /
property name=src location=${build.vm.home} /
compiler id=cpp.compiler extends=common.cpp.compiler
includepath
Re: [drlvm] passing extra options to vm fails on Widows XP
I was hoping you'd take the hint and limit the patch to just solving the stated problem. Extra refactoring just makes it harder - it can always be done as a followup. Anyway, looking at it now. geir Alexey Varlamov wrote: I observed such problem too. The HARMONY-1376 patch fixes this for me; but Geir still holds it... 2006/10/6, Elena Semukhina [EMAIL PROTECTED]: I failed to run any application with -Xem:jet (and -Xem:opt as well) set in harmonyvm.properties on my Windows XP while I succeeded on Windows 2003. I even copied that file from Windows 2003 machine to XP machine but this did not help. java Test gives me the following: An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 ExceptionCode=c005 ExceptionAddress=004020DF ContextFlags=0001003f Handler1=00401010 Handler2=11105CE0 InaccessibleAddress=0550 EDI= ESI=001531F0 EAX= EBX= ECX=004044F4 EDX=4C25 EIP=004020DF ESP=0013F970 EBP=0550 Module=C:\users\esemukhi\svn1\drlvm\trunk\build\deploy\jre\bin\java.exe Module_base_address=0040 Offset_in_DLL=20df This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. -- Thanks, Elena - 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]
Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
While nobody objects :) the right place for coverage scripts is 'buildtest' module. Seems, that this module should be a little bit reorder: new top level directories should be created: - 'cc' - for cruise control script (and move current stuff to this dir); - 'coverage' - for coverage scripts (It will nice if somebody also placed here data from issue 564); - 'japi' - for script to run 'japi'-tool. Seems, that directory 'tests' also should be created in this module to place non-unit tests when we will have one. thanks, Vladimir
Re: [drlvm][build]Stale object files are linked to DRLVM
Salikh Zakirov wrote: Geir replied: make? I know you are teasing (^_-) I'm actually not. Were there an additional 24 hours in a day There is a whole list of reasons why I'm not a fan of the current system, including maintainability as well as performance. (Building classlib takes far less time that DRLVM on windows, for reasons I find utterly perplexing...) I can easily propose a couple of ways to use make for building DRLVM (i.e. running C++ compiler and linker). The last thing I played with was using shell-script for generating Makefiles using the source file list. Well, cool :) We have the ability to learn from and improve upon classlib how we want to try and handle platforms correctly... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][GC] first generational version of GCv5 is submitted
Xiao-Feng Li wrote: The submitted revision is downloadable in JIRA-1428 at: http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip Nice! w00t! Attached in this email is the gc.xml file I am using that replaces existing one for building gc. Please attach that to the JIRA as well. I can't wait to try this... Below is the submission description: Attached file gcv5-r0.10.zip is first version of the generational mark-compaction GC for GCv5, which combines previous two submitted collectors as planned. That is, a trace-forward collector for minor collection and a mark-compaction collector for major collection. An additon of a copying algorithm is also developed that copies nursery live objects to mature space during a major collection. This revision has subtantial improvement in threading part. Although it's still single threaded collector, the framework for multithreading is ready. Basically, it has mutators and collectors to model the application threads and collection threads. A major design concept in this revision that was not made very clear in previous submissions is space. GC is a concept of a full (or standalone) garbage collector design. One GC can have multiple spaces, each of which can employ different collection policy. With this design idea in mind, the previous trace-forward GC is adapted to be the collection policy for the nursery space, and the mark-compaction GC is adapted to be the collection policy of the mature space. As an embodiment of the design idea, GCv5 eliminates the global gc variable in existing Harmony GC, and different space managements only need to know a general gc data structure, instead of the generational gc structure. This revision has been tested on Windows with SPECJVM98. As the first actual generational GC, any comments (or questions) are welcome! -xiaofeng [DRLVM] first batch of files for GCv5, a trace-forward copying collector Key: HARMONY-1428 URL: http://issues.apache.org/jira/browse/HARMONY-1428 Project: Harmony Issue Type: Improvement Components: DRLVM Environment: These files were only tested on Windows with VS.NET 2003. Reporter: Xiao-Feng Li Assigned To: weldon washburn Attachments: gc_v5.001.zip, GCv5-mc001.zip, gcv5-r0.10.zip This archive has a couple of files implementing an early version of a trace-forward copying collector for GCv5. It's only a starter with very basic functionalities. It is a generational GC reqiures write barrier implemented in JIT. It was tested with JET, and ran SPECJBB2000 and SPECJVM98. The algorithm is depth-first tracing of From-space, and forwarding live objects to To-space (It can forward part of the From-space). The To-space has no real management except for the accomodation of forwarded objects and large objects. So the To-space is going to be replaced by a mark-compaction GC, and the large objects will be managed by a LOS GC. In order to minimize the changes to other components of DRLVM, the codes here comply with the original contract between GCv4 and other components. I also borrowed some routine code from GCv4 to avoid repetitive labor work. GCv5 is under active development, so please expect quick and big changes to this submitted code base. I will submit new codes from time to time when they are worth a submission. Any comments or codes are more than welcome. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ?xml version=1.0 encoding=ISO-8859-1? !-- Copyright 2005-2006 The Apache Software Foundation or its licensors, as applicable. Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !-- Author: Marina V. Goldburt, Dmitry B. Yershov Version: $Revision: 1.1.1.1 $ -- !-- This is build descriptor for the component vm.gc. Please refer to make/components/README.txt for details about the component build descriptor structure. -- project name=vm.gc target name=init depends=common_vm property name=build.depends value=extra.apr,vm.vmcore / property name=outtype value=shared /
Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
Vladimir Ivanov wrote: While nobody objects :) the right place for coverage scripts is 'buildtest' module. Seems, that this module should be a little bit reorder: new top level directories should be created: - 'cc' - for cruise control script (and move current stuff to this dir); - 'coverage' - for coverage scripts (It will nice if somebody also placed here data from issue 564); - 'japi' - for script to run 'japi'-tool. Agreed on all three. Do we have a japi script? geir Seems, that directory 'tests' also should be created in this module to place non-unit tests when we will have one. thanks, Vladimir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][GC] first generational version of GCv5 is submitted
Good progress. I will plug GCV5 in today or tomorrow and report what runs. Provided this code sits well w/ drlvm tree, I will go ahead an commit to vm/gcv5 On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Xiao-Feng Li wrote: The submitted revision is downloadable in JIRA-1428 at: http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip Nice! w00t! Attached in this email is the gc.xml file I am using that replaces existing one for building gc. Please attach that to the JIRA as well. I can't wait to try this... Products Division
Re: [DRLVM][GC] first generational version of GCv5 is submitted
Can you make it selectable for build? IOW sh build.sh -Dbuild.gc=5 or something... Weldon Washburn wrote: Good progress. I will plug GCV5 in today or tomorrow and report what runs. Provided this code sits well w/ drlvm tree, I will go ahead an commit to vm/gcv5 On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Xiao-Feng Li wrote: The submitted revision is downloadable in JIRA-1428 at: http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip Nice! w00t! Attached in this email is the gc.xml file I am using that replaces existing one for building gc. Please attach that to the JIRA as well. I can't wait to try this... 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]
Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
On 6 October 2006 at 9:41, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Vladimir Ivanov wrote: While nobody objects :) the right place for coverage scripts is 'buildtest' module. Seems, that this module should be a little bit reorder: new top level directories should be created: - 'cc' - for cruise control script (and move current stuff to this dir); - 'coverage' - for coverage scripts (It will nice if somebody also placed here data from issue 564); - 'japi' - for script to run 'japi'-tool. Agreed on all three. Do we have a japi script? I have one but it's a little specific to the wrapper we use for the builds that report to the -commits list. But I can provide it if it will help. -Mark. Seems, that directory 'tests' also should be created in this module to place non-unit tests when we will have one. thanks, Vladimir - 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]
Re: [DRLVM][GC] first generational version of GCv5 is submitted
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Can you make it selectable for build? IOW sh build.sh -Dbuild.gc=5 or something... Good idea. Maybe even better would be to have ALL gc's always build and make them selectable on the command line. Weldon Washburn wrote: Good progress. I will plug GCV5 in today or tomorrow and report what runs. Provided this code sits well w/ drlvm tree, I will go ahead an commit to vm/gcv5 On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Xiao-Feng Li wrote: The submitted revision is downloadable in JIRA-1428 at: http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip Nice! w00t! Attached in this email is the gc.xml file I am using that replaces existing one for building gc. Please attach that to the JIRA as well. I can't wait to try this... 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] -- Weldon Washburn Intel Middleware Products Division
Re: [classlib] Recognizing lock objects
On Wed, 4 Oct 2006, Geir Magnusson Jr. wrote: | | | Tim Ellison wrote: | Geir Magnusson Jr. wrote: | +1 | | BTW, why call it RepositionLock? | | That was just an example taken from the class I was looking at, I've | called them different names depending upon the inst var name. | | Oh, thanks. | | It might not be a bad idea to adopt a common pattern like FOOSyncLock | - might make it easier to search for hotspots in a profiler... Just stumbled upon this thread while organizing my email..! What about an marker interface, or common ancestor class? Just to mark it as being of this type of usage? Would do a lot of good, I recon, to be able to trace/track such usages..? (Re java.util.EventListener, A tagging interface.. ) Regards, Endre. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
Thanks - maybe someone can massage that to fit with what we're building... Mark Hindess wrote: On 6 October 2006 at 9:41, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Vladimir Ivanov wrote: While nobody objects :) the right place for coverage scripts is 'buildtest' module. Seems, that this module should be a little bit reorder: new top level directories should be created: - 'cc' - for cruise control script (and move current stuff to this dir); - 'coverage' - for coverage scripts (It will nice if somebody also placed here data from issue 564); - 'japi' - for script to run 'japi'-tool. Agreed on all three. Do we have a japi script? I have one but it's a little specific to the wrapper we use for the builds that report to the -commits list. But I can provide it if it will help. -Mark. Seems, that directory 'tests' also should be created in this module to place non-unit tests when we will have one. thanks, Vladimir - 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]
Re: [drlvm][build]Stale object files are linked to DRLVM
Geir Magnusson Jr. wrote: make? Salikh Zakirov wrote: I know you are teasing (^_-) Geir replied: I'm actually not. Were there an additional 24 hours in a day There is a whole list of reasons why I'm not a fan of the current system, including maintainability as well as performance. (Building classlib takes far less time that DRLVM on windows, for reasons I find utterly perplexing...) Well, performance-wise, using 'make' will not make DRLVM build any faster, mainly because it is hard (if at all possible) to take advantage of compile-many-cpp-files-by-single-compiler-command mode available in MSVC and Intel compilers. I completely agree on the maintainability side. I can easily propose a couple of ways to use make for building DRLVM (i.e. running C++ compiler and linker). The last thing I played with was using shell-script for generating Makefiles using the source file list. Well, cool :) We have the ability to learn from and improve upon classlib how we want to try and handle platforms correctly... Actually, I do not think I would want to take classlib's make system as the base, because it does not satisfy two requirements I personally consider important: * concentrate the build configuration in one place * automatically deduce object files lists by finding .cpp files And, I would rather add GNU Make (Cygwin or Mingw) to the required build tools, than maintain two copies of make files. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
Dear all, Please go to https://issues.apache.org/jira/browse/HARMONY-1631 to find a patch for README.txt. Could you please find a chance to check whether the information is up-to date? (pay special attention to KNOWN ISSUES and TODO sections) In this connection I'd like to ask you to: 1. Check whether we need info about the compilers described below: + Microsoft 32-bit C/C++ Compiler, version 7 or higher + Windows platform SDK + Microsoft Visual Studio .NET 2003 or higher + Intel C++ Compiler, version 9.0 2. If we really need the aforementioned compilers, should we mention the following: 3.7 You can switch between the different compilers and modes by using the environment variables, as follows: On Windows*: | On Linux*: -+-- MSVC compiler : set CXX=msvc # | N/A Intel(R) compiler : set CXX=icl | export CXX=icc GCC compiler : N/A | export CXX=gcc etc 3. Is this still a dependency for Linux? libxml2 package 4. Do we really need all stuff specified as additional (section 2.TOOLS AND ENVIRONMENT VARIABLES REQUIRED FOR THE BUILD)? Your suggestions/comments/ideas are very welcome. :) Best regards, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, October 06, 2006 1:18 PM To: harmony-dev@incubator.apache.org Subject: Re: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 I was looking at the patch, and think we should just chuck the whole README.txt, salvage what's good, put it on the website, and put a pointer in the README.txt to the website. geir Morozova, Nadezhda wrote: Thanks for the fix, Alexei. I think this is a good start for updating the README. I've looked at the current version, and many other things are out-of-date (such as ij as the name of our executable). Some things are also duplicated - we now have the nice Quick Help pages for users [1] and developers [2]. As I see it, the Quick Start you've been referring to roughly matches [1], whereas [2] is for those who have to 'read this README and follow building instructions to the point.' :) I suggest that we edit the README file more to improve it. What do you think? Do you think we can use JIRA 1730 for these changes? [1] http://incubator.apache.org/harmony/quickhelp_users.html [2] http://incubator.apache.org/harmony/quickhelp_contributors.html Best regards, Nadya Morozova -Original Message- From: Fedotov, Alexei A Sent: Friday, October 06, 2006 12:23 AM To: Morozova, Nadezhda Cc: harmony-dev@incubator.apache.org Subject: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 BTW, I really enjoyed the last item of the Quick Start section: 7. If building the DRLVM fails, read this README and follow building instructions to the point. A hardcore programmer can loop infinitely here. :-) With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Fedotov, Alexei A Sent: Friday, October 06, 2006 12:20 AM To: =SMTP:[EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org Subject: RE: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Hi, Nadya, I tried to build DRLVM, faced the issue from the thread below, and filed a JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1730. Does the patch worth to be applied to the README.txt? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Spark Shen [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 9:56 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Thank you, I am trying :-). 2006/9/22, Vladimir Gorr [EMAIL PROTECTED]: On 9/22/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. Sorry for the late reply. JIRA 1500 is due to discussion [1] on the dev mailing list. I can not build DRLVM on my desktop. (Windows XP, RI JDK1.5.0, ant 1.6.5). So I could not reproduce the bug The prompted error message is: C:\spark\drlvm\trunk\build\make\build.xml:238: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:289: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:291: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:462: Warning:
Re: [DRLVM][GC] first generational version of GCv5 is submitted
Weldon Washburn wrote: On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Can you make it selectable for build? IOW sh build.sh -Dbuild.gc=5 or something... Good idea. Maybe even better would be to have ALL gc's always build and make them selectable on the command line. Well, I was thinking more about just building w/ the GC you chose. Seems to be less internal framework for plugging it in right now. geir Weldon Washburn wrote: Good progress. I will plug GCV5 in today or tomorrow and report what runs. Provided this code sits well w/ drlvm tree, I will go ahead an commit to vm/gcv5 On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Xiao-Feng Li wrote: The submitted revision is downloadable in JIRA-1428 at: http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip Nice! w00t! Attached in this email is the gc.xml file I am using that replaces existing one for building gc. Please attach that to the JIRA as well. I can't wait to try this... 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]
Re: [classlib][swing] Generification of the swing API.
I am happy to inform that I created a jira #1758 [1] for this task and attached a first patch. Also, I'd like to attract attention to several patches for the awt/swing modules: swing #1536 #1533 #1509 #1475 awt #1647 #1652 #1659 [1] http://issues.apache.org/jira/browse/HARMONY-1758 On 10/5/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: If no one objects I'll generify javax.swing to improve API indicators. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] clash in eclipse metadata
I have a problem with how we do eclipse meta-data in classlib, and I'm guessing there's some cool trick everyone else knows about. Right now, tree has lots of mods to modules/*/.settings/* and modules/*/.classpath, resulting in pain and suffering when I try to do a commit that spans multiple modules. How are people solving this? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
Nadya, here is my 2 cents: On 10/6/06, Morozova, Nadezhda [EMAIL PROTECTED] wrote: Dear all, Please go to https://issues.apache.org/jira/browse/HARMONY-1631 to find a patch for README.txt. Could you please find a chance to check whether the information is up-to date? (pay special attention to KNOWN ISSUES and TODO sections) In this connection I'd like to ask you to: 1. Check whether we need info about the compilers described below: + Microsoft 32-bit C/C++ Compiler, version 7 or higher + Windows platform SDK + Microsoft Visual Studio .NET 2003 or higher + Intel C++ Compiler, version 9.0 I think yes, we must point all of compilers we support. May be it worth to point the GCC versions we tested too. For example I'm not sure DRLVM is compilable with MSVC2005. 3.7 You can switch between the different compilers and modes by using the environment variables, as follows: On Windows*: | On Linux*: -+-- MSVC compiler : set CXX=msvc # | N/A Intel(R) compiler : set CXX=icl | export CXX=icc GCC compiler : N/A | export CXX=gcc etc I think that this information is also useful. Do you think that README file is too bloated? 4. Do we really need all stuff specified as additional (section 2.TOOLSAND ENVIRONMENT VARIABLES REQUIRED FOR THE BUILD)? I vote to have this chapter and + to describe briefly how to obtain and how to set classlib directory. Your suggestions/comments/ideas are very welcome. :) Best regards, Nadya Morozova -- Mikhail Fursov
[classlib] archve - JarOutputStreamTest
I'm about to commit 1376, and having tested w/ DRLVM's tests, I decided to try J9 w/ classlib test suite. Is JarOutputStreamTest failing for anyone else? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][GC] first generational version of GCv5 is submitted
Thanks. You can unzip it under gc/ directory after moving the original src/ tree. Note it has a dependent patch in JIRA for JET write barrier. There is also a one liner fix to in the JIRA. Thanks, xiaofeng On 10/6/06, Weldon Washburn [EMAIL PROTECTED] wrote: Good progress. I will plug GCV5 in today or tomorrow and report what runs. Provided this code sits well w/ drlvm tree, I will go ahead an commit to vm/gcv5 On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Xiao-Feng Li wrote: The submitted revision is downloadable in JIRA-1428 at: http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip Nice! w00t! Attached in this email is the gc.xml file I am using that replaces existing one for building gc. Please attach that to the JIRA as well. I can't wait to try this... 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]
Re: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
Why don't we just add this info to the getting started pages on the website?It's somewhat repetitive and we should just maintain in one place. Morozova, Nadezhda wrote: Dear all, Please go to https://issues.apache.org/jira/browse/HARMONY-1631 to find a patch for README.txt. Could you please find a chance to check whether the information is up-to date? (pay special attention to KNOWN ISSUES and TODO sections) In this connection I'd like to ask you to: 1. Check whether we need info about the compilers described below: + Microsoft 32-bit C/C++ Compiler, version 7 or higher + Windows platform SDK + Microsoft Visual Studio .NET 2003 or higher + Intel C++ Compiler, version 9.0 2. If we really need the aforementioned compilers, should we mention the following: 3.7 You can switch between the different compilers and modes by using the environment variables, as follows: On Windows*: | On Linux*: -+-- MSVC compiler : set CXX=msvc # | N/A Intel(R) compiler : set CXX=icl | export CXX=icc GCC compiler : N/A | export CXX=gcc etc 3. Is this still a dependency for Linux? libxml2 package 4. Do we really need all stuff specified as additional (section 2.TOOLS AND ENVIRONMENT VARIABLES REQUIRED FOR THE BUILD)? Your suggestions/comments/ideas are very welcome. :) Best regards, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, October 06, 2006 1:18 PM To: harmony-dev@incubator.apache.org Subject: Re: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 I was looking at the patch, and think we should just chuck the whole README.txt, salvage what's good, put it on the website, and put a pointer in the README.txt to the website. geir Morozova, Nadezhda wrote: Thanks for the fix, Alexei. I think this is a good start for updating the README. I've looked at the current version, and many other things are out-of-date (such as ij as the name of our executable). Some things are also duplicated - we now have the nice Quick Help pages for users [1] and developers [2]. As I see it, the Quick Start you've been referring to roughly matches [1], whereas [2] is for those who have to 'read this README and follow building instructions to the point.' :) I suggest that we edit the README file more to improve it. What do you think? Do you think we can use JIRA 1730 for these changes? [1] http://incubator.apache.org/harmony/quickhelp_users.html [2] http://incubator.apache.org/harmony/quickhelp_contributors.html Best regards, Nadya Morozova -Original Message- From: Fedotov, Alexei A Sent: Friday, October 06, 2006 12:23 AM To: Morozova, Nadezhda Cc: harmony-dev@incubator.apache.org Subject: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 BTW, I really enjoyed the last item of the Quick Start section: 7. If building the DRLVM fails, read this README and follow building instructions to the point. A hardcore programmer can loop infinitely here. :-) With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Fedotov, Alexei A Sent: Friday, October 06, 2006 12:20 AM To: =SMTP:[EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org Subject: RE: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Hi, Nadya, I tried to build DRLVM, faced the issue from the thread below, and filed a JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1730. Does the patch worth to be applied to the README.txt? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Spark Shen [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 9:56 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Thank you, I am trying :-). 2006/9/22, Vladimir Gorr [EMAIL PROTECTED]: On 9/22/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. Sorry for the late reply. JIRA 1500 is due to discussion [1] on the dev mailing list. I can not build DRLVM on my desktop. (Windows XP, RI JDK1.5.0, ant 1.6.5). So I could not reproduce the bug The prompted error message is: C:\spark\drlvm\trunk\build\make\build.xml:238: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:289: The
Re: [classlib] archve - JarOutputStreamTest
never mind - local problem w/ fork() failing... Geir Magnusson Jr. wrote: I'm about to commit 1376, and having tested w/ DRLVM's tests, I decided to try J9 w/ classlib test suite. Is JarOutputStreamTest failing for anyone else? geir - 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]
Re: [DRLVM][GC] first generational version of GCv5 is submitted
Can we not put it in gc/? How about gcv5/ ? Xiao-Feng Li wrote: Thanks. You can unzip it under gc/ directory after moving the original src/ tree. Note it has a dependent patch in JIRA for JET write barrier. There is also a one liner fix to in the JIRA. Thanks, xiaofeng On 10/6/06, Weldon Washburn [EMAIL PROTECTED] wrote: Good progress. I will plug GCV5 in today or tomorrow and report what runs. Provided this code sits well w/ drlvm tree, I will go ahead an commit to vm/gcv5 On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Xiao-Feng Li wrote: The submitted revision is downloadable in JIRA-1428 at: http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip Nice! w00t! Attached in this email is the gc.xml file I am using that replaces existing one for building gc. Please attach that to the JIRA as well. I can't wait to try this... 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]
Re: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
I like the README.txt file from the classlib . It helped me a lot when I built classlib first time, so let's keep README for DRLVM too. But classlib's README file is 2 times shorter than DRLVM's version - so it's easier to read it. I vote to leave in README file only info needed for a successful build. Any clarifications for possible problems put to the site. On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Why don't we just add this info to the getting started pages on the website?It's somewhat repetitive and we should just maintain in one place. -- Mikhail Fursov
Re: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
There's a maintenance issue here. The point of the quickstart guides is just that - to help someone build for the first time... Mikhail Fursov wrote: I like the README.txt file from the classlib . It helped me a lot when I built classlib first time, so let's keep README for DRLVM too. But classlib's README file is 2 times shorter than DRLVM's version - so it's easier to read it. I vote to leave in README file only info needed for a successful build. Any clarifications for possible problems put to the site. On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Why don't we just add this info to the getting started pages on the website?It's somewhat repetitive and we should just maintain in one place. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm][mmtk] Offset.fromSigned() -- what are the semantics?
MMTk gurus! I'm working on MMTk 'unboxed' package support in DRLVM. I hope I finished the implementation, but because of the scant comments in JAVA docs (like http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/Offset.html) I feel that I do not completely understand the semantics of some operations. Here is one of the issues I do not completely understand: Look into this test: long v1 = Offset.fromIntSignExtend(0xBABA).toLong() long v2 =Offset.fromIntSignExtend(0x).toLong() What result is expected after these transformations on IA32 platform? The Offset by itself is an Integer of 32 or 64 bits (BTW is it signed?). If the offset is 32 bit integer on IA32 platform the operations like fromIntSignExtend or fromIntZeroExtend do nothing and just return the integer value of the offset. So, after the operations above v1=0xBABA and v2=0xFFffFFff for IA32 and v1=0xBABA and v2=0xFFffFFffFFffFFff for EM64T platforms. Is it right? -- Mikhail Fursov
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Geir, That's terrible. We have power outageservers are down. I can't send the patches now will do it tomorrow Evgueni On 10/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: woo hoo! here we go... Andrey Chernyshev wrote: Hi Evgueni, On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi All, I have attached updated patch to the JIRA. It should resolve remain concerns. Andrey, could you give a green light now? Thanks for updating the patch! I agree it it can be committed, at least signatures look good. 5 revisions seem like more than enough :). Anyways, I think the remaining issues can be resolved with additional patches. Thanks again for the good work and your patience. Thanks, Andrey. Thanks Evgueni On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Andrey, I see your points. I think both approaches have advantages and disadvantages. I think it is quite hard to say which approach is better until we play with one VM only. I still feel like introducing one more dependence is better than spreading code which deals with attachment among VM and TM. We really get stuck. OK, just because I want to move forward I will do required changes to remove vm_create_jthread from TM. I believe that will resolve all our disagreements and the patch will be applied soon. Thanks Evgueni. On 10/4/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 10/3/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 10/3/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Andrey, Just to be clear I agree with you it is more convenient if jthread_create takes JNIEnv instead of JavaVM. It reflects that current thread has been attached already. Do you think it makes sense to get rid of JNIEnv and use jthread_get_JNI_env in that case? The jthread_* layer is designed like if it were a regular JNI application which is meant to be called from the Java code, hence every function on that layer receives JNIenv. We can probably get rid of the JNEnv parameter for jthread_* functions, assuming that TM can always extract JNIenv for the current thread with jthread_get_JNI_env(). My only concern would be the performance - once the JNIenv is already known for the native part of the kernel classes impl, it must be cheaper to pass JNIEnv to TM as an extra parameter rather than extract it from the TLS again. Other than that, I see no strong advantages in keeping JNIEnv parameter. Regarding jthread_attach. I still didn't get your point Clarify it please if you think jhread_attach should be modified. Sorry for being not clear: I think for jthread_attach, we have two options: 1) Make JNIEnv input parameter - it must be new JNIEnv that VM pre-allocates for the new Java thread. jthread_attach would just associate it with the current thread. 2) Obtain JNIEnv via vm_attach() callback. In this case, if vm_attach() callback implementation needs to know for which JavaVM new JNIenv has to be allocated, then we'll need to add JavaVM as input parameter for jthread_attach(). I think both options should be fine, (1) would probably keep TM interface a bit lighter, though (2) may look more closer to the JNI invocation API idea. So I think adding JavaVM specifically for jthread_attach may make sense given the explanation you provided earlier. The concern I would have regarding the proposed jthread_attach implementation is a call to vm_create_jthread() - this call introduces an extra dependency of TM on vmcore that I'd prefer to be avoided. In the original version, jthread_attach() was taking jthread argument of the already prepared j.l.Thread. I understand your concern. Unfortunately I don't see what we can do here. Let me explain. In the beginning you have an unattached native thread. To be able to call java code (which is required for constructing j.l.Thread instance) the thread should be attached first. To be specific it should be attached to VM by calling vm_attach which will return a valid JNIEnv It is valid to use JNI from that moment. Obtained JNIEnv can be used to execute java code and create j.l.Thread instance. Since we do vm_attach in jthread_attach we need to do vm_create_jthread inside jthread_atach as well. Of course it can be an alternative to do vm_attach and vm_create_jthread outside of TM right before jthread_attach. Sure it will reduce one dependence between VM and TM. But it seems like artificial action for me just because of dependency Why do you think it is artificial? I would rather prefer not to throw vm_attach event from the jthread_attach() call at all than to add extra dependency. The idea of jthread layer is
Re: [drlvm] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
On 10/6/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Ivan, I'm agree that the problem we have is more complicated then my example. And I'm glad to hear that there are no problem with the scenario from my example today. Jitrino.OPT uses 3 interface methods to report GC root set: 1. VMEXPORT void vm_enumerate_root_reference(Managed_Object_Handle *ref, Boolean is_pinned); 2. VMEXPORT void vm_enumerate_root_interior_pointer(void **slot, int offset, Boolean is_pinned); 3. VMEXPORT void vm_enumerate_root_interior_pointer_with_base(void **slot_root, void **slot_base, Boolean is_pinned); The method 1 is used for bases The method 2 is used for mptrs with offset known at compilation time The method 3 is used for mptrs with dynamic offset that is computed only in runtime In our case JIT reports the pair: new_base and old_mptr. JIT does not report offset here. So if you could process this situation with 'forwarding' pointer we have the half of the problem solved. The other half of the problem is finding a base for the mptr with unknown offset. The current implementation in JIT looks for a base right before reporting the mptr: it selects the nearest one. So if base pointer was updated by GC the search will produce incorrect results. I see the following solutions in our problem 1) Fix in GC and JIT: GC is learned how to deal with mptrs reported with outdated base + fix in JIT in base searching algorithm (here we have a lot of variants) 2) Fix in JIT only: precache all offsets and then report. In this case JIT will always use only method1 and method2. I vote for the item 2 and can provide a fix in a day. But in this case I propose to remove the method3 from GC-JIT interface at all, as deprecated. I would like to have second variant implemented and corresponding (method3) interface removed as unused anymore. But, I'm not sure if this is possible. Thread stack enumeration is just a part of root set enumeration process. Roots can be already reported (and moved) even before the jitrino enumeration starts. Will the second variant work despite of this? There is one more way to make this work. Do the same as gc_v4 does: get full root set and then do the modifications to heap. -- Ivan 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]
Re: [DRLVM][GC] first generational version of GCv5 is submitted
On 10/6/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: A major design concept in this revision that was not made very clear in previous submissions is space. GC is a concept of a full (or standalone) garbage collector design. One GC can have multiple spaces, each of which can employ different collection policy. With this design idea in mind, the previous trace-forward GC is adapted to be the collection policy for the nursery space, and the mark-compaction GC is adapted to be the collection policy of the mature space. As an embodiment of the design idea, GCv5 eliminates the global gc variable in existing Harmony GC, and different space managements only need to know a general gc data structure, instead of the generational gc structure. Thanks for the code Xiao Feng. This ( above ) lose coupling is a great idea. We have discussed a little about space/collection policies/inter-space relations on a previous thread. This revision has been tested on Windows with SPECJVM98. As the first actual generational GC, any comments (or questions) are welcome! I will try to run the DeCapo suite against this. Thanks again, Rana
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Nooo! LOL I'm here waiting - This will unblock a whole bunch of things :) Thanks for the effort Evgueni Brevnov wrote: Geir, That's terrible. We have power outageservers are down. I can't send the patches now will do it tomorrow Evgueni On 10/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: woo hoo! here we go... Andrey Chernyshev wrote: Hi Evgueni, On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi All, I have attached updated patch to the JIRA. It should resolve remain concerns. Andrey, could you give a green light now? Thanks for updating the patch! I agree it it can be committed, at least signatures look good. 5 revisions seem like more than enough :). Anyways, I think the remaining issues can be resolved with additional patches. Thanks again for the good work and your patience. Thanks, Andrey. Thanks Evgueni On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Andrey, I see your points. I think both approaches have advantages and disadvantages. I think it is quite hard to say which approach is better until we play with one VM only. I still feel like introducing one more dependence is better than spreading code which deals with attachment among VM and TM. We really get stuck. OK, just because I want to move forward I will do required changes to remove vm_create_jthread from TM. I believe that will resolve all our disagreements and the patch will be applied soon. Thanks Evgueni. On 10/4/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 10/3/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 10/3/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Andrey, Just to be clear I agree with you it is more convenient if jthread_create takes JNIEnv instead of JavaVM. It reflects that current thread has been attached already. Do you think it makes sense to get rid of JNIEnv and use jthread_get_JNI_env in that case? The jthread_* layer is designed like if it were a regular JNI application which is meant to be called from the Java code, hence every function on that layer receives JNIenv. We can probably get rid of the JNEnv parameter for jthread_* functions, assuming that TM can always extract JNIenv for the current thread with jthread_get_JNI_env(). My only concern would be the performance - once the JNIenv is already known for the native part of the kernel classes impl, it must be cheaper to pass JNIEnv to TM as an extra parameter rather than extract it from the TLS again. Other than that, I see no strong advantages in keeping JNIEnv parameter. Regarding jthread_attach. I still didn't get your point Clarify it please if you think jhread_attach should be modified. Sorry for being not clear: I think for jthread_attach, we have two options: 1) Make JNIEnv input parameter - it must be new JNIEnv that VM pre-allocates for the new Java thread. jthread_attach would just associate it with the current thread. 2) Obtain JNIEnv via vm_attach() callback. In this case, if vm_attach() callback implementation needs to know for which JavaVM new JNIenv has to be allocated, then we'll need to add JavaVM as input parameter for jthread_attach(). I think both options should be fine, (1) would probably keep TM interface a bit lighter, though (2) may look more closer to the JNI invocation API idea. So I think adding JavaVM specifically for jthread_attach may make sense given the explanation you provided earlier. The concern I would have regarding the proposed jthread_attach implementation is a call to vm_create_jthread() - this call introduces an extra dependency of TM on vmcore that I'd prefer to be avoided. In the original version, jthread_attach() was taking jthread argument of the already prepared j.l.Thread. I understand your concern. Unfortunately I don't see what we can do here. Let me explain. In the beginning you have an unattached native thread. To be able to call java code (which is required for constructing j.l.Thread instance) the thread should be attached first. To be specific it should be attached to VM by calling vm_attach which will return a valid JNIEnv It is valid to use JNI from that moment. Obtained JNIEnv can be used to execute java code and create j.l.Thread instance. Since we do vm_attach in jthread_attach we need to do vm_create_jthread inside jthread_atach as well. Of course it can be an alternative to do vm_attach and vm_create_jthread outside of TM right before jthread_attach. Sure it will reduce one dependence between VM and TM. But it seems like artificial action for me just because of dependency Why do you think it is artificial? I
Re: [drlvm] passing extra options to vm fails on Widows XP
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]: I was hoping you'd take the hint and limit the patch to just solving the stated problem. Extra refactoring just makes it harder - it can always be done as a followup. Yeah, this was miscommunicated - I thought I provided enugh justification for all the changes... Anyway, looking at it now. geir Alexey Varlamov wrote: I observed such problem too. The HARMONY-1376 patch fixes this for me; but Geir still holds it... 2006/10/6, Elena Semukhina [EMAIL PROTECTED]: I failed to run any application with -Xem:jet (and -Xem:opt as well) set in harmonyvm.properties on my Windows XP while I succeeded on Windows 2003. I even copied that file from Windows 2003 machine to XP machine but this did not help. java Test gives me the following: An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 ExceptionCode=c005 ExceptionAddress=004020DF ContextFlags=0001003f Handler1=00401010 Handler2=11105CE0 InaccessibleAddress=0550 EDI= ESI=001531F0 EAX= EBX= ECX=004044F4 EDX=4C25 EIP=004020DF ESP=0013F970 EBP=0550 Module=C:\users\esemukhi\svn1\drlvm\trunk\build\deploy\jre\bin\java.exe Module_base_address=0040 Offset_in_DLL=20df This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. -- Thanks, Elena - 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]
Re: [drlvm] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
On 10/6/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: I would like to have second variant implemented and corresponding (method3) interface removed as unused anymore. But, I'm not sure if this is possible. Thread stack enumeration is just a part of root set enumeration process. Roots can be already reported (and moved) even before the jitrino enumeration starts. Will the second variant work despite of this? Why do you think it will not work? Here is the algorithm JIT reports 2 types of items: 1) bases 2) mptrs + offsets 1) Once JIT report base GC uses the same algorithm as before: it moves the object and for subsequent reports of the same base it uses 'forwarding pointer' as you mentioned before: if the second reference points to previous position of object it will be automatically updated according to installed forwarding pointer. 2) When JIT reports mptr + offset, GC deduce the old object location, and uses the same 'forwarding pointer' to adjust the mptr What is wrong with this schema? There is one more way to make this work. Do the same as gc_v4 does: get full root set and then do the modifications to heap. Yes this is the most pessimistic variant we have if all other variants failed -- Mikhail Fursov
Re: [drlvm] too tired, need help
Actually you'd only need 2 changes over my patch:
1) change the path to kernel.jar in classloader.cpp (and in build
scripts accordingly :);
2) add smth like
-Dorg.apache.harmony.vm.path=%JAVA_HOME%/bin/%VM_DIR% to
harmonyvm.properties
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
Ok - I'll grab your -Xbootclasspath stuff...
Alexey Varlamov wrote:
(Cross-posted from JIRA):
OK, we should combine both patches. The
-Dorg.apache.harmony.vm.vmdir= of yours is logical continuation
towards multiVM-WS feature. And my patch more correctly handles
-Xbootclasspath[/ap]: options.
Will refresh patch after 1582 if your mind is easy now :)
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
not a worry - I learned a lot
Take a look at what I did and see if it's right :)
geir
Alexey Varlamov wrote:
Oh, I'd had not such happy lunch time knowing about your torments ;(
I thought I indicated my intentions about this on the list and did'n
bother to state this in the JIRA.
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I have this almost done so that it uses the boot classpath
generated by
luni. Only remaining peace is to add kernel.jar to it, and I'll do
that
so it comes from the VMDIR - we wanted to move kernel.jar there anyway
for cleaner deployment.
I just couldn't stop... no mental peace. :)
Geir Magnusson Jr. wrote:
Alexey Varlamov wrote:
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure
how it
gets to us...), and I'm too tired, too dumb, or both to figure
this out.
Geir,
To avoid possible duplication - there is HARMONY-1626 about smth
very
similar, and I'm ready to submit a patch, just waiting for H-1582.
Ah - I was looking at this very JIRA. I didn't realize you were
working
on it. PLease submit the patch now just so i can see it so i can
to to
bed w/ a peaceful mind.
You can submit another after 1582 - also, please link to 1582
geir
Launcher calls JNI_CreateJavaVM. In our
vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void
*vm_args) {
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined
or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be
useless
here...
geir
-
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]
-
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]
-
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:
Re: [drlvm] too tired, need help
Fine. Tell me what's wrong with mine. Why? Not because I care that
much, but because this soup of properties is a mess, and this is a good
time to clean this up.
Actually, I'll start a new thread. Please participate. :)
geir
Alexey Varlamov wrote:
Actually you'd only need 2 changes over my patch:
1) change the path to kernel.jar in classloader.cpp (and in build
scripts accordingly :);
2) add smth like
-Dorg.apache.harmony.vm.path=%JAVA_HOME%/bin/%VM_DIR% to
harmonyvm.properties
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
Ok - I'll grab your -Xbootclasspath stuff...
Alexey Varlamov wrote:
(Cross-posted from JIRA):
OK, we should combine both patches. The
-Dorg.apache.harmony.vm.vmdir= of yours is logical continuation
towards multiVM-WS feature. And my patch more correctly handles
-Xbootclasspath[/ap]: options.
Will refresh patch after 1582 if your mind is easy now :)
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
not a worry - I learned a lot
Take a look at what I did and see if it's right :)
geir
Alexey Varlamov wrote:
Oh, I'd had not such happy lunch time knowing about your torments ;(
I thought I indicated my intentions about this on the list and did'n
bother to state this in the JIRA.
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I have this almost done so that it uses the boot classpath
generated by
luni. Only remaining peace is to add kernel.jar to it, and I'll do
that
so it comes from the VMDIR - we wanted to move kernel.jar there
anyway
for cleaner deployment.
I just couldn't stop... no mental peace. :)
Geir Magnusson Jr. wrote:
Alexey Varlamov wrote:
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure
how it
gets to us...), and I'm too tired, too dumb, or both to figure
this out.
Geir,
To avoid possible duplication - there is HARMONY-1626 about smth
very
similar, and I'm ready to submit a patch, just waiting for
H-1582.
Ah - I was looking at this very JIRA. I didn't realize you were
working
on it. PLease submit the patch now just so i can see it so i can
to to
bed w/ a peaceful mind.
You can submit another after 1582 - also, please link to 1582
geir
Launcher calls JNI_CreateJavaVM. In our
vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void
*vm_args) {
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined
or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be
useless
here...
geir
-
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]
-
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]
-
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
[general] define pre-commit testing configs to gain the stability
Hello all, This thread is about a way to improve stability in the environment of growing patch flow in Harmony. Originally I though about DRLVM issues but this may be helpful for classlib too. Currenly, before committing a patch a committer checks it on his favorite configurations (I mean architecture, OS and compiler first of all). Another committer checks another patch on a different set of configurations. As a result, though both patches are tested, there is no guarantee that they will work together on any configuration. If we agree on common testing configs we can make sure the Harmony will be stable on at least this set of configurations. This does not mean we won't fix problems on other configurations. The goal is to gain and maintain general stability. Another benefit would be in faster adoption of patches. If contributors could check their patches on the same configs as the committers do, there would be less likely a particular patch is rejected. I propose to work out a set of configs the committers will use to check patches before committing them to SVN. We can start with a few configs defining the platform, OS familly and the compiler used. When we are sure the Harmony is stable we can add more configurations. IMO, it would be reasonable to start with 3 configurations - one configuration for each supported platform, for example: - Windows / IA32 / MSVS .NET 2003 / release - Linux / IA32 / GCC 4.0.3 / release - Linux / EM64T / GCC 4.0.3 / release There may be a contrary point - let's everyone use it's own platform - such way we'll discover bugs earlier. I think this might work good in a smaller project. The Harmony is quite a big child already and trying to kill all the birds we may chase them for ages. I'd be happy if we converge on the set of our primary target configs here. Thank you Pavel Ozhdikhin - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
On 10/6/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/6/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: I would like to have second variant implemented and corresponding (method3) interface removed as unused anymore. But, I'm not sure if this is possible. Thread stack enumeration is just a part of root set enumeration process. Roots can be already reported (and moved) even before the jitrino enumeration starts. Will the second variant work despite of this? Why do you think it will not work? Here is the algorithm JIT reports 2 types of items: 1) bases 2) mptrs + offsets 1) Once JIT report base GC uses the same algorithm as before: it moves the object and for subsequent reports of the same base it uses 'forwarding pointer' as you mentioned before: if the second reference points to previous position of object it will be automatically updated according to installed forwarding pointer. 2) When JIT reports mptr + offset, GC deduce the old object location, and uses the same 'forwarding pointer' to adjust the mptr What is wrong with this schema? If it is possible to get somehow valid offset within object then it is great! I would be happy to see this solved this way. Waiting for your patch. For, now I have attached to JIRA HARMONY-1682 the pessimistic variant of fix for those who may not be interested in the discussion and wants to have the problem fixed (workarounded?) anyhow. -- Thanks, Ivan There is one more way to make this work. Do the same as gc_v4 does: get full root set and then do the modifications to heap. Yes this is the most pessimistic variant we have if all other variants failed -- 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]
[drlvm] the big soup of VM properties (HARMONY-1626)
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 suggestions?
geir
Geir Magnusson Jr. wrote:
Fine. Tell me what's wrong with mine. Why? Not because I care that
much, but because this soup of properties is a mess, and this is a good
time to clean this up.
Actually, I'll start a new thread. Please participate. :)
geir
Alexey Varlamov wrote:
Actually you'd only need 2 changes over my patch:
1) change the path to kernel.jar in classloader.cpp (and in build
scripts accordingly :);
2) add smth like
-Dorg.apache.harmony.vm.path=%JAVA_HOME%/bin/%VM_DIR% to
harmonyvm.properties
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
Ok - I'll grab your -Xbootclasspath stuff...
Alexey Varlamov wrote:
(Cross-posted from JIRA):
OK, we should combine both patches. The
-Dorg.apache.harmony.vm.vmdir= of yours is logical continuation
towards multiVM-WS feature. And my patch more correctly handles
-Xbootclasspath[/ap]: options.
Will refresh patch after 1582 if your mind is easy now :)
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
not a worry - I learned a lot
Take a look at what I did and see if it's right :)
geir
Alexey Varlamov wrote:
Oh, I'd had not such happy lunch time knowing about your
torments ;(
I thought I indicated my intentions about this on the list and
did'n
bother to state this in the JIRA.
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I have this almost done so that it uses the boot classpath
generated by
luni. Only remaining peace is to add kernel.jar to it, and I'll do
that
so it comes from the VMDIR - we wanted to move kernel.jar there
anyway
for cleaner deployment.
I just couldn't stop... no mental peace. :)
Geir Magnusson Jr. wrote:
Alexey Varlamov wrote:
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I'm trying to trace through the boot sequence chasing some
boot
classpath property thing (luniglob sets it, and I can't figure
how it
gets to us...), and I'm too tired, too dumb, or both to figure
this out.
Geir,
To avoid possible duplication - there is HARMONY-1626 about
smth
very
similar, and I'm ready to submit a patch, just waiting for
H-1582.
Ah - I was looking at this very JIRA. I didn't realize you were
working
on it. PLease submit the patch now just so i can see it so i
can
to to
bed w/ a peaceful mind.
You can submit another after 1582 - also, please link to 1582
geir
Launcher calls JNI_CreateJavaVM. In our
vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void
*vm_args) {
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined
or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be
useless
here...
geir
-
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]
-
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]
Re: [drlvm] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
On 10/6/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: If it is possible to get somehow valid offset within object then it is great! I would be happy to see this solved this way. Waiting for your patch. Yes, before reporting all objects and mptr for a method JIT is able to calculate offsets and use them when reporting mptrs. For, now I have attached to JIRA HARMONY-1682 the pessimistic variant of fix for those who may not be interested in the discussion and wants to have the problem fixed (workarounded?) anyhow. Ok. -- Mikhail Fursov
Re: [general] define pre-commit testing configs to gain the stability
Pavel, Your idea has sence. But... Are you sure that all the committers has all the mentioned configurations? SY, Alexey 2006/10/6, Pavel Ozhdikhin [EMAIL PROTECTED]: Hello all, This thread is about a way to improve stability in the environment of growing patch flow in Harmony. Originally I though about DRLVM issues but this may be helpful for classlib too. Currenly, before committing a patch a committer checks it on his favorite configurations (I mean architecture, OS and compiler first of all). Another committer checks another patch on a different set of configurations. As a result, though both patches are tested, there is no guarantee that they will work together on any configuration. If we agree on common testing configs we can make sure the Harmony will be stable on at least this set of configurations. This does not mean we won't fix problems on other configurations. The goal is to gain and maintain general stability. Another benefit would be in faster adoption of patches. If contributors could check their patches on the same configs as the committers do, there would be less likely a particular patch is rejected. I propose to work out a set of configs the committers will use to check patches before committing them to SVN. We can start with a few configs defining the platform, OS familly and the compiler used. When we are sure the Harmony is stable we can add more configurations. IMO, it would be reasonable to start with 3 configurations - one configuration for each supported platform, for example: - Windows / IA32 / MSVS .NET 2003 / release - Linux / IA32 / GCC 4.0.3 / release - Linux / EM64T / GCC 4.0.3 / release There may be a contrary point - let's everyone use it's own platform - such way we'll discover bugs earlier. I think this might work good in a smaller project. The Harmony is quite a big child already and trying to kill all the birds we may chase them for ages. I'd be happy if we converge on the set of our primary target configs here. Thank you Pavel Ozhdikhin - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko 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]
[jira] Updated: (HARMONY-1763) [classlib][beans] method java.beans.PropertyDescriptor.equals(Object) throws ClassCastException
According to the good issue resolution guideline I am forwarding
this to the dev. list.
-- Forwarded message --
From: Oleg Khaschansky (JIRA) [EMAIL PROTECTED]
Date: Oct 6, 2006 8:58 PM
Subject: [jira] Updated: (HARMONY-1763) [classlib][beans] method
java.beans.PropertyDescriptor.equals(Object) throws ClassCastException
To: [EMAIL PROTECTED]
[ http://issues.apache.org/jira/browse/HARMONY-1763?page=all ]
Oleg Khaschansky updated HARMONY-1763:
--
Attachment: harmony-1763.patch
Patch for this issue rev. 453254.
[classlib][beans] method java.beans.PropertyDescriptor.equals(Object) throws
ClassCastException
---
Key: HARMONY-1763
URL: http://issues.apache.org/jira/browse/HARMONY-1763
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Oleg Khaschansky
Priority: Minor
Attachments: harmony-1763-test.patch, harmony-1763.patch
The test below throws ClassCastException on Harmony but passes on RI.
I will provide a patch for this issue and a unit test.
import java.beans.*;
import java.lang.reflect.*;
public class Test {
public static void main(String[] args) {
PropertyDescriptor toRet = null;
try {
toRet = new PropertyDescriptor(p, Bean.class );
toRet.setBound( true );
} catch (IntrospectionException e) {
e.printStackTrace();
}
Method m = null;
try {
m = HelpClass.class.getDeclaredMethod(f_static,
(Class[])null);
} catch (NoSuchMethodException e) {
e.printStackTrace();
}
toRet.equals(m);
System.out.println(PASSED);
}
}
class Bean {
public void setP(int i) {}
public int getP() {return 0;}
}
class HelpClass {
public HelpClass () {}
public static void f_static () {}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test] Site to collect classlib test statistics
2006/10/6, Anton Luht [EMAIL PROTECTED]: Hello, Those 554 errors on interpreter are due to fork mode=once, it is a single error affecting the whole run. Is there a way to delete an uploaded run? I've added a possibility to delete run for a registered user. Please send me login/password if you want to have such possibility. Better yet, to be able select a range of runs to include to analysis. The appetite comes with eating :) Criteria to select can vary, one of many possible is execution engine - it would be nice to have such characteristic of a run ... The latest Web 2.0 fashion trend is to use tags for this (same as keywords in Bugzilla) :) Will it do for you if tags support is implemented? Examples of tags I can can think of are: msvc, gcc, Linux, Windows, SP2, RedHat, Single_Core, Multi_Core, etc. We can have an editable list to avoid typos but to be able to add new tags easily. Yes, I think this would do the job. Let's try and see how to make it convenient. The filter settings better be persistent, to ease browsing. BTW, it would be nice to remember previous values on upload page too - e.g. my name don't change that often to retype it each time :) Alexey, I've added both options - search by test name and list of tests that ever failed. The second one is very big because of results you've uploaded for DRLVM/Linux with 554 errors. Please tell me if you want to change anything in the interface. On 10/6/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Anton, Many thanks for exploring this area, it looks quite promising. An idea: this service would become more valuable if presented transparent search/comparison of results for particular tests over all uploaded runs. Let user enter name of a test and show in one table all known results for this test, or even better, provide a table of all ever failed tests with links to individual consolidated tables. This would help analyzing failures very much. -- Regards, Alexey 2006/10/4, Anton Luht [EMAIL PROTECTED]: Hello, Could you tell about it in more detail? 1) Who can upload test results? Everyone - no authorization is needed, you can include file upload to your regular builds if you want - authorized users can remove them later if something goes wrong :) If you want to modify uploaded tests' data - add JIRA issues to failures, add comments, etc - please send me login/password and I'll create an account. 2) How are you going to develop this site, structure, data base and etc.? I'll try to implement all feature requests that community members will express. One of possible directions I see is support for new test suites - currently it recognises only Harmony classlib JUnit tests output. If you have another test suite you want to upload to that site - just send me an archive and I'll try to add support for this kind of tests. Sources of that app are not in SVN now - if you want to review/fix/improve something - I can send you an archive. -- Regards, Anton Luht, 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] -- Regards, Anton Luht, 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] -- Regards, Anton Luht, 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]
Re: [general] define pre-commit testing configs to gain the stability
Alexey, No, I'm not sure the committers have all the configurations. I think most of all have Windows and Linux IA32, but I doubt all of them have EM64T. This is indeed the problem and I hope together we will find the solution. For example, we may not require classlib commits to be tested on EM64T for now, or check if Apache has machines for testing, or we'll have a magic tool which will run EM64T tests for all committers on some hidden machine etc. If finally we realize that it's impossible to require EM64T testing at this time, we can delay this particular config, but regarding remaining criteria I think we can avoid many problems using primary target configs. Thanks, Pavel On 10/6/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Pavel, Your idea has sence. But... Are you sure that all the committers has all the mentioned configurations? SY, Alexey 2006/10/6, Pavel Ozhdikhin [EMAIL PROTECTED]: Hello all, This thread is about a way to improve stability in the environment of growing patch flow in Harmony. Originally I though about DRLVM issues but this may be helpful for classlib too. Currenly, before committing a patch a committer checks it on his favorite configurations (I mean architecture, OS and compiler first of all). Another committer checks another patch on a different set of configurations. As a result, though both patches are tested, there is no guarantee that they will work together on any configuration. If we agree on common testing configs we can make sure the Harmony will be stable on at least this set of configurations. This does not mean we won't fix problems on other configurations. The goal is to gain and maintain general stability. Another benefit would be in faster adoption of patches. If contributors could check their patches on the same configs as the committers do, there would be less likely a particular patch is rejected. I propose to work out a set of configs the committers will use to check patches before committing them to SVN. We can start with a few configs defining the platform, OS familly and the compiler used. When we are sure the Harmony is stable we can add more configurations. IMO, it would be reasonable to start with 3 configurations - one configuration for each supported platform, for example: - Windows / IA32 / MSVS .NET 2003 / release - Linux / IA32 / GCC 4.0.3 / release - Linux / EM64T / GCC 4.0.3 / release There may be a contrary point - let's everyone use it's own platform - such way we'll discover bugs earlier. I think this might work good in a smaller project. The Harmony is quite a big child already and trying to kill all the birds we may chase them for ages. I'd be happy if we converge on the set of our primary target configs here. Thank you Pavel Ozhdikhin - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko 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]
Re: [jira] Updated: (HARMONY-1763) [classlib][beans] method java.beans.PropertyDescriptor.equals(Object) throws ClassCastException
Oleg,
Can we write the same logic a little bit nicer?
Something like:
public boolean equals(Object object) {
-boolean result = (object != null object instanceof
PropertyDescriptor);
-if (result) {
+boolean result = false;
+
+if (object != null object instanceof PropertyDescriptor) {
PropertyDescriptor pd = (PropertyDescriptor) object;
Anyway +1 for the patch in general, thank you for finding this!
Regards,
2006/10/6, Oleg Khaschansky [EMAIL PROTECTED]:
According to the good issue resolution guideline I am forwarding
this to the dev. list.
-- Forwarded message --
From: Oleg Khaschansky (JIRA) [EMAIL PROTECTED]
Date: Oct 6, 2006 8:58 PM
Subject: [jira] Updated: (HARMONY-1763) [classlib][beans] method
java.beans.PropertyDescriptor.equals(Object) throws ClassCastException
To: [EMAIL PROTECTED]
[ http://issues.apache.org/jira/browse/HARMONY-1763?page=all ]
Oleg Khaschansky updated HARMONY-1763:
--
Attachment: harmony-1763.patch
Patch for this issue rev. 453254.
[classlib][beans] method java.beans.PropertyDescriptor.equals(Object) throws
ClassCastException
---
Key: HARMONY-1763
URL: http://issues.apache.org/jira/browse/HARMONY-1763
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Oleg Khaschansky
Priority: Minor
Attachments: harmony-1763-test.patch, harmony-1763.patch
The test below throws ClassCastException on Harmony but passes on RI.
I will provide a patch for this issue and a unit test.
import java.beans.*;
import java.lang.reflect.*;
public class Test {
public static void main(String[] args) {
PropertyDescriptor toRet = null;
try {
toRet = new PropertyDescriptor(p, Bean.class );
toRet.setBound( true );
} catch (IntrospectionException e) {
e.printStackTrace();
}
Method m = null;
try {
m = HelpClass.class.getDeclaredMethod(f_static,
(Class[])null);
} catch (NoSuchMethodException e) {
e.printStackTrace();
}
toRet.equals(m);
System.out.println(PASSED);
}
}
class Bean {
public void setP(int i) {}
public int getP() {return 0;}
}
class HelpClass {
public HelpClass () {}
public static void f_static () {}
}
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test] Site to collect classlib test statistics
Vera, I'm not sure I understood your intention. Do you want to monitor regressions routinely a la CruiseControl? Or you need an automated failure analyzer which bisects commits and finds flawed commit? 2006/10/6, Volynets, Vera [EMAIL PROTECTED]: Alexey, Thank you for your response. As I understood I'm working on the same problem, I write scripts to run different tests(cunit, classlib, smoke, kernel, specjvm98) and collect statistics. I do it to track patch which was reason of failure of any test. So bug propagation would be stopped. The final result is presented like table with name and state (passed/failed). My next step was to use mysql database, php and Apache server to make my system user-friendly. Also I need to think out algorithm to find guilty revision. Now I run tests only on Windows and only on my machine. I think it's a good idea to keep in touch and collaborate! It's useful to have this system on Harmony, because each contributor can see how his patch effect the virtual machine!!! With best regards, Vera! -Original Message- From: Alexey Varlamov [mailto:[EMAIL PROTECTED] Sent: Friday, October 06, 2006 4:14 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][test] Site to collect classlib test statistics Thanks for prompt response! Those 554 errors on interpreter are due to fork mode=once, it is a single error affecting the whole run. Is there a way to delete an uploaded run? Better yet, to be able select a range of runs to include to analysis. The appetite comes with eating :) Criteria to select can vary, one of many possible is execution engine - it would be nice to have such characteristic of a run ... 2006/10/6, Anton Luht [EMAIL PROTECTED]: Alexey, I've added both options - search by test name and list of tests that ever failed. The second one is very big because of results you've uploaded for DRLVM/Linux with 554 errors. Please tell me if you want to change anything in the interface. On 10/6/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Anton, Many thanks for exploring this area, it looks quite promising. An idea: this service would become more valuable if presented transparent search/comparison of results for particular tests over all uploaded runs. Let user enter name of a test and show in one table all known results for this test, or even better, provide a table of all ever failed tests with links to individual consolidated tables. This would help analyzing failures very much. -- Regards, Alexey 2006/10/4, Anton Luht [EMAIL PROTECTED]: Hello, Could you tell about it in more detail? 1) Who can upload test results? Everyone - no authorization is needed, you can include file upload to your regular builds if you want - authorized users can remove them later if something goes wrong :) If you want to modify uploaded tests' data - add JIRA issues to failures, add comments, etc - please send me login/password and I'll create an account. 2) How are you going to develop this site, structure, data base and etc.? I'll try to implement all feature requests that community members will express. One of possible directions I see is support for new test suites - currently it recognises only Harmony classlib JUnit tests output. If you have another test suite you want to upload to that site - just send me an archive and I'll try to add support for this kind of tests. Sources of that app are not in SVN now - if you want to review/fix/improve something - I can send you an archive. -- Regards, Anton Luht, 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] -- Regards, Anton Luht, 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] - Terms of use :
Re: [general] define pre-commit testing configs to gain the stability
I only have Windows/MSVC2003/IA32, if you're looking for anecdotal evidence. On 10/6/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: Alexey, No, I'm not sure the committers have all the configurations. I think most of all have Windows and Linux IA32, but I doubt all of them have EM64T. This is indeed the problem and I hope together we will find the solution. For example, we may not require classlib commits to be tested on EM64T for now, or check if Apache has machines for testing, or we'll have a magic tool which will run EM64T tests for all committers on some hidden machine etc. If finally we realize that it's impossible to require EM64T testing at this time, we can delay this particular config, but regarding remaining criteria I think we can avoid many problems using primary target configs. Thanks, Pavel On 10/6/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Pavel, Your idea has sence. But... Are you sure that all the committers has all the mentioned configurations? SY, Alexey 2006/10/6, Pavel Ozhdikhin [EMAIL PROTECTED]: Hello all, This thread is about a way to improve stability in the environment of growing patch flow in Harmony. Originally I though about DRLVM issues but this may be helpful for classlib too. Currenly, before committing a patch a committer checks it on his favorite configurations (I mean architecture, OS and compiler first of all). Another committer checks another patch on a different set of configurations. As a result, though both patches are tested, there is no guarantee that they will work together on any configuration. If we agree on common testing configs we can make sure the Harmony will be stable on at least this set of configurations. This does not mean we won't fix problems on other configurations. The goal is to gain and maintain general stability. Another benefit would be in faster adoption of patches. If contributors could check their patches on the same configs as the committers do, there would be less likely a particular patch is rejected. I propose to work out a set of configs the committers will use to check patches before committing them to SVN. We can start with a few configs defining the platform, OS familly and the compiler used. When we are sure the Harmony is stable we can add more configurations. IMO, it would be reasonable to start with 3 configurations - one configuration for each supported platform, for example: - Windows / IA32 / MSVS .NET 2003 / release - Linux / IA32 / GCC 4.0.3 / release - Linux / EM64T / GCC 4.0.3 / release There may be a contrary point - let's everyone use it's own platform - such way we'll discover bugs earlier. I think this might work good in a smaller project. The Harmony is quite a big child already and trying to kill all the birds we may chase them for ages. I'd be happy if we converge on the set of our primary target configs here. Thank you Pavel Ozhdikhin - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko 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]
Re: [classlib] clash in eclipse metadata
Realistically, we could probably just eliminate all of the Eclipse IDE files, as they don't really work out of the box anyway, so I always end up tweaking them anyway or tweaking my setup. For those who do use Eclipse IDE, a simple script could be create to generate the appropriate artifacts or it can be done manually. Then we can just add these files to the ignore list. BTW - The way I use the Eclipse IDE is to setup a custom Target Platform (a set of folders that contains OSGi bundles/plugins) that points to the deploy folder build and the support JAR. This assumes you've run a full build or have a snapshot build. Then, in each project's .classpath, the Required Plugins container and the JUNIT variable are set. The Required Plugins just takes the current project's Import-Packages attribute from the manifest and looks at all of the plugins in the Target Platform and resolves the appropriate JARs, so the code can compile. The JUNIT variable is for resolving the JUnit classes, since this isn't explicitly in the OSGi bundles. -Nathan On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I have a problem with how we do eclipse meta-data in classlib, and I'm guessing there's some cool trick everyone else knows about. Right now, tree has lots of mods to modules/*/.settings/* and modules/*/.classpath, resulting in pain and suffering when I try to do a commit that spans multiple modules. How are people solving this? geir - 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]
Re: [general] define pre-commit testing configs to gain the stability
I'm also not sure that ALL the commiters has Windows and Linux at the same time... And Nathan is an example :) SY, Alexey 2006/10/6, Pavel Ozhdikhin [EMAIL PROTECTED]: Alexey, No, I'm not sure the committers have all the configurations. I think most of all have Windows and Linux IA32, but I doubt all of them have EM64T. This is indeed the problem and I hope together we will find the solution. For example, we may not require classlib commits to be tested on EM64T for now, or check if Apache has machines for testing, or we'll have a magic tool which will run EM64T tests for all committers on some hidden machine etc. If finally we realize that it's impossible to require EM64T testing at this time, we can delay this particular config, but regarding remaining criteria I think we can avoid many problems using primary target configs. Thanks, Pavel On 10/6/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Pavel, Your idea has sence. But... Are you sure that all the committers has all the mentioned configurations? SY, Alexey 2006/10/6, Pavel Ozhdikhin [EMAIL PROTECTED]: Hello all, This thread is about a way to improve stability in the environment of growing patch flow in Harmony. Originally I though about DRLVM issues but this may be helpful for classlib too. Currenly, before committing a patch a committer checks it on his favorite configurations (I mean architecture, OS and compiler first of all). Another committer checks another patch on a different set of configurations. As a result, though both patches are tested, there is no guarantee that they will work together on any configuration. If we agree on common testing configs we can make sure the Harmony will be stable on at least this set of configurations. This does not mean we won't fix problems on other configurations. The goal is to gain and maintain general stability. Another benefit would be in faster adoption of patches. If contributors could check their patches on the same configs as the committers do, there would be less likely a particular patch is rejected. I propose to work out a set of configs the committers will use to check patches before committing them to SVN. We can start with a few configs defining the platform, OS familly and the compiler used. When we are sure the Harmony is stable we can add more configurations. IMO, it would be reasonable to start with 3 configurations - one configuration for each supported platform, for example: - Windows / IA32 / MSVS .NET 2003 / release - Linux / IA32 / GCC 4.0.3 / release - Linux / EM64T / GCC 4.0.3 / release There may be a contrary point - let's everyone use it's own platform - such way we'll discover bugs earlier. I think this might work good in a smaller project. The Harmony is quite a big child already and trying to kill all the birds we may chase them for ages. I'd be happy if we converge on the set of our primary target configs here. Thank you Pavel Ozhdikhin - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko 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] -- Alexey A. Petrenko 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]
Re: [general] define pre-commit testing configs to gain the stability
What would you do if you need to commit a patch to some Linux-specific code in VM? The commit criteria my be either as simple as a list of configs or have also some exclusions. For example, there is no much sense to test on Linux a patch for a source file which is not even compiled on Windows. On 10/7/06, Nathan Beyer [EMAIL PROTECTED] wrote: I only have Windows/MSVC2003/IA32, if you're looking for anecdotal evidence. On 10/6/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: Alexey, No, I'm not sure the committers have all the configurations. I think most of all have Windows and Linux IA32, but I doubt all of them have EM64T. This is indeed the problem and I hope together we will find the solution. For example, we may not require classlib commits to be tested on EM64T for now, or check if Apache has machines for testing, or we'll have a magic tool which will run EM64T tests for all committers on some hidden machine etc. If finally we realize that it's impossible to require EM64T testing at this time, we can delay this particular config, but regarding remaining criteria I think we can avoid many problems using primary target configs. Thanks, Pavel On 10/6/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Pavel, Your idea has sence. But... Are you sure that all the committers has all the mentioned configurations? SY, Alexey 2006/10/6, Pavel Ozhdikhin [EMAIL PROTECTED]: Hello all, This thread is about a way to improve stability in the environment of growing patch flow in Harmony. Originally I though about DRLVM issues but this may be helpful for classlib too. Currenly, before committing a patch a committer checks it on his favorite configurations (I mean architecture, OS and compiler first of all). Another committer checks another patch on a different set of configurations. As a result, though both patches are tested, there is no guarantee that they will work together on any configuration. If we agree on common testing configs we can make sure the Harmony will be stable on at least this set of configurations. This does not mean we won't fix problems on other configurations. The goal is to gain and maintain general stability. Another benefit would be in faster adoption of patches. If contributors could check their patches on the same configs as the committers do, there would be less likely a particular patch is rejected. I propose to work out a set of configs the committers will use to check patches before committing them to SVN. We can start with a few configs defining the platform, OS familly and the compiler used. When we are sure the Harmony is stable we can add more configurations. IMO, it would be reasonable to start with 3 configurations - one configuration for each supported platform, for example: - Windows / IA32 / MSVS .NET 2003 / release - Linux / IA32 / GCC 4.0.3 / release - Linux / EM64T / GCC 4.0.3 / release There may be a contrary point - let's everyone use it's own platform - such way we'll discover bugs earlier. I think this might work good in a smaller project. The Harmony is quite a big child already and trying to kill all the birds we may chase them for ages. I'd be happy if we converge on the set of our primary target configs here. Thank you Pavel Ozhdikhin - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][GC] first generational version of GCv5 is submitted
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Weldon Washburn wrote: On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Can you make it selectable for build? IOW sh build.sh -Dbuild.gc=5 or something... Good idea. Maybe even better would be to have ALL gc's always build and make them selectable on the command line. Well, I was thinking more about just building w/ the GC you chose. Seems to be less internal framework for plugging it in right now. On second thought, you are right. I don't really should not be hacking on the framework right now. But at some point, we need to have the GC selectable at the command line. geir
Re: [general] define pre-commit testing configs to gain the stability
On 10/7/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: What would you do if you need to commit a patch to some Linux-specific code in VM? The commit criteria my be either as simple as a list of configs or have also some exclusions. For example, there is no much sense to test on Linux a patch for a source file which is not even compiled on Windows. I meant not even compiled on Linux, of course. :) On 10/7/06, Nathan Beyer [EMAIL PROTECTED] wrote: I only have Windows/MSVC2003/IA32, if you're looking for anecdotal evidence. On 10/6/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: Alexey, No, I'm not sure the committers have all the configurations. I think most of all have Windows and Linux IA32, but I doubt all of them have EM64T. This is indeed the problem and I hope together we will find the solution. For example, we may not require classlib commits to be tested on EM64T for now, or check if Apache has machines for testing, or we'll have a magic tool which will run EM64T tests for all committers on some hidden machine etc. If finally we realize that it's impossible to require EM64T testing at this time, we can delay this particular config, but regarding remaining criteria I think we can avoid many problems using primary target configs. Thanks, Pavel On 10/6/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Pavel, Your idea has sence. But... Are you sure that all the committers has all the mentioned configurations? SY, Alexey 2006/10/6, Pavel Ozhdikhin [EMAIL PROTECTED]: Hello all, This thread is about a way to improve stability in the environment of growing patch flow in Harmony. Originally I though about DRLVM issues but this may be helpful for classlib too. Currenly, before committing a patch a committer checks it on his favorite configurations (I mean architecture, OS and compiler first of all). Another committer checks another patch on a different set of configurations. As a result, though both patches are tested, there is no guarantee that they will work together on any configuration. If we agree on common testing configs we can make sure the Harmony will be stable on at least this set of configurations. This does not mean we won't fix problems on other configurations. The goal is to gain and maintain general stability. Another benefit would be in faster adoption of patches. If contributors could check their patches on the same configs as the committers do, there would be less likely a particular patch is rejected. I propose to work out a set of configs the committers will use to check patches before committing them to SVN. We can start with a few configs defining the platform, OS familly and the compiler used. When we are sure the Harmony is stable we can add more configurations. IMO, it would be reasonable to start with 3 configurations - one configuration for each supported platform, for example: - Windows / IA32 / MSVS .NET 2003 / release - Linux / IA32 / GCC 4.0.3 / release - Linux / EM64T / GCC 4.0.3 / release There may be a contrary point - let's everyone use it's own platform - such way we'll discover bugs earlier. I think this might work good in a smaller project. The Harmony is quite a big child already and trying to kill all the birds we may chase them for ages. I'd be happy if we converge on the set of our primary target configs here. Thank you Pavel Ozhdikhin - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] define pre-commit testing configs to gain the stability
2006/10/6, Pavel Ozhdikhin [EMAIL PROTECTED]: What would you do if you need to commit a patch to some Linux-specific code in VM? And I do not have Linux? I will not commit this patch of course. And will ask another committer to do this. Pavel, again. I understand your concern and I think that testing a patch different platforms is really good approach. But I'm afraid that it is unreal to set this as a requirement for all the commiters and all the patches. But this is should not be a big problem. Because we have a regression tests. So if one committer commits something on Linux and accidentally breaks something on Windows another community member will catch it. The commit criteria my be either as simple as a list of configs or have also some exclusions. For example, there is no much sense to test on Linux a patch for a source file which is not even compiled on Windows. On 10/7/06, Nathan Beyer [EMAIL PROTECTED] wrote: I only have Windows/MSVC2003/IA32, if you're looking for anecdotal evidence. On 10/6/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: Alexey, No, I'm not sure the committers have all the configurations. I think most of all have Windows and Linux IA32, but I doubt all of them have EM64T. This is indeed the problem and I hope together we will find the solution. For example, we may not require classlib commits to be tested on EM64T for now, or check if Apache has machines for testing, or we'll have a magic tool which will run EM64T tests for all committers on some hidden machine etc. If finally we realize that it's impossible to require EM64T testing at this time, we can delay this particular config, but regarding remaining criteria I think we can avoid many problems using primary target configs. Thanks, Pavel On 10/6/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Pavel, Your idea has sence. But... Are you sure that all the committers has all the mentioned configurations? SY, Alexey 2006/10/6, Pavel Ozhdikhin [EMAIL PROTECTED]: Hello all, This thread is about a way to improve stability in the environment of growing patch flow in Harmony. Originally I though about DRLVM issues but this may be helpful for classlib too. Currenly, before committing a patch a committer checks it on his favorite configurations (I mean architecture, OS and compiler first of all). Another committer checks another patch on a different set of configurations. As a result, though both patches are tested, there is no guarantee that they will work together on any configuration. If we agree on common testing configs we can make sure the Harmony will be stable on at least this set of configurations. This does not mean we won't fix problems on other configurations. The goal is to gain and maintain general stability. Another benefit would be in faster adoption of patches. If contributors could check their patches on the same configs as the committers do, there would be less likely a particular patch is rejected. I propose to work out a set of configs the committers will use to check patches before committing them to SVN. We can start with a few configs defining the platform, OS familly and the compiler used. When we are sure the Harmony is stable we can add more configurations. IMO, it would be reasonable to start with 3 configurations - one configuration for each supported platform, for example: - Windows / IA32 / MSVS .NET 2003 / release - Linux / IA32 / GCC 4.0.3 / release - Linux / EM64T / GCC 4.0.3 / release There may be a contrary point - let's everyone use it's own platform - such way we'll discover bugs earlier. I think this might work good in a smaller project. The Harmony is quite a big child already and trying to kill all the birds we may chase them for ages. I'd be happy if we converge on the set of our primary target configs here. Thank you Pavel Ozhdikhin - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko 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 :
Re: [classlib] clash in eclipse metadata
I think it would be nice if we had examples in bundle form of different usage models. We could drop those into SVN too,a nd people could just take them and overlay... geir Nathan Beyer wrote: Realistically, we could probably just eliminate all of the Eclipse IDE files, as they don't really work out of the box anyway, so I always end up tweaking them anyway or tweaking my setup. For those who do use Eclipse IDE, a simple script could be create to generate the appropriate artifacts or it can be done manually. Then we can just add these files to the ignore list. BTW - The way I use the Eclipse IDE is to setup a custom Target Platform (a set of folders that contains OSGi bundles/plugins) that points to the deploy folder build and the support JAR. This assumes you've run a full build or have a snapshot build. Then, in each project's .classpath, the Required Plugins container and the JUNIT variable are set. The Required Plugins just takes the current project's Import-Packages attribute from the manifest and looks at all of the plugins in the Target Platform and resolves the appropriate JARs, so the code can compile. The JUNIT variable is for resolving the JUnit classes, since this isn't explicitly in the OSGi bundles. -Nathan On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I have a problem with how we do eclipse meta-data in classlib, and I'm guessing there's some cool trick everyone else knows about. Right now, tree has lots of mods to modules/*/.settings/* and modules/*/.classpath, resulting in pain and suffering when I try to do a commit that spans multiple modules. How are people solving this? geir - 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]
