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: [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: [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: [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: [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
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] 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] 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: [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
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)
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][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]
[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]
[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: 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
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
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]
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] 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
[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: [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]
Re: [general] define pre-commit testing configs to gain the stability
Pavel Ozhdikhin wrote: What would you do if you need to commit a patch to some Linux-specific code in VM? Ask someone w/ a linux box to check 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 : 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
Rana Dasgupta wrote: On 10/6/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: 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. 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 We need to check both release and debug builds...the binaries and timing characteristics are too different. At this immediate stage of the project, I would suggest leaving out EM64T as part of mandatory testing( unless it is EM64T specific functionality, eg., codegen ). Too few contributors and committers have access to it. We are not yet at a stage where we can make this mandatory. I have a machine now :) I will be EM64T-ing all the live-long day! If possible all submissions should be tested( by submitters ) on all the combinations identified . It is actually more urgent for submitters to do this. We should stop patches by email. We don't really accept them. Also, at this point, it is an honor system, we can't attach 6 before and after test logs to each JIRA submission. The committer could randomly check on one or more combination, ...the more the better obviously. I think that just having a submitter note which platforms have been tested is good. Having others test and note their results is good too. Best is getting community CI systems set up. That EM64T system will be for that, and I'll have a linux 32 bit machine also doing it. In some cases, submissions will be platform specific ( eg., very new code like GC V5, platform specific bug fixes or a simple case of developer not having all the machines ). I would leave these to the committers' discretion. Thanks. - 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] Dynamic class loading
Stefano Mazzocchi wrote: Fedotov, Alexei A wrote: Hello, Nathan, Had Nikolay said anything about JVM modification? As far as I understand him the class library should be just enhanced with this smart class loader. Now imagine how our reproducers would look in JIRA: java -cp http://svn.apache.org/... -Djava.system.class.loader=org.apache.harmony.Nikolagent TestClass Just cut paste it in your console with Harmony JRE in PATH! Like I said, this can be done *already* with a loader written in java that wraps around the system classloader without having to modify *anything* in the way the java system runs. Not that I'm against something like the above, but I'm not really happy about introducing harmony enhancements before we pass certification. As you note, this is something that can be included at application level, and there is no reason to bundle it with a JDK/JRE. And, as you note, there are no plans to deviate from the standard JDK/JRE package right now... 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: [infra] does anybody have a server to donate...
Stefano Mazzocchi wrote: ... to run Gump for harmony? Doesn't need to be fast and doesn't need to be expensive, just be able to stand the cpus and disks running all day and night and have some 100Gb of disk and some 512Mb of RAM. Anyone? Yes - when I get that machine I got today setup, I'll ping you. I'll get as much disk as I can in there... 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: [classlib] manifest information
Tim Ellison wrote: Alexey Petrenko wrote: We also need to keep Import-Package section up to date... For sure, and (just to be clear to all) these are not just for Eclipse's benefit, they are for our benefit as they are the definition of our class library modularity. When you add a new Import or Export you are changing the module's interface and potentially adding new coupling. It should not be undertaken lightly. I appreciate that it is hard to maintain the module boundaries if you don't use a tool like Eclipse that warns you if you reach outside the module definition; and we should consider adding such a check into the automated build. Therefore, I'd not be in favour of automatically updating the Imports and Exports in the manifest -- it would hide any widening of the inter-module dependencies and we could end up with the spaghetti code evident in 'other popular implementations of the spec'. Right - I was going to say similar. I think that the import/export should be changed by deliberate decisions by humans... The data is unique to that manifest too. geir Regards, Tim 2006/10/5, Geir Magnusson Jr. [EMAIL PROTECTED]: Can we consider making the final manifest that goes into our jars to be created/updated dynamically? I just went through all manifests and added Specification-Version, Implementation-Version, etc and they will change, at least the last one. I know the Eclipse people depend on them, so maybe can we used ant's filtering to set the Impl-Version dynamically? Or something like that? 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: [classlib] manifest information
Stepan Mishura wrote: On 10/5/06, Tim Ellison wrote: Alexey Petrenko wrote: We also need to keep Import-Package section up to date... For sure, and (just to be clear to all) these are not just for Eclipse's benefit, they are for our benefit as they are the definition of our class library modularity. When you add a new Import or Export you are changing the module's interface and potentially adding new coupling. It should not be undertaken lightly. Hi Tim, I've just realized that I don't really understand why we should add tests' dependencies to manifest. I guess that I missed something. I've looked through harmony-dev mail archive but I haven't find answer. Could you give me a hint where to look at? I asked that a while ago, and it's still an outstanding question. I really don't mind them there, but seems it would be cleaner if we had a second manifest for the test jars or something... Thanks, Stepan. I appreciate that it is hard to maintain the module boundaries if you don't use a tool like Eclipse that warns you if you reach outside the module definition; and we should consider adding such a check into the automated build. Therefore, I'd not be in favour of automatically updating the Imports and Exports in the manifest -- it would hide any widening of the inter-module dependencies and we could end up with the spaghetti code evident in 'other popular implementations of the spec'. Regards, Tim 2006/10/5, Geir Magnusson Jr. [EMAIL PROTECTED]: Can we consider making the final manifest that goes into our jars to be created/updated dynamically? I just went through all manifests and added Specification-Version, Implementation-Version, etc and they will change, at least the last one. I know the Eclipse people depend on them, so maybe can we used ant's filtering to set the Impl-Version dynamically? Or something like that? 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] creation of jdktools
indeed :) Alexei Zakharov wrote: Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd BTW, we have more tools indeed. I mean RMI tools: rmic - java org.apache.harmony.rmi.compiler.Main rmid - java org.apache.harmony.rmi.activation.Rmid rmiregistry - java org.apache.harmony.rmi.registry.RegistryImpl We can hack the launcher to enable these three tools too. Seven tools is more than just four. :) Regards, 2006/10/2, Geir Magnusson Jr. [EMAIL PROTECTED]: Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd like to organize these and add them to the next snapshot. So I propose adding a new top-level directory called jdktools (and rename tools to project_tools) and create a build target that - with a dependency on classlib for the launcher - creates the 'stuff' needed to fill into the JDK. Any comments? 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: [classlib] Trying to catch patternset errors earlier
Before you do that... you would be putting similar information in the
build.xml file? Or am I misunderstanding something? having it in the
patternset does make it easy to find stuff :)
geir
Mark Hindess wrote:
Ok. There haven't been any shouts against it so. I'm going to split
the .java files that contain two classes and then dump the patternsets.
Regards,
Mark.
On 3 October 2006 at 11:27, Oliver Deakin [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
On 28 September 2006 at 14:58, Alexey Petrenko [EMAIL PROTECTED]
om wrote:
2006/9/28, Mark Hindess [EMAIL PROTECTED]:
On 28 September 2006 at 14:30, Alexey Petrenko [EMAIL PROTECTED]
.c
om wrote:
I think that it will be better to add another target to build for
this check.
Because of two reasons:
1. It is unclear that clean is also checks something
This simple check can only happen part way through the clean target -
after the modules have done their cleaning and before the top-level
cleanup is done.
I see your point.
But let's review the sitatuation from another viewpoint...
What do we need in general?
We need up-to-date list of all packages in the specified module. Right?
If so we can create simple script to update patternset files... Or
even create them at build time. But will cost us build time itself :)
That's a reasonable point. I had a look at what it would take to get
rid of the patternsets completely. It's quite easy for some modules.
For example, for accessibility, we can just replace the classes
fileset with:
fileset id=classes dir=${hy.build}
or
present targetdir=${hy.accessibility.src.main.java} /
present targetdir=${hy.accessibility.src.main.java}
mapper type=regexp
from=^(.*?)(\$$[^/\\\.]*)?\.class$$
to=\1.java/
/present
/or
/fileset
Which basically says include files if they are also present in
the source directory - typically resource files - or if they are
.class files and have an obviously-named source file in the source
directory[0].
+1 to building the patternset on the fly rather than relying on file
lists being manually
kept up to date. I can't see any reason for keeping the patternset files.
This works for most modules. The present tags are duplicated for
modules with platform source directories.
However, it doesn't work very well for awt, beans, jndi, luni, and
security. Why? Because they have some source files defining two
classes. For instance, java.awt.ContextImpl defined in:
modules/awt/src/main/java/common/java/awt/Component.java
We could hardcode these special case - there are only a few. Or perhaps
we could split them in to distinct source files?
I'd go for splitting them out into separate files - hardcoding them
means that you're still
keeping a manual file list for those classes. Does anyone have an issue
with separating
these classes out?
I have some patches ready to make this change but I've not committed
anything.
Personally I think getting rid of the patternsets would be a good idea
since it reduces the coupling - although really the coupling is only
strictly necessary for luni and security.
It is important to note that even if we do something like this, leaving
the catch-all check in the clean target still helps stop problems - if
people forget to add the hardcoded special cases or if we split them
people add new source defining two classes in one file.
Agreed - keeping the clean target check helps us make sure that no one
breaks the
jar packaging in the future. As long as it completes the clean before
failing, that's
fine.
Regards,
Oliver
Regards,
Mark.
[0] The simpler 'mapper type=glob from=*.class to=*.java'
doesn't work because it misses inner classes.
2006/9/28, Mark Hindess [EMAIL PROTECTED]:
On 28 September 2006 at 11:07, Tim Ellison [EMAIL PROTECTED] wrot
e:
Sounds reasonable. The alternative is to not make clean fail, just
print the warning and tidy up the remainder. That may be too easy to
ignore though.
Yes. I considered that and had the same concern. Even if I wrote the
code to print the warning, I think I'd ignore it since it would scroll
too quickly off the top of my screen at the beginning of the build.
-Mark.
Regards,
Tim
Mark Hindess wrote:
Yesterday, while looking at something unrelated, I noticed that som
e
of the patternsets that are used to select the jars for the classli
b
modules were not up to date with the result that some classes would
be
missing from the resulting jars[0].
While it makes me slightly uneasy having a clean target that might
fail
,
it turns out that this is one place where it is quite easy to check
whether the patternsets are out of date. (Because if after the mod
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
can we get a green light from Andrey and any others in the conversation? geir Evgueni Brevnov wrote: Hi, I'm working on restoring cunit tests. I already made a good progress in that direction. So I expect to have it done soon Evgueni On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 10/4/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I assume you intend that only the latest patch is applied? Yes. invocation_api.5.patch only. (And I assume that it would apply cleanly to SVN HEAD) I believe so. Evgueni geir Evgueni Brevnov 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 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
Re: [classlib] Recognizing lock objects
Oh, for a #define :)
Tim Ellison wrote:
Nathan Beyer wrote:
There may be value in doing this, but what's the increase in class file
overhead? Every new class that gets created for these locks ends up as
another class file that has to be stored (takes up drive space) and has to
be loaded (takes up memory in the class loader). Ever additional class file
takes up at least 1K of space on Windows.
How many of these locks are we talking about?
I haven't counted, but I'd guess 10's rather than 100's based on what I
have found so far.
Each .class files created take up about 360 bytes in the JAR file. The
size in memory is obviously dependent upon the VM implementation but I
don't expect it to be onerous (in the IBM VME it will, by coincidence,
be very roughly the same number of bytes in memory).
Regards,
Tim
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 04, 2006 6:30 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Recognizing lock objects
Mikhail Fursov wrote:
Another variant is to use anonymous class without the name:
Object lock = new Object(){};
But the name by itself (RepositionLock) serves like a comment.
Yep -- I'm inclined to keep the meaningful name.
Reagrds,
Tim
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
--
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]
-
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][depends] missing liblcms +em64t
I added all that info into the README file when I did it on windows last week. Did I forget to commit it? Ivan Volosyuk wrote: Readme is quite helpful. Yesterday, I used google to locate thouse lcms library. IMHO, if the build system displayed the link to the README.txt it could be much easier to deal with the issue. -- Ivan On 10/4/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Ivan, I went through all this a few minutes ago ( on 32 bit RedHat enterprise Linux ). The summary is that if you don't have the littlecms package, you need to download it from http:// www.littlecms.com and build and deploy it in your dependencies. See the README in depends/libs/build. Rana - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Fix compilation on Linux/x86_64
Mark, if you don't care, I'm happy to do it as I'm running through DRLVM JIRA chains now. Let me know by simply un- or re-assigning geir Mark Hindess wrote: On 5 October 2006 at 13:57, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 10/4/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: The patch turned out to be exact duplicate of HARMONY-1571. Besides, there exist a patch with fixes for unit tests: HARMONY-1574. The following change is needed on top of already committed HARMONY-1551 to make DRLVM start on Linux/x86_64. However, it still doesn't work properly, failing with java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167: Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion `!(vt() 1)' failed. The assertion failure were caused by the leftover patch from HARMONY-1372, which didn't make it to SVN (gcv41_em64t_vm_changes.diff) Yes, looks like I forget the change when I have made the last patch in the HARMONY-1372. The patch gcv41_em64t_vm_changes.diff is still in the JIRA. I can create new JIRA issue or one of the commiters can add this missing piece to svn. Geir? Unless Geir gets there first I was planning to look at this in the new JIRA http://issues.apache.org/jira/browse/HARMONY-1698 -Mark. - 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][logging] Best practices for logging within the Class Library?
Tim Ellison wrote: We did this topic already g it's even referenced from the website [1]. So at the risk of repeating my super-super-duper high level view... Why are we considering putting logging into the class library implementation? Darn it! I was hoping that I could beat you to this, by playing the straight man and setting you up so you could say this line, because I *knew* you would say this :) [and I agree] Is it for our end-users? Do we expect them to turn on logging and look at the contents to discover problems in our code? or perhaps discover problems in their usage of the API? Both of these seem like flawed concepts. Is it for us as developers? Putting printf's in the code doesn't seem like a very efficient way of figuring out how the code works, and just clutters up the codebase. I'd also object to having loads of modules depend on logging. Oh, for that #define I was talking about in the sync object thread. Actually, I'll start a new thread on this... [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/agreements.html Regards, Tim Nathan Beyer wrote: There seem to be a number of places where logging would be useful within the class library (and Java parts of the VM), but the rules of engagement seems to be undefined, so it's not being used. Here's my super-duper high-level swipe at it. 1. Use java.util.logging for normal logging (somewhat obvious). 2. Do not use java.util.logging within luni, security and kernel modules; this is to prevent cyclical executions. 3. Use the class name for the name of the Logger; this is based on the assumption that classes will be packaged appropriately such that logging can be enabled by packages to get sub-system information. 4. Use the java.util.logging.Level javadoc [1] as a guide for the appropriate logging level for a particular message. When in doubt, be conservative and use lower levels (less than INFO). Thoughts, comments? The big question in my mind is what modules must be isolated from consuming java.util.logging (regarding 2 above). The other modules that might need isolation are archive and text, but I'm not sure about that. Any others? -Nathan [1] http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/Level.html - 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] Bugs priorities
Agreed. I think that we should outline a set of guidelines, but also realize that the priority is like beauty - it's in the eyes of the reporter. I tend to troll through DRLVM JIRAs and do small things like comment or link, and one thing I'll add to my work is resetting priority based on how I see it, and defend it with a comment. Any other committer can do the same for DRLVM or any others, and if you disagree, change it and defend it. The outcome won't be perfect, and we shouldn't spend too much time arguing about priority (if you you really think it's a major problem, fix it!), but I think that this would normalize the bug priirities over time... geir Mark Hindess wrote: On 5 October 2006 at 20:05, Mikhail Fursov [EMAIL PROTECTED] wrote: The priority of the bug could be the priority of the scenario this bug affects. So, we need to select some applications/scenarios and if one of these applications failed - the bug is blocker or critical. Major as default priority is OK (imo) because it's in the middle of the list. That logic only really works for me if the distribution of bugs by priority is even. So for example we'd have as many 'critical' bugs as 'trivial' ones. I don't think (I hope!) that we do. Most of our JIRA are classified as major. Most of the bugs described in the JIRA issues are actually minor or trivial. I honestly think the classifications would better reflect reality if we changed this. Regards, Mark. On 10/5/06, Anton Luht [EMAIL PROTECTED] wrote: Hello, Salikh, I just suggest rules to be written explicitly. Every bug submitter tends to think that his bug or his application is the most important - some limits should be put to avoid 90% of bugs being major and critical. On 10/5/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Anton Luht wrote: Hello, Maybe it's worth to explicitly specify priorities for various kinds of bugs? The advice that appears now near 'priority' drop-down in JIRA list is general and not Harmony-specific. Bug submitters make decision mostly by his/her intuition. An example of rule set: VM hangs crashes - critical, Junit tests failures - major, application failures - major, exception incompatibility - minor. And what guidelines would you recommend for the corner cases, when something is important for some people, and does not matter for others? For example, some people are trying to get Harmony to run x86_64 and ia64 platforms, while most of the project participants just do not care. - 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] -- Mikhail Fursov --=_Part_20534_19790021.1160053532326-- - 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
Salikh Zakirov wrote: Hi! 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? make? 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: [classlib] Trying to catch patternset errors earlier
Mark Hindess wrote:
On 5 October 2006 at 10:05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Before you do that... you would be putting similar information in the
build.xml file? Or am I misunderstanding something? having it in the
patternset does make it easy to find stuff :)
I'll be putting something in the build.xml file ... the ant from the
accessibility example below. That is a patternset that just figures
everything out from the source tree.
Essentially it's just saying include build/classes/blah if:
1) blah is also in the source tree - a resource file for example
2) there is a corresponding blah.java file in the source tree
I've never really looked in the patternset files when trying to find
something. I'd just look in the src/main/java tree or the jar table of
contents. What do you use the patternsets for?
I've grep-ed them looking for stuff.
I wonder if it would be easy to write out a map file.
eh, never mind. We'll see if anyone cares...
geir
Regards,
Mark.
Mark Hindess wrote:
Ok. There haven't been any shouts against it so. I'm going to split
the .java files that contain two classes and then dump the patternsets.
Regards,
Mark.
On 3 October 2006 at 11:27, Oliver Deakin [EMAIL PROTECTED] wr
ote:
Mark Hindess wrote:
On 28 September 2006 at 14:58, Alexey Petrenko [EMAIL PROTECTED]
.c
om wrote:
2006/9/28, Mark Hindess [EMAIL PROTECTED]:
On 28 September 2006 at 14:30, Alexey Petrenko [EMAIL PROTECTED]
il
.c
om wrote:
I think that it will be better to add another target to build for
this check.
Because of two reasons:
1. It is unclear that clean is also checks something
This simple check can only happen part way through the clean target -
after the modules have done their cleaning and before the top-level
cleanup is done.
I see your point.
But let's review the sitatuation from another viewpoint...
What do we need in general?
We need up-to-date list of all packages in the specified module. Right?
If so we can create simple script to update patternset files... Or
even create them at build time. But will cost us build time itself :)
That's a reasonable point. I had a look at what it would take to get
rid of the patternsets completely. It's quite easy for some modules.
For example, for accessibility, we can just replace the classes
fileset with:
fileset id=classes dir=${hy.build}
or
present targetdir=${hy.accessibility.src.main.java} /
present targetdir=${hy.accessibility.src.main.java}
mapper type=regexp
from=^(.*?)(\$$[^/\\\.]*)?\.class$$
to=\1.java/
/present
/or
/fileset
Which basically says include files if they are also present in
the source directory - typically resource files - or if they are
.class files and have an obviously-named source file in the source
directory[0].
+1 to building the patternset on the fly rather than relying on file
lists being manually
kept up to date. I can't see any reason for keeping the patternset files.
This works for most modules. The present tags are duplicated for
modules with platform source directories.
However, it doesn't work very well for awt, beans, jndi, luni, and
security. Why? Because they have some source files defining two
classes. For instance, java.awt.ContextImpl defined in:
modules/awt/src/main/java/common/java/awt/Component.java
We could hardcode these special case - there are only a few. Or perhaps
we could split them in to distinct source files?
I'd go for splitting them out into separate files - hardcoding them
means that you're still
keeping a manual file list for those classes. Does anyone have an issue
with separating
these classes out?
I have some patches ready to make this change but I've not committed
anything.
Personally I think getting rid of the patternsets would be a good idea
since it reduces the coupling - although really the coupling is only
strictly necessary for luni and security.
It is important to note that even if we do something like this, leaving
the catch-all check in the clean target still helps stop problems - if
people forget to add the hardcoded special cases or if we split them
people add new source defining two classes in one file.
Agreed - keeping the clean target check helps us make sure that no one
breaks the
jar packaging in the future. As long as it completes the clean before
failing, that's
fine.
Regards,
Oliver
Regards,
Mark.
[0] The simpler 'mapper type=glob from=*.class to=*.java'
doesn't work because it misses inner classes.
2006/9/28, Mark Hindess [EMAIL PROTECTED]:
On 28 September 2006 at 11:07, Tim Ellison [EMAIL PROTECTED] wr
ot
e:
Sounds reasonable. The alternative is to not make clean fail, just
print the warning and tidy up the remainder. That may be too easy t
o
ignore though.
Yes. I
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
that.
class VM_thread {
...
+JNIEnv_Internal * jni_env;
The jthread already has the jni_env pointer, you do
not need to
duplicate it here.
forexample by using
jthread_get_JNI_env(jthread_self());
Yes I know. I don't see any problems here. Some times
it is much more
convenient to get JNIEnv from VM_thread structure (and
faster) instead
of doing jthread_get_JNI_env(jthread_self()). So I
need strong
arguments for removing it. Again it seems that should
be addressed in
design of multi VM. So lets forget about it for a
while...
I think that the data duplication would always serve as
a potential
source of errors - while updating one copy of object,
you may forget
to update the other, often resulting into a strange
behavior of the
whole application. Let's see what are the specific
performance
concerns that have to be addressed. To get VM_thread
structure, you
would eventually go to the TLS, just like
jthread_get_JNI_env(jthread_self() would do.
If there is already VM_thread structure for some reasons
then there
will be no extra access to TLS. It is definitely much more in
jthread_get_JNI_env(jthread_self() than just one TLS
access and one
dereferncing. I don't think it is a really big problem
now. Do you
agree to look at this later. I guess multi VM
implementation will
alter it in any case.
Thanks
Evgueni
Thanks,
Andrey.
Evgueni
Thanks
Artem
On 9/28/06, Evgueni Brevnov
[EMAIL PROTECTED] wrote:
I suppose two days silence means that there is no
objects (maybe
interest) against proposed patch. I would suggest
to commit it ASAP.
It really works! There are some cases when current
VM crashes but the
patch fixes it. I can work on bringing cunit tests
to live as soon as
the patch is committed This is just my
understanding.
Thanks
Evgueni
On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED]
wrote:
So where are we here?
On Sep 28, 2006, at 12:41 AM, Evgueni Brevnov
wrote:
On 9/28/06, Weldon Washburn
[EMAIL PROTECTED] wrote:
On 9/26/06, Evgueni Brevnov
[EMAIL PROTECTED] wrote:
On 9/27/06, Andrey Chernyshev
[EMAIL PROTECTED] wrote:
(3)
One more lock is added -
hythread_lib_lock. How is that differ
from
the hythread_global_lock that we already
have? Each extra lock
to the
system may add more possibilities for
deadlocks, as well as can
negatively impact the scalability (unless
some of the existing
locks
are split).
hythread_lib_lock acquires exactly the same
lock as
hythread_global_lock. Probably I miss
something but we need to be
compatible with IBM threading library now.
This library has such
function. That's why I added it. Sounds right?
Well, this sort of, kind of sounds right but
not quite. Its a
little more
subtle than being compatible with IBM
threading library. The
first goal is
to identify the parts of IBM threading
library that are JVM
independent. It
makes sense for DRLVM to be compatible with
the independent
parts. This
should be a nobrainer.
The parts of IBM threading library that
assume a specific JVM
implementation
will be a problem. We will need to find a
solution that is
endorsed by all
the stakeholders (including J9 folks). The
hythread_global_lock
falls into
this category. For starts, I would like to
see a concise
description from
the portlib owners on what
hythread_global_lock protects, which
locks have
to be held before grabbing this lock, are
there any restrictions
on what
system calls can be made while holding this
lock (like sleep or
wait), etc.
Weldon, I completely agree with what your are
saying. It's common
problem of current hythread that should be
resolved some how. I just
go inline with current implementation and
added two missing functions.
Missing these can lead to the same problems as
with hythread_exit
discussed in another thread [drlvm]
[launcher] Executable hangs.
To get a better idea what's in the
patch.diff, I printed
Re: Wonka, Mika, and Apache
Stefano Mazzocchi wrote: Chris Gray wrote: Chris, I personally think it would be *very* nice to have Wonka and friends donated to the Harmony Project, if only as a starting point for a very portable and embeddable JVM. While Harmony is principally aimed at Java Standard Edition, it is not a secret that many of us would like to continue on with Java Mobile Edition once the standard edition is certified. Don't forget that you can have an embeddable SE - it doesn't have to be ME. 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. I think Wonka could be a great seed in that respect. +1 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: Wonka, Mika, and Apache
Chris Gray wrote: On Thursday 05 October 2006 18:00, Geir Magnusson Jr. wrote: Don't forget that you can have an embeddable SE - it doesn't have to be ME. Yes, but a full SE nowadays is pretty big. JavaME CDC is basically a defined subset of SE at the package level, and this is what Wonka aims to support. There is nothing missing in terms of VM functionality (contrast with CLDC). 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. Once you can overcome the no subsetting restriction, yes. I've written to Punch Telematix about the bulk contribution checklist, I await a reply. w00t :) Cheers, Chris - 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
Yes. It's a test. 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 PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Spark Shen China Software Development Lab, IBM - 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!
Congratulations! Excellent! geir Alex Blewitt wrote: 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] - 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][logging] Best practices for logging within the Class Library?
Nathan Beyer wrote: -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Tim Ellison wrote: We did this topic already g it's even referenced from the website [1]. So at the risk of repeating my super-super-duper high level view... Why are we considering putting logging into the class library implementation? Darn it! I was hoping that I could beat you to this, by playing the straight man and setting you up so you could say this line, because I *knew* you would say this :) [and I agree] So does this mean that I delete all of the TODOs with comments like log warning and not get flamed again? That wasn't a flame :) Seriously, if this was already agreed upon, then why are they tons of comments about logging to be reinserted? These comments are either in the form of TODOs, FIXMEs and in many cases just logging code that commented out. To be honest, there never was a real consensus reached on it. I had proposed thinking about it from other angles, such as aspects. I was also thinking that some kind of pre-processing might help here - developers want it, but we clearly don't want it in a shipped version... As for not remembering the previous agreement, sorry about that. I looked and the original conversation was in May, I can barely remember last week. Last week? I have trouble with yesterday. geir Is it for our end-users? Do we expect them to turn on logging and look at the contents to discover problems in our code? or perhaps discover problems in their usage of the API? Both of these seem like flawed concepts. Is it for us as developers? Putting printf's in the code doesn't seem like a very efficient way of figuring out how the code works, and just clutters up the codebase. I'd also object to having loads of modules depend on logging. Oh, for that #define I was talking about in the sync object thread. Actually, I'll start a new thread on this... [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/agreements. html Regards, Tim Nathan Beyer wrote: There seem to be a number of places where logging would be useful within the class library (and Java parts of the VM), but the rules of engagement seems to be undefined, so it's not being used. Here's my super-duper high-level swipe at it. 1. Use java.util.logging for normal logging (somewhat obvious). 2. Do not use java.util.logging within luni, security and kernel modules; this is to prevent cyclical executions. 3. Use the class name for the name of the Logger; this is based on the assumption that classes will be packaged appropriately such that logging can be enabled by packages to get sub-system information. 4. Use the java.util.logging.Level javadoc [1] as a guide for the appropriate logging level for a particular message. When in doubt, be conservative and use lower levels (less than INFO). Thoughts, comments? The big question in my mind is what modules must be isolated from consuming java.util.logging (regarding 2 above). The other modules that might need isolation are archive and text, but I'm not sure about that. Any others? -Nathan [1] http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/Level.html - 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 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]
Re: [r451637] - Code cleanup - ... - Remove unnecessary comments
Stepan Mishura wrote:
On 10/4/06, Nathan Beyer wrote:
If this is an event that should be logged, as the TODO indicated, then
why not just print out the stack trace and be done with it? If this
exception happens so often that you'd like it removed, then why would
we want to log a warning message, which I would presume would print to
the console just as frequently.
As for TODOs, in general I find TODOs never get done, especially
trivial ones like this particular case.
I don't agree. TODOs are good hint for making improvements and I'd keep
them
in source files.
Me too. I don't like cruft, but I'm not sure I see the harm in general.
geir
Thanks,
Stepan.
-Nathan
On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Nathan,
I've seen you dropped many TODOs in - Code cleanup - series of
commits;
I'd like to know what reasoning was behind this? I think it's a bit
early to erase TODOs without appropriate consideration...
In particular, could you please undo the following change, it produces
garbage messages during AUTH testing:
modules/auth/src/main/java/common/org/apache/harmony/auth/login/DefaultConfigurationParser.java
===
@@ -216,12 +206,12 @@ public class DefaultConfigurationParser
try {
val = PolicyUtils.expand(st.sval, system);
} catch (Exception e) {
- //TODO: warning log
- }
+ e.printStackTrace();
+ }
}
--
WBR,
Alexey
--
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] DRLVM, jre/bin/default and launcher
Vladimir Ivanov wrote: As we know the current IBM VM does not support all 'standard' java options. IBM VM peoples, could you give some expectation when this support will be available (1 month, 3 or 6 ...)? Why do we as the Harmony project care? geir thanks, Vladimir The standard options from my point of view are (without deprecated): tmpjava Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file) where options include: -client to select the client VM -server to select the server VM -hotspot is a synonym for the client VM [deprecated] The default VM is client. -cp class search path of directories and zip/jar files -classpath class search path of directories and zip/jar files A ; separated list of directories, JAR archives, and ZIP archives to search for class files. -Dname=value set a system property -verbose[:class|gc|jni] enable verbose output -version print product version and exit -version:value require the specified version to run -showversion print product version and continue -jre-restrict-search | -jre-no-restrict-search include/exclude user private JREs in the version search -? -help print this help message -Xprint help on non-standard options -ea[:packagename...|:classname] -enableassertions[:packagename...|:classname] enable assertions -da[:packagename...|:classname] -disableassertions[:packagename...|:classname] disable assertions -esa | -enablesystemassertions enable system assertions -dsa | -disablesystemassertions disable system assertions On 9/4/06, Oliver Deakin [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: Andrey Chernyshev wrote: 1. Fix the DRLVM layout - rename vmcore to harmonyvm and move ..dll/.so into the default subdirectory such that one doesn't have to type -vm and -vmdir options; While would you want to rename DRLVM to Harmony VM? It feels to me like claiming DRLVM to be the only Harmony VM. On the contrary, I thought Harmony project is about *encouraging* diversity. I think having library named libdrlvm.so would be much better. The Harmony launcher looks for harmonyvm.dll as its default vm library. It's just a generic name so that the launcher can find the correct library without -vm. The IBM VME also contains a harmonyvm.dll, which is why it works without specifying command line options Regards, Oliver 2. Exclude building of the original launcher from the DRLVM build - it currently conflicts with the classlib launcher (both are called java). 3. Aside from the hythread, it may also have a sense to make the classlib and DRLVM using the same zlib dll/so (preferably the system one). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - 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] deploy.canonical ant task
I'll look at the patch, and either do that, or something where it's on demand. geir Salikh Zakirov wrote: Pavel Pervov wrote: Dear all, Can we exclude this task from DRLVM's build.xml default task? It takes most of build time when rebuilding only several files while working with drlvm code. AFAIU, exect content of this directory exists at platform_arch_compiler_config/deploy directory. The HARMONY-1085 has been filed some two months ago to do just that: stop copying jre from platform-specific directory to just deploy/ directory. I have just updated patches in HARMONY-1085 to match current SVN trunk. - 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] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
of multi VM. So lets forget about it for a while... I think that the data duplication would always serve as a potential source of errors - while updating one copy of object, you may forget to update the other, often resulting into a strange behavior of the whole application. Let's see what are the specific performance concerns that have to be addressed. To get VM_thread structure, you would eventually go to the TLS, just like jthread_get_JNI_env(jthread_self() would do. If there is already VM_thread structure for some reasons then there will be no extra access to TLS. It is definitely much more in jthread_get_JNI_env(jthread_self() than just one TLS access and one dereferncing. I don't think it is a really big problem now. Do you agree to look at this later. I guess multi VM implementation will alter it in any case. Thanks Evgueni Thanks, Andrey. Evgueni Thanks Artem On 9/28/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: I suppose two days silence means that there is no objects (maybe interest) against proposed patch. I would suggest to commit it ASAP. It really works! There are some cases when current VM crashes but the patch fixes it. I can work on bringing cunit tests to live as soon as the patch is committed This is just my understanding. Thanks Evgueni On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: So where are we here? On Sep 28, 2006, at 12:41 AM, Evgueni Brevnov wrote: On 9/28/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 9/26/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/27/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: (3) One more lock is added - hythread_lib_lock. How is that differ from the hythread_global_lock that we already have? Each extra lock to the system may add more possibilities for deadlocks, as well as can negatively impact the scalability (unless some of the existing locks are split). hythread_lib_lock acquires exactly the same lock as hythread_global_lock. Probably I miss something but we need to be compatible with IBM threading library now. This library has such function. That's why I added it. Sounds right? Well, this sort of, kind of sounds right but not quite. Its a little more subtle than being compatible with IBM threading library. The first goal is to identify the parts of IBM threading library that are JVM independent. It makes sense for DRLVM to be compatible with the independent parts. This should be a nobrainer. The parts of IBM threading library that assume a specific JVM implementation will be a problem. We will need to find a solution that is endorsed by all the stakeholders (including J9 folks). The hythread_global_lock falls into this category. For starts, I would like to see a concise description from the portlib owners on what hythread_global_lock protects, which locks have to be held before grabbing this lock, are there any restrictions on what system calls can be made while holding this lock (like sleep or wait), etc. Weldon, I completely agree with what your are saying. It's common problem of current hythread that should be resolved some how. I just go inline with current implementation and added two missing functions. Missing these can lead to the same problems as with hythread_exit discussed in another thread [drlvm] [launcher] Executable hangs. To get a better idea what's in the patch.diff, I printed it out. Its 120+ pages. Quite a big patch! Most of it looks like straight forward JNI interface glue. There are some tricky parts. I would like to know the design review process for these parts. Using grep, I found 20 locations where ...suspend_enable... and ...suspend_disable... have been added. And 25 locations where enable/disable have been removed. Failure in this logic can lead to incorrect reference pointer enumeration. These are probably the hardest bugs to find. Please tell us who has looked at this code
Re: [classlib] [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test
Mark Hindess wrote: FYI: I've changed the way our builds are reported to the -commits list. Now, the reports go to my apache.org email address where they are compressed and stored. The url in the message is then modified to point to the compressed version in my people.apache.org web space and the first 10k of the message is sent on to the -commits list. This should mean: a) all messages reach the list (no more size limit issues) b) the full logs are available via the web - at least for a week or two Nice! Currently the trimming of the logs to send to the list is very crude and usually the first 10k isn't very useful. Hopefully I'll get some time to improve the trimming shortly to, for instance, include lines which match /(error/fail/warn)/i plus a few lines of context above/below. I'm hoping we can transition soon to the common CI system in build-test, so maybe the system you concocted could be adapted to that. geir Regards, Mark. On 4 October 2006 at 9:36, [EMAIL PROTECTED] wrote: Online report : http://people.apache.org/~hindessm/continuum/classlib/linux.i a32/2006/10/04/20061004-083606.successful.log.gz Build statistics: State: Ok Previous State: Failed Started at: Wed, 4 Oct 2006 09:03:31 +0100 Finished at: Wed, 4 Oct 2006 09:36:04 +0100 Total time: 32m 33s Build Trigger: Schedule Exit code: 0 Building machine hostname: hy2 Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes classlib/modules/auth/src/test/java/common/org/ap ache/harmony/auth/login/DefaultConfigParserTest.java classlib/modules/auth/src/test/java/common/org/apache/harmony/aut h/login/DefaultConfigurationTest.java classlib/modules/auth/src/test/resources/auth.conf classlib/make/properties.xml Output: Buildfile: build.xml build: [delete] Deleting directory /home/hybld/continuum-working-directory/6/clas slib/deploy [echo] Classlib revision is 452787 [echo] Post process: true [echo] JAPI: true [echo] Building with reference jdk/javac [exec] Buildfile: build.xml [exec] clean-java: [exec] -copy-kernel-patternsets: [exec] [mkdir] Created dir: /home/hybld/continuum-working-directory/ 6/classlib/deploy/build/patternsets [exec] [copy] Copying 1 file to /home/hybld/continuum-working-direc tory/6/classlib/deploy/build/patternsets [exec] [copy] Copying 1 file to /home/hybld/continuum-working-direc tory/6/classlib/deploy/build/patternsets [exec] -modules-clean-bin: [exec] call-modules-all: [exec] clean: [exec][delete] Deleting 30 files from /home/hybld/continuum-working- directory/6/classlib/build/classes [exec][delete] Deleting 15 files from /home/hybld/continuum-working- directory/6/classlib/modules/accessibility/bin/test [exec] clean: [exec][delete] Deleting 13 files from /home/hybld/continuum-working- directory/6/classlib/build/classes [exec] clean: [exec][delete] Deleting 4 files from /home/hybld/continuum-working-d irectory/6/classlib/build/classes [exec][delete] Deleting 1 files from /home/hybld/continuum-working-d irectory/6/classlib/modules/applet/bin/test [exec] clean: [exec][delete] Deleting 51 files from /home/hybld/continuum-working- directory/6/classlib/build/classes [exec][delete] Deleting 41 files from /home/hybld/continuum-working- directory/6/classlib/modules/archive/bin/test [exec] clean-native-includes: [exec][delete] /home/hybld/continuum-working-directory/6/classlib/de ploy/include not found. [exec] clean: [exec][delete] Deleting 106 files from /home/hybld/continuum-working -directory/6/classlib/build/classes [exec][delete] Deleting 218 files from /home/hybld/continuum-working -directory/6/classlib/modules/auth/bin/test [exec] clean: [exec][delete] Deleting 901 files from /home/hybld/continuum-working -directory/6/classlib/build/classes [exec][delete] Deleting 570 files from /home/hybld/continuum-working -directory/6/classlib/modules/awt/bin/test [exec] clean: [exec][delete] Deleting 107 files from /home/hybld/continuum-working -directory/6/classlib/build/classes [exec][delete] Deleting 233 files from /home/hybld/continuum-working -directory/6/classlib/modules/beans/bin/test [exec] clean: [exec][delete] Deleting 122 files from /home/hybld/continuum-working -directory/6/classlib/build/classes [exec][delete] /home/hybld/continuum-working-directory/6/classlib/mo dules/concurrent/bin/test not found. [exec] clean: [exec][delete] Deleting 49 files from /home/hybld/continuum-working- directory/6/classlib/build/classes [exec]
Re: [drlvm][build] deploy.canonical ant task
Salikh Zakirov wrote: Geir Magnusson Jr. wrote: Ok - I'm going to suggest something different that gets you what you want, namely pass a flag to do the fill up canonical rather than pass the deploy directory. That way, the build process is always the same, with an extra step if you ask for it, rather than have it slightly variable as you suggest in the patch. Make sense? Sounds acceptable to me. (Though I still believe that copying is unnecessary). Why? Having a well known target to find stuff is good. Having the standard build (from DRLVM POV) be standard is also good. I guess that the best way would be simply to create a link so that the caller outside DRLVM could just pick up the material that way. Anyway, since now the copying doesn't happen, why is it bad for the federated build? It's slow on windows compared to linux, but that's not surprising... 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: [patch][drlvm] Fix compilation on Linux/x86_64
Can you open a JIRA with this, explaining what needs to be done, and
linking the other JIRAs as needed?
Thx
geir
Salikh Zakirov wrote:
The patch turned out to be exact duplicate of HARMONY-1571.
Besides, there exist a patch with fixes for unit tests: HARMONY-1574.
The following change is needed on top of already committed HARMONY-1551
to make DRLVM start on Linux/x86_64.
However, it still doesn't work properly, failing with
java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167:
Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion `!(vt() 1)'
failed.
--- a/vm/vmcore/src/jvmti/jvmti_dasm.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_dasm.cpp
@@ -68,9 +68,9 @@ static void convertOperand2Opnd(
}
#ifdef _IPF_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
@@ -78,9 +78,9 @@ static const char* get_reg_value(
#elif defined _EM64T_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
Salikh Zakirov wrote:
Hi gang,
the below patch fixes the problem that prevents DRLVM from being compilable
on Linux/x86_64.
The TI itself does not work on x86_64, and the modification only fixes
compiler error.
diff --git a/vm/vmcore/src/jvmti/jvmti_step.cpp
b/vm/vmcore/src/jvmti/jvmti_step.cpp
index d29ef32..b4180f6 100644
--- a/vm/vmcore/src/jvmti/jvmti_step.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_step.cpp
@@ -502,7 +502,7 @@ #endif
const InstructionDisassembler::Opnd stub_op = stub_disasm.get_opnd(0);
assert(stub_op.kind == InstructionDisassembler::Kind_Imm);
-method = (Method *)stub_op.imm;
+method = (Method *)(POINTER_SIZE_INT)stub_op.imm;
}
}
-
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] Recognizing lock objects
+1
BTW, why call it RepositionLock?
Tim Ellison wrote:
BTW, as I go through the code looking at the occurrences of 'new
Object()' and determining if they are used simply for their locks, I
figured we also need a way to record the check has been done.
So, if there is a 'new Object()' that is not simply a lock object (and
therefore named as we agreed) I'll mark it on the same line as
// $NON-LOCK-1$ so we can easily grep for divergences from the pattern.
Regards,
Tim
Mikhail Fursov wrote:
Another variant is to use anonymous class without the name:
Object lock = new Object(){};
But the name by itself (RepositionLock) serves like a comment.
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
-
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] HARMONY-1607 : where is the right place to put it?
Mikhail Fursov wrote: Geir, I created this package to have a common place with other MSVC users in JIRA and I did not expect you want to put it into the trunk :) Well, I think that we should put these things in SVN if we can, rather than use JIRA as some kind of storage. I think that some docs on this for the website would be nice, as well as for Eclipse and any other environments that people use. But if you decided to add it I suggest adding it to the drlvm/trunk/build folder. So the resulting folder for MSVC2003 solution will be drlvm/trunk/build/custom/msvc_2003. Ok. You're the expert. Note:This package does not complete today and contains only jitrino/encoder/em projects. If anyone has other MSVC project files for drlvm subprojects, please speak up. Offtopic: Geir, you said before you use IDEA for Java, so I think you like to use keyboard shortcuts instead of mouse. The Visual Assist plugin for MSVC allows me to work without mouse in Visual Studio too. I used to do a lot of win32 system programming, and really did like working in MSVC - but that was years ago. I just prefer to work under Linux. I hate to admit it, I've been using Eclipse a lot lately because of the C/C++ support :) geir On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I haven't used MSVC in about 6 years, so where is the right place to put the files from 1607 so that they are easily used by an MSVC user? 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: [patch][drlvm] Fix compilation on Linux/x86_64
Salikh Zakirov wrote:
Okay, I will file a JIRA as soon as I have a complete solution.
A side question: do we have a philosophical justification
why we as a project prefer to work through JIRA instead of e-mail?
I personally believe that the instruction will not get any clearer
if it is written in JIRA rather than in e-mail, and also tend to think
that noone will ever want to know why build on a particular platform
was failing at some particular point of time in the past.
Accordingly, I think that transient issues like build failures
are better served with e-mailed patches.
A few reasons... first, it's much easier to track where things came
from, the svn revision, etc. Second, it's a single record of all
contributions to the project from non-committers, which is important
from the perspective of our IP tracking and provenance process.
Also, counting patches makes it easy to evaluate people for
committership - it's only one element, but an easy one
geir
Geir Magnusson Jr. wrote:
Can you open a JIRA with this, explaining what needs to be done, and
linking the other JIRAs as needed?
Thx
geir
Salikh Zakirov wrote:
The patch turned out to be exact duplicate of HARMONY-1571.
Besides, there exist a patch with fixes for unit tests: HARMONY-1574.
The following change is needed on top of already committed HARMONY-1551
to make DRLVM start on Linux/x86_64.
However, it still doesn't work properly, failing with
java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167:
Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion
`!(vt() 1)' failed.
--- a/vm/vmcore/src/jvmti/jvmti_dasm.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_dasm.cpp
@@ -68,9 +68,9 @@ static void convertOperand2Opnd(
}
#ifdef _IPF_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
@@ -78,9 +78,9 @@ static const char* get_reg_value(
#elif defined _EM64T_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
Salikh Zakirov wrote:
Hi gang,
the below patch fixes the problem that prevents DRLVM from being
compilable
on Linux/x86_64.
The TI itself does not work on x86_64, and the modification only fixes
compiler error.
diff --git a/vm/vmcore/src/jvmti/jvmti_step.cpp
b/vm/vmcore/src/jvmti/jvmti_step.cpp
index d29ef32..b4180f6 100644
--- a/vm/vmcore/src/jvmti/jvmti_step.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_step.cpp
@@ -502,7 +502,7 @@ #endif
const InstructionDisassembler::Opnd stub_op =
stub_disasm.get_opnd(0);
assert(stub_op.kind == InstructionDisassembler::Kind_Imm);
-method = (Method *)stub_op.imm;
+method = (Method *)(POINTER_SIZE_INT)stub_op.imm;
}
}
-
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] Recognizing lock objects
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...
geir
Tim
Tim Ellison wrote:
BTW, as I go through the code looking at the occurrences of 'new
Object()' and determining if they are used simply for their locks, I
figured we also need a way to record the check has been done.
So, if there is a 'new Object()' that is not simply a lock object (and
therefore named as we agreed) I'll mark it on the same line as
// $NON-LOCK-1$ so we can easily grep for divergences from the pattern.
Regards,
Tim
Mikhail Fursov wrote:
Another variant is to use anonymous class without the name:
Object lock = new Object(){};
But the name by itself (RepositionLock) serves like a comment.
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
-
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: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/depends.xml
Any reason why we couldn't do the same thing for linux that we're doing
for windows in terms of having these libraries pre-compiled and easy to
drop in?
geir
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Regards,
Mark.
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/ (pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
-
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x8
6/
-
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.properties
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/depends.properties?view=diffrev=452826r1=452825r2=452826
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.properties (origin
al)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed Oct
4 03:24:29 2006
@@ -98,3 +98,11 @@
servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servlet-a
pi-2.5-6.0.0.jar
+
+people.apache.base=http://people.apache.org/~geirm/harmony/
+awtdeps.dir=${depends.dir}/libs/windows.x86
+awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
+awtdeps.extract.dir=${depends.dir}/libs/build
+awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/depends.xml?view=diffrev=452826r1=452825r2=452826
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml Wed Oct 4 03:
24:29 2006
@@ -72,17 +72,22 @@
/target
-target name=-check-win if=is.windows
+target name=-check-win if=is.windows
+depends=-really-check-win,-awt-tar-extract /
+
+target name=-really-check-win if=is.windows
check-one-file src=${msvcr71.url} dest=${msvcr71.dll} /
-/target
+check-one-file src=${awtdeps.url} dest=${awtdeps.tar} /
+
+ uptodate property=awtdeps.uptodate
+ srcfile=${awtdeps.tar}
+ targetfile=${awtdeps.testfile} /
-target name=-check-unix if=with.awt.swing
-antcall target=--check-unix /
/target
-target name=--check-unix if=is.unix
+target name=-check-unix if=is.unix
property name=lcms.msg
value=liblcms development package not installed
@@ -214,6 +219,10 @@
download-one-file src=${msvcr71.url} dest=${msvcr71.dll}
md5=${msvcr71.md5} /
+ mkdir dir=${awtdeps.dir} /
+ download-one-file src=${awtdeps.url} dest=${awtdeps.tar}
+ md5=${awtdeps.md5} /
+
/target
macrodef name=download-one-file
@@ -298,6 +307,14 @@
jar destfile=${bcprov.jar} basedir=${bcprov.dir}/temp
manifest=${bcprov.dir}/temp/META-INF/MANIFEST.MF /
delete dir=${bcprov.dir}/temp /
+/target
+
+target name=-awt-tar-extract unless=awtdeps.uptodate
+echoExtracting awt dependencies/echo
+ untar src=${awtdeps.tar} dest=${awtdeps.extract.dir}
+ compression=gzip /
+echo file=${awtdeps.testfile}
+ message=${awtdeps.tar} extracted${line.separator} /
/target
macrodef name=check-one-link
Re: [classlib] enabling AWT/Swing by default
Tim Ellison wrote:
Excuse the change in subject line...
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
To the contrary, ditch it.
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Problem 1: My machine is too slow running all these tests.
That means you probably want to have a flag to not run those tests...
geir
Regards,
Tim
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/ (pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
-
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x8
6/
-
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.properties
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/depends.properties?view=diffrev=452826r1=452825r2=452826
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.properties (origin
al)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed Oct
4 03:24:29 2006
@@ -98,3 +98,11 @@
servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servlet-a
pi-2.5-6.0.0.jar
+
+people.apache.base=http://people.apache.org/~geirm/harmony/
+awtdeps.dir=${depends.dir}/libs/windows.x86
+awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
+awtdeps.extract.dir=${depends.dir}/libs/build
+awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/depends.xml?view=diffrev=452826r1=452825r2=452826
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml Wed Oct 4 03:
24:29 2006
@@ -72,17 +72,22 @@
/target
-target name=-check-win if=is.windows
+target name=-check-win if=is.windows
+depends=-really-check-win,-awt-tar-extract /
+
+target name=-really-check-win if=is.windows
check-one-file src=${msvcr71.url} dest=${msvcr71.dll} /
-/target
+check-one-file src=${awtdeps.url} dest=${awtdeps.tar} /
+
+ uptodate property=awtdeps.uptodate
+ srcfile=${awtdeps.tar}
+ targetfile=${awtdeps.testfile} /
-target name=-check-unix if=with.awt.swing
-antcall target=--check-unix /
/target
-target name=--check-unix if=is.unix
+target name=-check-unix if=is.unix
property name=lcms.msg
value=liblcms development package not installed
@@ -214,6 +219,10 @@
download-one-file src=${msvcr71.url} dest=${msvcr71.dll}
md5=${msvcr71.md5} /
+ mkdir dir=${awtdeps.dir} /
+ download-one-file src=${awtdeps.url} dest=${awtdeps.tar}
+ md5=${awtdeps.md5} /
+
/target
macrodef name=download-one-file
@@ -298,6 +307,14 @@
jar destfile=${bcprov.jar} basedir=${bcprov.dir}/temp
manifest=${bcprov.dir}/temp/META-INF/MANIFEST.MF /
delete dir=${bcprov.dir}/temp /
+/target
+
+target name=-awt-tar-extract unless=awtdeps.uptodate
+echoExtracting awt dependencies/echo
+ untar src=${awtdeps.tar} dest=${awtdeps.extract.dir}
+ compression=gzip /
+echo file=${awtdeps.testfile}
+ message=${awtdeps.tar}
Re: [classlib] enabling AWT/Swing by default
Mark Hindess wrote: On 4 October 2006 at 15:41, Tim Ellison [EMAIL PROTECTED] wrote: Excuse the change in subject line... No problem. I was just cursing myself for having forgotten to change it. Mark Hindess wrote: With this change, the awt dependencies should now be automated for windows and at least fairly trivial (installing a few packages on Linux[0]). I think it is time we removed the with.awt.swing flag. Anyone object? To the contrary, ditch it. Please test the current setup with -Dwith.awt.swing=true and report any problems. Problem 1: My machine is too slow running all these tests. Mine too. And I have wondered if the hourly builds will finish within the hour now. We really should see if we can avoid the need to fork for every test. LOL. If our tests take more than an hour, so be it... Or, do a fast test set on one machine to get the earliest warning for the most amount of code, and a slower do it all machine that acts as a safety net 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: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/depends.xml
Mark Hindess wrote:
Since most (all?) distributions provide versions of these libraries (and
maintain them - regular security fixes for example) why would we want
to maintain them ourselves? It's not a job I'd want.
I'm not advocating maintenance, but simply defining the set that we
build and test with.
I'm not a fan of having certified builds be dependent on whatever random
stuff the user downloads to /usr/lib
Really the same is true for zlib and to an extent icu. If someone
else is doing the work maintaining them, we should use what they are a
providing not make more work for ourselves. We should also try to use
the dynamic libraries if possible.
Yes, on the first sentence, not so sure on the last, simply because
there's value in testing a fixed set of versions of stuff.
With the exception of icu, most of these libraries change very little
over time so there should be few if any interoperability issues.
I can only really see a good argument for maintaining icu binaries since
it is changing more frequently and many distributions seem to have
rather old versions.
Regards,
Mark.
On 4 October 2006 at 10:40, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Any reason why we couldn't do the same thing for linux that we're doing
for windows in terms of having these libraries pre-compiled and easy to
drop in?
geir
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Regards,
Mark.
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props
ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/
(pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/windows
.x8
6/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.propertie
s
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
k/m
ake/depends.properties?view=diffrev=452826r1=452825r2=452826
==
===
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.properties (ori
gin
al)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed
Oct
4 03:24:29 2006
@@ -98,3 +98,11 @@
servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servle
t-a
pi-2.5-6.0.0.jar
+
+people.apache.base=http://people.apache.org/~geirm/harmony/
+awtdeps.dir=${depends.dir}/libs/windows.x86
+awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
+awtdeps.extract.dir=${depends.dir}/libs/build
+awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
k/m
ake/depends.xml?view=diffrev=452826r1=452825r2=452826
==
===
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml Wed Oct 4
03:
24:29 2006
@@ -72,17 +72,22 @@
/target
-target name=-check-win if=is.windows
+target name=-check-win if=is.windows
+depends=-really-check-win,-awt-tar-extract /
+
+target name=-really-check-win if=is.windows
check-one-file src=${msvcr71.url} dest=${msvcr71.dll} /
-/target
+check-one-file src=${awtdeps.url} dest=${awtdeps.tar} /
+
+ uptodate property=awtdeps.uptodate
+ srcfile=${awtdeps.tar
Re: [classlib][depends] missing liblcms +em64t
Mark Hindess wrote: On 4 October 2006 at 18:26, Ivan Volosyuk [EMAIL PROTECTED] wrote: Working on a patch, I've just wanted to check wether it works on em64t. It is not that easy as I expected. Yesterday, I have filed HARMONY-1676 to have classlib built. Today, I have: Missing dependency. The file from: /usr/lib/liblcms.a should be linked to: depends/libs/build/lcms/liblcms.ia32 But /usr/lib/liblcms.a doesn't exist. liblcms development package not installed For Debian/Ubuntu try: apt-get install liblcms1-dev First of all, why 'ia32' prefix for em64t build? One second look, this seems to be a different problem. It looks like I accidentally hardcode ia32 - but since that's all that we really support at the moment then I'm not that sorry. The wider issue is that for historical reasons the awt build still uses ia32 and ipf where as it should probably be fixed to use the hy.arch defines of x86 and x86_64 (and ia64 if necessary but we don't really cover that yet anyway). +1 Patches welcome or I'll try to take a look in the next day or so. Regards, Mark. - 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]
[classlib] manifest information
Can we consider making the final manifest that goes into our jars to be created/updated dynamically? I just went through all manifests and added Specification-Version, Implementation-Version, etc and they will change, at least the last one. I know the Eclipse people depend on them, so maybe can we used ant's filtering to set the Impl-Version dynamically? Or something like that? 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][JIRA] Can 1594 be committed?
Ok. I'll look. It must be the case that the whole thing can compile w/ GCC 4.*, not just Jitrino and jet, including classlib. This isssue, the version of GCC, is one of the things that snags people. Are there any backwards compat issues if we make it all 4.x compatible? geir Pavel Pervov wrote: Dear committers, please, commit HARMONY-1594 to fix gcc 4.* build for Jitrino and jet sources. Otherwise, it is a bit more complex to live on a linux with compiler version 4.0 and above. Regards, Pavel Pervov. 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][kernel exception handling] several issues
Serguei Zapreyev wrote: Dear committers, I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the suggested patches. I was looking at 1573 last night, but was too tired to follow the instructions :) (Take the third attachment, combine with the first, to produce the second test that can be used on any Thursday in an odd-numbered month. Carry the 7, cross out each second vowel, and ...) Yes, I'll look at all three today. the last three were hidden - you didn't assign to the DRLVM component, so I missed them yesterday. So, to avoid redoubling efforts or superposition of commits because of delay could somebody take them under a control to estimate and apply if it is necessary? All the more, the 1650 and 1573 issues seem to be able to upset somehow the execution stability of a big application. Does that mean the patches fix them, or make big apps less stable? geir Great thanks in advance, Serguei - 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][jit] Internal testing framework for Jitrino.OPT compiler
yes, I saw - thanks for that. I was trying to get 1531 to work yesterday, and I seemed to do something wrong. Can you look at 1531 and comment? geir Ivan Kollegov wrote: Hi, I opened new JIRA http://issues.apache.org/jira/browse/HARMONY-1586 and attach my contribution to keep things clearer, could you just open a fresh JIRA, attach your contribition, and then link back to 1531? It makes it much easier to track who has given what... 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: [classlib] AWT/Swing deps
Mikhail Loenko wrote: For the short term it sounds good. For the long term the deps would better be built on the fly IMHO Why? We don't build other deps on the fly. By using a binary distro, we all have the same, predictable thing. And seems like some of this code hasn't changed since last century :) geir Thanks, Mikhail 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: Ok, that was fun. Not. We need to finish making this easier for developers to build by having pre-built binaries somewhere. To start, I'm going to put a well-documented tree that contains the stuff needed for /png, /lcms and /jpg on my personal account and note it. If we can then make that part of fetch-depends, all will be well. Comments? Other ideas? - 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][JIRA] Can 1594 be committed?
Congratulations! You're the proud owner of 1594! Please make sure things still compile w/ 3.4 :) geir Mark Hindess wrote: After posting, I noticed that Geir has pick up this JIRA so, while I'll still take a look, I wont steal the JIRA or commit any changes. Geir feel free to re-assign it if you decide you don't want it. ;-) -Mark. On 3 October 2006 at 12:02, Mark Hindess [EMAIL PROTECTED] wrote: I'll take a look. -Mark. On 3 October 2006 at 14:42, Pavel Pervov [EMAIL PROTECTED] wrote: Dear committers, please, commit HARMONY-1594 to fix gcc 4.* build for Jitrino and jet sources. Otherwise, it is a bit more complex to live on a linux with compiler version 4.0 and above. Regards, Pavel Pervov. 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]
[drlvm] HARMONY-1607 : where is the right place to put it?
I haven't used MSVC in about 6 years, so where is the right place to put the files from 1607 so that they are easily used by an MSVC user? 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: [classlib] AWT/Swing deps
Alexey Petrenko wrote: 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Petrenko wrote: I agree that downloading of prebuilt libraries is better choice. So we got only two options: 1. Find prebuilt libraries somewhere. 2. Build them ourselves and store them somewhere. I've tried to find prebuilt libraries but I was not successful. So it seems that the only option is to build them ourselves. And the only question is: Where to store them? Any ideas? As I threatened in my original post, I put them in http://people.apache.org/~geirm/harmony/ I could move them to the snapshot directory too, but I figure no one is going to assume that we are formally distributing them if they are in a personal directory. Your personal directory looks ok for me. You can get prebuilt libraries from the HARMONY-1297 or build them yourself... They are already there. I built them myself. That gives me an idea. Can I stuff them in JIRA and and just have the build fetch from there? The URL should be stable. geir SY, Alexey http://issues.apache.org/jira/browse/HARMONY-1297 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Mikhail Loenko wrote: For the short term it sounds good. For the long term the deps would better be built on the fly IMHO Why? We don't build other deps on the fly. By using a binary distro, we all have the same, predictable thing. And seems like some of this code hasn't changed since last century :) geir Thanks, Mikhail 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: Ok, that was fun. Not. We need to finish making this easier for developers to build by having pre-built binaries somewhere. To start, I'm going to put a well-documented tree that contains the stuff needed for /png, /lcms and /jpg on my personal account and note it. If we can then make that part of fetch-depends, all will be well. Comments? Other ideas? - 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][kernel exception handling] several issues
I tend to agree. I think that it's a good idea to consider for the future, but right now, if the fixes help stabilize, great. I think that stabilization is key right now. geir Serguei Zapreyev wrote: On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/10/3, Serguei Zapreyev [EMAIL PROTECTED]: Dear committers, I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the suggested patches. So, to avoid redoubling efforts or superposition of commits because of delay could somebody take them under a control to estimate and apply if it is necessary? All the more, the 1650 and 1573 issues seem to be able to upset somehow the execution stability of a big application. Serguei, the HARMONY-1573 is mostly about j.l.Process impl. I believe we shoud consider reusing org\apache\harmony\luni\internal\process\SystemProcess.java available in luni rather than fixing alternative impl in DRLVM. What do you think? Alexey, I guess few items should be took into consideration before doing some conclusions here. First, DRLVM's implementation of Runtime has been checked during a lot of testing milestones. Second, its code is well known for DRLVM developers, so it's easy to maintain it in this hot time. Third, we have no good test set (like TCK) to compare the discussed impls. Forth, we have no methods to estimate performance of impls. ... So, I think your suggestion isn't too actual just now and may be considered some later. There is no need to upset the current stability just now. I think the attached patches should be applayed in the nearest time to improve the used code. All the more, this patch combines some issues apart from the Process. Thanks, Serguei -- Regards, Alexey Great thanks in advance, Serguei - 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] AWT/Swing deps
Mikhail Loenko wrote: 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Petrenko wrote: I agree that downloading of prebuilt libraries is better choice. So we got only two options: 1. Find prebuilt libraries somewhere. 2. Build them ourselves and store them somewhere. I've tried to find prebuilt libraries but I was not successful. So it seems that the only option is to build them ourselves. And the only question is: Where to store them? Any ideas? As I threatened in my original post, I put them in http://people.apache.org/~geirm/harmony/ I could move them to the snapshot directory too, but I figure no one is going to assume that we are formally distributing them if they are in a personal directory. Interesting statement. IANAL, but I'd assume we are The key is the definition of distribute. The project (and therefore the ASF) has not decided to distribute the software. It's being made available for use by our developers in our project tree. (It's structured as a drop-in for the right place in classlib/depends) This is very different from us creating a release and voting on it. 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] invoking non-trivial jars results in IllegalAccessError
nice work Anton Luht wrote: Alexey, Thanks for pointing to that test - I created my tests using this approach. Please see HARMONY-1671 for tests. If you think that some more options should be covered - please let me know - I'll try to make tests for them. On 9/29/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Anton, Many thanks for volunteering. You might be interested to look at org.apache.harmony.archive.tests.java.util.jar.JarOutputStreamTest in archive module - it gives some basic coverage in this area. I know about it because just recently fixed it, see HARMONY-1622. -- Alexey 2006/9/29, Anton Luht [EMAIL PROTECTED]: Hello, I'd like to volunteer. Just an idea: I'm going to create a number of .class and .jar files and test various combinations of launching using SupportExec On 9/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: We desperately need tests for this. Anyone want to volunteer, to even make simple ones? We can stuff into the smoke or other frameworks... geir Pavel Pervov wrote: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- 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] - 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: [classlib] AWT/Swing deps
Mark Hindess wrote: On 3 October 2006 at 19:16, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Petrenko wrote: I agree that downloading of prebuilt libraries is better choice. So we got only two options: 1. Find prebuilt libraries somewhere. 2. Build them ourselves and store them somewhere. I've tried to find prebuilt libraries but I was not successful. So it seems that the only option is to build them ourselves. And the only question is: Where to store them? Any ideas? As I threatened in my original post, I put them in http://people.apache.org/~geirm/harmony/ I could move them to the snapshot directory too, but I figure no one is going to assume that we are formally distributing them if they are in a personal directory. Interesting statement. IANAL, but I'd assume we are Certainly we are in that sense but I don't think that is the issue Geir was trying to address. (This certainly means we needed to meet the license requirements for distribution - though IIRC they are fairly minimal for these particular packages.) The issue is whether the Apache Software Foundation is considered to be formally responsible or if it is just something Geir is doing personally. Well, if the project build is tied to it, it should be considered something we are doing as a project *for ourselves*. In the same way that we stuff things into SVN for our use, we aren't claiming to be a distributor of those things. Sure, it's available to evereyone, but that's because of the open way we work. 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: [patch][drlvm] fix junit.jar download
1) Salikh - thanks for catching this
2) Alexey - yes, I think that would be better. Can someone offer a patch?
geir
Alexey Varlamov wrote:
Can't we just take junit.jar from classlib's depends (as we do with XALAN)?
2006/10/3, Salikh Zakirov [EMAIL PROTECTED]:
Geir,
it looks like the commit
[r452245] HARMONY-698 This should be equivalent to what HARMONY-698
broken the downloading of junit.jar (which we used to take from
Eclipse distribution).
The below patch adds junit.jar as a separate download from ibiblio jar
repository.
--- 8 ---
added downloading of junit.jar
diff --git build/make/lnx.properties build/make/lnx.properties
index c4f6c56..1404b5b 100644
--- build/make/lnx.properties
+++ build/make/lnx.properties
@@ -57,6 +57,10 @@ # APR-iconv, version 1.1.1 or above
# http://apr.apache.org/download.cgi
remote.APRICONV.archive=http://apache.reverse.net/pub/apache/apr/apr-iconv-1.1.1.tar.gz
+# JUnit, version 3.8.1 or above
+remote.JUNIT.archive=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
+remote.JUNIT.archive.type=asis
+
# LOG4CXX, svn revision 416779
# http://logging.apache.org/site/cvs-repositories.html
remote.LOG4CXX.archive=-r 416779
http://svn.apache.org/repos/asf/logging/log4cxx/trunk
diff --git build/make/setup.xml build/make/setup.xml
index e570ae0..be28782 100644
--- build/make/setup.xml
+++ build/make/setup.xml
@@ -105,6 +105,7 @@ Version: $Revision: 1.5.2.33 $
property name=CLASSLIB.check.file
value=native-src/README.txt /
property name=XALAN.check.file value=xalan.jar /
property name=VM.check.file
value=vmcore/src/init/vm_main.cpp /
+ property name=JUNIT.check.file value=junit-3.8.1.jar /
property name=ANTLR.check.file
value=antlr-2.7.5.jar /
property name=PATCHES.check.file value=README.txt /
/target
@@ -148,6 +149,12 @@ Version: $Revision: 1.5.2.33 $
target name=copy.nessessary.jars
+copy tofile=tmp/junit.jar
+fileset dir=${build.precopied.dir}/common/JUNIT
+include name=junit*.jar /
+/fileset
+/copy
+
propertyregex property=build.XALAN.path
input=${if.XALAN.exist} regexp=(.*)/${XALAN.check.f
ile} select=\1 /
copy file=${build.XALAN.path}/xalan.jar todir=tmp /
@@ -176,7 +183,7 @@ Version: $Revision: 1.5.2.33 $
target name=setup.resources depends=plugin.antcontrib
-property name=common.resources
value=LOG4CXX,CPPTASKS,XALAN,VM,ANTLR,PATCHES /
+property name=common.resources
value=LOG4CXX,CPPTASKS,XALAN,VM,ANTLR,PATCHES,JUNIT /
property name=build.resources value=CPPTASKS /
if
isset property=if.lnx /
diff --git build/make/win.properties build/make/win.properties
index 51274f1..6753d2b 100644
--- build/make/win.properties
+++ build/make/win.properties
@@ -60,6 +60,10 @@ # APR-iconv, version 1.1.1 or above
# http://apr.apache.org/download.cgi
remote.APRICONV.archive=http://apache.reverse.net/pub/apache/apr/apr-iconv-1.1.1-win32-src.zip
+# JUnit, version 3.8.1 or above
+remote.JUNIT.archive=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
+remote.JUNIT.archive.type=asis
+
# LOG4CXX, svn revision 416779
remote.LOG4CXX.archive=-r 416779
http://svn.apache.org/repos/asf/logging/log4cxx/trunk
remote.LOG4CXX.archive.type=svn
-
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][jit] Internal testing framework for Jitrino.OPT compiler
so is my response :) Mikhail Fursov wrote: Geir, my comment is in JIRA. On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: yes, I saw - thanks for that. I was trying to get 1531 to work yesterday, and I seemed to do something wrong. Can you look at 1531 and comment? geir Ivan Kollegov wrote: Hi, I opened new JIRA http://issues.apache.org/jira/browse/HARMONY-1586 and attach my contribution to keep things clearer, could you just open a fresh JIRA, attach your contribition, and then link back to 1531? It makes it much easier to track who has given what... 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][jit] Internal testing framework for Jitrino.OPT compiler
done Mikhail Fursov wrote: Ivan, Thank you for the fix. I checked the diff and it looks OK. Actually, with this patch you remove the extra state from CFG - the special behaviour of CFG without exit/entry nodes. And I think that this is right. Now it's time to ask commiters to apply the patch. On 10/3/06, Ivan Kollegov [EMAIL PROTECTED] wrote: Hi Mikhail, I created fix for this bag and posted my diff to https://issues.apache.org/jira/browse/HARMONY-1665 I added 2 ifs for entry and exit nodes, to verify if the node is not null. If the node is null, then return. Can you check my fix? On 9/27/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Ivan, I've checked all of the tests - this is very good beginning! I see 2 directions to advance: 1) Integrate Jitrino tests into common harmony test system. So we can ask people to use our test suite. 2) Start to test not only CFG but more complex IR examples. I mean to test IR with instructions using optimizations. I want to get item 1 as TODO for myself. Could you take item 2 and write several IR templates with instructions and use these templates in tests? getNodeCountTest2 - this is a real bug. This bug does not affect any of JIT algorithms today, but anyway it must be fixed. Could you create and post the fix into JIRA? If you have questions I can help you with the fix. - 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: [patch][drlvm] fix junit.jar download
fixed - thanks
Salikh Zakirov wrote:
Alexey Varlamov wrote:
Can't we just take junit.jar from classlib's depends (as we do with XALAN)?
I agree, that would be a better solution.
It just didn't occur to me that we already have it in classlib's depends.
So, the below change seems to be sufficient.
--- build/make/setup.xml
+++ build/make/setup.xml
@@ -148,6 +148,8 @@ Version: $Revision: 1.5.2.33 $
target name=copy.nessessary.jars
+copy file=${external.dep.CLASSLIB}/depends/jars/junit_3.8.2/junit.jar todir=tmp /
+
propertyregex property=build.XALAN.path input=${if.XALAN.exist}
regexp=(.*)/${XALAN.check.file} select=\1 /
copy file=${build.XALAN.path}/xalan.jar todir=tmp /
-
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]
[vote] HARMONY-1609 - bulk contribution of Applet, ImageIO and Print modules
BCC and ACQs in place. [ ] +1 Yes, accept the contribution [ ] -1 No, don't. reason : As usual, 3 days or until all committers vote, or there is an objection/request for continuance - 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] Recognizing lock objects
Tim Ellison wrote:
There are a number of places in the class library code where we create
an object solely to use as a synchronized block 'lock'.
For example, in RandomAccessFile we define a
private Object repositionLock = new Object();
then in a number of methods
public int read()..
..
synchronized(repositionLock) {
...
}
you get the idea.
Using an instance of Object makes it hard to see (in profiling tools)
which lock objects are 'hot', or how often a particular lock object is used.
I'd like to replace the generic Object instance with a private type just
for the purpose, like this:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
Why RepositionLock? (curious about origin of the name)
The usage would be the same, but it will then be easier to see if
RandomAccessFile$RepositionLock becomes a choke point.
Any objections or improvements to this proposed 'pattern' and putting it
into various places throughout the class library?
I like it. But, any benefit to having a general class
o.a.h.whatever.LockObject rather than class private?
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: [classlib] Recognizing lock objects
I don't think the goal is performance, but just being able to monitor
what sync blocks are hot via watching the sync objects.
geir
Weldon Washburn wrote:
Tim,
I suspect there may be some JVM internal lock design issues involved in
what
you are suggesting. In specific, I vaguely remember a paper written by
David Bacon that describes lock optimization heuristics based on the
observation that most of the time, the object being locked is an
instance of
a synchronized class.
Maybe it makes sense to build a microbenchmark of what you are suggesting
and run it on several different JVMs? Maybe it makes sense to prototype
Java locking code in a way that VM fat/thin locks like best??
I suspect that your initial goal is classlib performance only. I'd like to
see if we can expand this to JVM-wide system performance. Otherwise we run
the risk of re-optimizing the whole stack and re-opening the classlib lock
design at a later date. :(
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
There are a number of places in the class library code where we create
an object solely to use as a synchronized block 'lock'.
For example, in RandomAccessFile we define a
private Object repositionLock = new Object();
then in a number of methods
public int read()..
..
synchronized(repositionLock) {
...
}
you get the idea.
Using an instance of Object makes it hard to see (in profiling tools)
which lock objects are 'hot', or how often a particular lock object is
used.
I'd like to replace the generic Object instance with a private type just
for the purpose, like this:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
The usage would be the same, but it will then be easier to see if
RandomAccessFile$RepositionLock becomes a choke point.
Any objections or improvements to this proposed 'pattern' and putting it
into various places throughout the class library?
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]
Re: [classlib] Recognizing lock objects
Geir Magnusson Jr. wrote:
I don't think the goal is performance, but just being able to monitor
what sync blocks are hot via watching the sync objects.
What I meant to say was that it's not the performance of the lock
objects themselves, but the overall performance of the code that uses
it, hence looking for a better way to identify hot lock objects.
And therefore, I now grok why we can't have a global one. :)
geir
Weldon Washburn wrote:
Tim,
I suspect there may be some JVM internal lock design issues involved
in what
you are suggesting. In specific, I vaguely remember a paper written by
David Bacon that describes lock optimization heuristics based on the
observation that most of the time, the object being locked is an
instance of
a synchronized class.
Maybe it makes sense to build a microbenchmark of what you are suggesting
and run it on several different JVMs? Maybe it makes sense to prototype
Java locking code in a way that VM fat/thin locks like best??
I suspect that your initial goal is classlib performance only. I'd
like to
see if we can expand this to JVM-wide system performance. Otherwise
we run
the risk of re-optimizing the whole stack and re-opening the classlib
lock
design at a later date. :(
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
There are a number of places in the class library code where we create
an object solely to use as a synchronized block 'lock'.
For example, in RandomAccessFile we define a
private Object repositionLock = new Object();
then in a number of methods
public int read()..
..
synchronized(repositionLock) {
...
}
you get the idea.
Using an instance of Object makes it hard to see (in profiling tools)
which lock objects are 'hot', or how often a particular lock object is
used.
I'd like to replace the generic Object instance with a private type just
for the purpose, like this:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
The usage would be the same, but it will then be easier to see if
RandomAccessFile$RepositionLock becomes a choke point.
Any objections or improvements to this proposed 'pattern' and putting it
into various places throughout the class library?
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]
-
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] creation of jdktools
yep, that's the plan. And once we have that, we can simplify the launcher as well... Tim Ellison wrote: +1 for creating a jdktools directory. The dependency on the classlib launcher should be relatively light if we go with a simple tools launcher that rewrites the tool invocation into a generic launcher invocation. You may recall the idea was discussed a while ago. So, for example, jdk/bin/javac -source 1.5 -J-Xmx200M FooBar is rewritten to jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M org.apache.harmony.tools.javac.Main -source 1.5 FooBar and so on. Regards, Tim Geir Magnusson Jr. wrote: Geir Magnusson Jr. wrote: Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd like to organize these and add them to the next snapshot. My bad - the javap isn't being voted on yet. I was thinking of the jdwp vote... sorry So I propose adding a new top-level directory called jdktools (and rename tools to project_tools) and create a build target that - with a dependency on classlib for the launcher - creates the 'stuff' needed to fill into the JDK. Any comments? 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: Where to put the tools.... (was Re: [vote] HARMONY-1410 : JDWP agent for DRLVM)
Ivan Popov wrote: --- I'd like to see JDWP unit tests included into regular tests runs, they often reveal problems with JVMTI and JNI support when JVM implementation is changed. I'm not sure that unit tests are provided with other tools and included into tests run, and this can be a separate topic for discussion. Yah, I've been noting that in JVMTI commit messages - we need a suite of JVMTI tests, and I guess we can use the agent for it? 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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Alexei Zakharov wrote: Hi, 2006/10/2, Vladimir Ivanov [EMAIL PROTECTED]: On 10/2/06, Mark Hindess [EMAIL PROTECTED] wrote: I think we need more than one tests.jar. In fact, I think we need more than one tests.jar per module since some tests need to be on the bootclasspath while others do not (and should not). At the moment it might be necessary to have more since there isn't really a way to distinguish api/internal tests (this might change if/when we move to testng). Almost all API tests can be run through the bootclasspath. May be we just waiting for something like TestNG (or other solution) and will create one test.jar for each module? Juist my two cents. Some test even from such a high-level module as beans fail if they run from bootclasspath (BeansTest for example). Moreover, they crash DRLVM :) BTW, personally I use custom-made build file to develop with HDK and single-module checkout. Wouldn't this be something nice to show people? :) geir Regards, - 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][jmx] Options for going forward w/ MX4J
Thanks for the comments, Simone. I'm hoping that at some point in the near future, we can think about doing other things that bring the communities closer together, but this is a great first step. geir Simone Bordet wrote: Hi, On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: I've been talking with Simone Bordet about how we might bring MX4J into Harmony. I think it's a good code base to build our JMX implementation on, as it's well tested and has been used in implementations that have been tested with the JMX TCK. (We can't say that MX4J passes, as I don't believe the project has a TCK). MX4J has served many people over many years, and it's a shame that the addition of JMX into the SE platform has sent this project into it's golden years. I see it a bit differently -- it is a testament to the quality and broad use of MX4J that has helped make JMX a compelling addition to Java SE. I join you in commending Simone and the other contributors for their work. Thanks for the kind words. There were a lot of issues discussed, mainly about user support, time Simone could commit to help us, etc , and in summary, it boils down to this : Simone has no problem with us doing a gentle fork (in his words) of the code to build on. By this, we are simply taking a snapshot of the project codebase, and building upon it. This is not a hostile, anti-community act, but simply a recognition that it's useful code for us, we want to keep building on the code base, but need to make modifications for java SE 5 that are incompatible with the needs of the pre-Java 5 users that the MX4J project support. I read this as an indication that MX4J has no interest in pursuing a 5.0 compatible implementation? Likewise we have no interest in distributing a 1.4 version. Correct. My take on the issue is that there is no point for MX4J to implement JMX 1.3 (shipped in JDK 5), since it will be very rare that people will put such an alternative implementation in the boot classpath before the JDK classes. I think implementing JMX 1.3 belongs more to an effort such as Harmony, or such as Application Servers heavily based on JMX that support J2EE 5. Presumably all the enhancements that are made in the Harmony SVN tree are 'our new enhancements', so identifying them will not be a problem. Putting the code into standard sounds like the right answer. I assume that in this scenario, and unlike concurrent, we do not attempt to keep the two sites in sync. This is also my thinking. We can agree on a best effort communication where mx4j notifies harmony-dev of bugs discovered in mx4j, or of new releases, and harmony can communicate bugs to mx4j, with the goal of saving time and energy, but not with the goal of keeping the codebases in sync. Regards, Simon - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r450941 - in /incubator/harmony/enhanced/drlvm/trunk/vm: gc/src/ vmcore/include/ vmcore/src/util/
definitely top of my list for this morning. I'm hoping it was nothing more than what you describe. geir Ivan Volosyuk wrote: Geir, it was JIRA 1372. Currently it is marked as closed after these commits. It looks like it doesn't compile due to the same mistake Weldon made after me. To new files was not added to the SVN and only existed in local copy of repository. Please deal with the JIRA, either reopen it or commit it again with the new files added. -- Ivan On 9/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: geirm Date: Thu Sep 28 10:53:54 2006 New Revision: 450941 URL: http://svn.apache.org/viewvc?view=revrev=450941 Log: Rollback of r450918, r450919 (HARMONY-1372 it appears) via : $ svn merge -r 450919:450917 https://svn.apache.org/repos/asf/incubator/harmony/enhanced/drlvm/trunk Uvm/gc/src/prepare.cpp Uvm/gc/src/gc_for_vm.cpp Uvm/gc/src/init.cpp Uvm/gc/src/collect_forced.cpp Uvm/gc/src/collect_cache.cpp Uvm/gc/src/slide_compact.h Uvm/gc/src/collect_slide_compact.cpp Uvm/gc/src/collect_copy.cpp Uvm/gc/src/selector.cpp Uvm/gc/src/gc_types.h Uvm/gc/src/collect.cpp Uvm/gc/src/timer.h Uvm/gc/src/root_set_cache.h Uvm/gc/src/collect.h Uvm/vmcore/src/util/mem_alloc.cpp because it doesn't build, even after a clean, on this box anyway - Ubuntu 6. We'll investigate after the snapshot is done. Modified: incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect.h incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect_cache.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect_copy.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect_forced.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect_slide_compact.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/gc_for_vm.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/gc_types.h incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/init.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/prepare.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/root_set_cache.h incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/selector.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/slide_compact.h incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/timer.h incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/version_svn_tag.h incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/mem_alloc.cpp Modified: incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect.cpp URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect.cpp?view=diffrev=450941r1=450940r2=450941 - 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] Should URLClassLoader convert class names? (See HARMONY-1622)
Tim Ellison wrote: FWIW the version in the IBM VME explicitly converts '/' to '.' in the Main-Class: value before looking up the class. I suggest we support both, IMHO nobody will be relying on it failing with '/'s. Sure, but the question is where. JarRunner or ClassLoader... geir Regards, Tim Geir Magnusson Jr. wrote: Looking at HARMONY-1622, I'm not convinced that we need to change JarRunner in DRLVM, but rather should figure out what the right thing to do is in classlib. The issue is having a MainClass in the manifest contain / : geir/GeirTest versus geir.GeirTest My simple quick test showed that the RI will throw an exception with the / and be ok w/ the . Currently, it's reported in 1622 that o.a.h.a.t.j.u.j.JarOutputStreamTest fails on the / in the main class name. I think that's actually right, if we want to conform to the RI. Right now, though, either J9 does the conversion in it's JarRunner, or internally it's classloader infrastructure is more tolerant. Comments? 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: [classlib] Should URLClassLoader convert class names? (See HARMONY-1622)
Ya know... I looked and looked for that in the classLoader docs... I kept skipping over it for some reason Agreed. Tim Ellison wrote: Geir Magnusson Jr. wrote: Tim Ellison wrote: FWIW the version in the IBM VME explicitly converts '/' to '.' in the Main-Class: value before looking up the class. I suggest we support both, IMHO nobody will be relying on it failing with '/'s. Sure, but the question is where. JarRunner or ClassLoader... In JarRunner. The ClassLoader spec states that : Binary names Any class name provided as a String parameter to methods in ClassLoader must be a binary name as defined by the Java Language Specification. Examples of valid class names include: java.lang.String javax.swing.JSpinner$DefaultEditor java.security.KeyStore$Builder$FileBuilder$1 java.net.URLClassLoader$3$1 Regards, Tim Geir Magnusson Jr. wrote: Looking at HARMONY-1622, I'm not convinced that we need to change JarRunner in DRLVM, but rather should figure out what the right thing to do is in classlib. The issue is having a MainClass in the manifest contain / : geir/GeirTest versus geir.GeirTest My simple quick test showed that the RI will throw an exception with the / and be ok w/ the . Currently, it's reported in 1622 that o.a.h.a.t.j.u.j.JarOutputStreamTest fails on the / in the main class name. I think that's actually right, if we want to conform to the RI. Right now, though, either J9 does the conversion in it's JarRunner, or internally it's classloader infrastructure is more tolerant. Comments? 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]
[OFFTOPIC] [legal] a solution to our licensing issues with classpath
http://www.mysql.com/company/legal/licensing/foss-exception.html So it seems that the GPL is compatible with the Apache License, because MySQL says so, at least for Apache code they want to use, like APR. I assume this means you could take a small snippet of MySQL, and use it as a bridge between GPL code and Apache Licensed code? Of course, their section 2.2 says you still have to redistribute your source. Suppose we then do the same thing independently, but make it a free license - put out some code under the GPL with an exception that is like the MySQL exception, but omits section 2.2 - doesn't force source redistribution of the Apache Licensed work... Run that by your favorite lawyer, but don't tell them I sent you :) 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][jitrino.JET] -Xem jet: and -Xjit jet::wb4j don't work anymore
On Sep 29, 2006, at 12:03 AM, Weldon Washburn wrote: On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 28, 2006, at 9:39 PM, Weldon Washburn wrote: On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Have you tried using a colon rather than a space after -Xem? Well, the -X... is unsuported old style switches. You sure? Anything that is prefixed with -Xem: will be processed. Whether or not the em deals with it is another story. Did you actually try it? I hacked around with it and got the following response: C:\t_harmony\drlvm\trunk\vm\MMTkc:\t_harmony\drlvm\trunk\build \win_ia32_msvc_de bug\deploy\jre\bin\java.exe -Xbootclasspath/p:.;mmtk.jar - Xjit:jet::wb4j TestGe nMS 2 * *WARNING ! * * Command line options in form of -Xjit jet::arg are deprecated ! * * * * The jet:: parameters are IGNORED * * * * To pass arguments to Jitrino.JET use * * -Djit.jit_name.arg=value * * Use * * -Djit.jit_name.show=help * * to get the list of supported args.* * LOL. Yep, I guess they're deprecated :) Looking at Jitrino code, the new style looks like: -Djit.jet.arg.log=rt I tried grep'ing for write barrier and vmmagic support in the current harmonydrlvm but can't seem to find anything. Maybe the JIT guys can tell us the status of vmmagic and WB support in both OPT and JET. geir On Sep 28, 2006, at 6:29 PM, Weldon Washburn wrote: Alex Astapchuk, Mikhail Fursov, With the patch blizzard of the last few weeks, Harmony-816 no longer works. The patches won't stick. Can you put harmony-816 back together? Or if it make sense, we can close this JIRA and open another one. In any case, I would like to make forward progress on MMTk port once again. I realize Jitrino.OPT now has write barrier and vmmagic support. I'd still like to keep Jitrino.JET functional. Its much easier to debug with JET. Also, I will get to Jitrino.OPT once I get MMTk moved over to the latest tree. Thanks Weldon -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- 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: harmony-dev- [EMAIL PROTECTED] -- 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: [general] snapshots deployed (r450941)
Indeed! Thanks. I'd rather be lucky than good :) On Sep 29, 2006, at 12:30 AM, Alexey Varlamov wrote: Geir, There was another jira for SUIDs [1], your commit actually fixed it as well. [1] http://issues.apache.org/jira/browse/HARMONY-1361 2006/9/29, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 4:48 PM, Geir Magnusson Jr. wrote: Snapshots are built, tested and deployed to site. I found a few things while testing, such as not being able to run jedit out of the box on windows. (HARMONY-1639) Ran fine on linux though, but that's an older version. I'll check with latest. yep - same bug shows itself on linux Also re-discovered a problem that we knew about, that we don't seem to be calculating serialVersionUIDs right. (HARMONY-1123). I'm going to look at that now, as that's keeping us from running Geronimmo 1.1.1, which I think would be useful. Ok - fixed that (and we really need to some tests for this as I'm not convinced it's 100% right yet as the spec is so lousy...), but now we have another good one , HARMONY-1641, where on startup of Geronimo 1.1.1, we have trouble finding CGLIB-enhanced classes (or a G classloader does, but we're involved...) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [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] snapshots deployed (r450941)
Doh! Sorry. My fault. Fixed. geir On Sep 29, 2006, at 3:58 AM, Dmitry Durnev wrote: I can't download Windows snapshots, both JRE HDK, I get: Forbidden You don't have permission to access /dist/incubator/harmony/snapshots/latest-harmony-jre-windows.zip on this server. :( Linux snapshots are OK. On 9/29/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Snapshots are built, tested and deployed to site. I found a few things while testing, such as not being able to run jedit out of the box on windows. (HARMONY-1639) Ran fine on linux though, but that's an older version. I'll check with latest. Also re-discovered a problem that we knew about, that we don't seem to be calculating serialVersionUIDs right. (HARMONY-1123). I'm going to look at that now, as that's keeping us from running Geronimmo 1.1.1, which I think would be useful. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Dmitry A. Durnev, 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: snapshot...
sorry - fixed (someone else pointed it out...) On Sep 29, 2006, at 4:49 AM, Vladimir Ivanov wrote: Geir, could you please add r'reading' permission to HDK file? Now server says: Forbidden You don't have permission to access /dist/incubator/harmony/snapshots/latest-harmony-hdk-windows.zip on this server thanks, Vladimir On 9/29/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/9/28, Mark Hindess [EMAIL PROTECTED]: On 28 September 2006 at 19:56, Tim Ellison [EMAIL PROTECTED] wrote: Martin Cordova wrote: Hello, will this snapshot include the recent ImageIO contributions? No, that will have to wait for the snapshot after it has been voted in. You should be able to combine the contribution with the snapshot quite easily if you choose. Not that easily. There are no build scripts in the contribution - though the comments indicate that a patch will be contributed. Yep, I'm going to prepare build files in next few days. And svn add script as it required by good issue resolution guideline :) SY, Alexey -- 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: harmony-dev- [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: [launcher] let's fix JAVA_HOME issue finally
On Sep 29, 2006, at 8:04 AM, Alexey Varlamov wrote: Folks, It appears we did not fixed dependency on environmental var JAVA_HOME yet. Rather than pushing workarounds to build scripts (like HARMONY-1569), let's fix the root cause! That wasn't a workaround, IMO, but getting things explicit. Can somebody express some reason why launcher should depend on JAVA_HOME value? If no objections, suggested fix is at HARMONY-1646. We've agreed to punt on JAVA_HOME, so thanks for the patch. geir -- Regadrs, Alexey - 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]
