Re: [general] POLL : supported platforms
1. Windows XP x86, Windows Server 2003 x86 (32bit) 2. Linux SLES 9 32bit 3. Linux SUSE 9 64bit 3. Linux SLES 9 IPF Thank you, Pavel On 10/17/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: My vote: FC4/5, Suse11, Windows XP/2003 X86 (both 32bit and 64bit), and IPF I guess it's a bit unclear to say IA64 in the community. It would be clearer to use X86 64bit or IPF (Itanium). Thanks, xiaofeng On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: We're a volunteer project, so supported is based on interest in community. Lets be clear by writing down a set of platforms that we as a community commit to support. I think we can define support as - one or more people in the community tests on that platform on a regular basis, there are users that use that platform, and we have people volunteering to find and fix bugs that specifically affect that platform Just throw things out there and we'll gather the results and see what's popular. We'll summarize in 3 days. Please be clear in indicating what you think should be reported. Don't vote against anything. To start, using a broad brush : Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 - 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] “java.compiler” property
2006/10/17, Mikhail Fursov [EMAIL PROTECTED]: On 10/17/06, Pavel Pervov [EMAIL PROTECTED] wrote: Mikhail, EM, as I see it, is interchangeable component. Should we require defining java.compiler for interpreted mode from all EMs? EM does not know the semantic of options it adds to the system properties. See client.emconf file to see how options are passed to JIT and EM knows nothing about their meaning. EM configuration is very convenient place to put all options that affect the current execution mode. And if you want to have meaningful java.compiler option a EM configuration file is the only place. My idea is to initialize java.compiler to some default value (none?) in VM, and then overwrite it with actual value wherever actual information is available (in EM in our case). EM does not override system options that are already set. Such a behaviour allows to make cmd-line option to have higher priority then those in EM configuration file. I would vote to keep the behaviour. This behaviour is fairly reasonable and I agree we should keep it. To solve Pavel's concerns, VM could set this property after EM init if needed. Though this might feel like a hack, this is a matter of when and how VM initializes Java properties (aka public in a recent thread) with default values. Seemingly default Java properties are not significant for components loading and should be set after all components init, no overriding. And one question follows: what if we have three different JITs defined in EM configuration file? :) What value java.compiler will contain in this case? client.emconf already has 3 JITS configured inside. The common name for the configuration is 'client mode' -- Mikhail Fursov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][awt] Does Harmony awt support win.xpstyle.dllName desktop property in windows XP?
Hi, does Harmony awt support win.xpstyle.dllName desktop property in
windows XP?
Consider following code:
public static void main(String[] args) {
Toolkit toolkit = Toolkit.getDefaultToolkit();
String xpstyleDll = (String) toolkit
.getDesktopProperty(win.xpstyle.dllName);
System.out.println(xpstyleDll);
}
RI Output:
C:\WINDOWS\resources\Themes\luna\luna.msstyles
Harmony Output:
null
--
Best regards,
Andrew Zhang
Re: [classlib][awt] Does Harmony awt support win.xpstyle.dllName desktop property in windows XP?
No, it doesn't. Unfortunately most of desktop properties are not described
in j2se documentation. If you feel that we need to support this
property please file JIRA issue and we'll try to fix it ASAP.
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi, does Harmony awt support win.xpstyle.dllName desktop property in
windows XP?
Consider following code:
public static void main(String[] args) {
Toolkit toolkit = Toolkit.getDefaultToolkit();
String xpstyleDll = (String) toolkit
.getDesktopProperty(win.xpstyle.dllName);
System.out.println(xpstyleDll);
}
RI Output:
C:\WINDOWS\resources\Themes\luna\luna.msstyles
Harmony Output:
null
--
Best regards,
Andrew Zhang
--
Sergey Soldatov
Intel Middleware Products Division
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Congratulations! Good work!
Re: [classlib][luni]Runtime.exec fails on Linux
Hi, all:
I tried to build drlvm on linux, but when build update, it reports such
error:
[echo] downloading XALAN from no_settings_in_config_or_environment
[echo] no_settings_in_config_or_environment
BUILD FAILED
/root/workspaces/workspace/drlvm/build/make/build.xml:240: The following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:273: The following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:275: The following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:442: Warning: Could
not find file
/root/workspaces/workspace/drlvm/build/make/no_settings_in_config_or_environment
to copy.
How can I do with it?
Thanks.
On 10/17/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/10/16, Leo Li [EMAIL PROTECTED]:
It seems not quite related to actual memory stress although the reported
error is ENOMEM.
I have run it both in eclipse and console. And there are enough memory
available.
Furthermore, the case can be repeated even though in the same time a C
program runs well when using fork().
I suspect that it is related with VM since it can be only reproduced by
VM
calling it. I am not sure whether vm does something behind me, but I
have
not thought out of a way that a user-space program have such effect.:)
Actually drlvm provides own impl of j.l.Process. Interesting, would it
work if switched to classlib's impl - then this should be process impl
issue. Could you please try the following patch with DRLVM and see if
it works?
Index: vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java
===
--- vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java
(revision 464817)
+++ vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java (working
copy)
@@ -743,14 +743,15 @@
//#IN004# Should we check: envp != null ?
//#IN004# Should we check envp's direction values: envp[i] !=
null ?
-String dirPathName = (dir != null ? dir.getPath() : null);
+//String dirPathName = (dir != null ? dir.getPath() : null);
-SubProcess sp = new SubProcess();
+//SubProcess sp = new SubProcess();
-sp.execVM(cmdarray, envp, dirPathName);
+//sp.execVM(cmdarray, envp, dirPathName);
-return sp;
-
+//return sp;
+return org.apache.harmony.luni.internal.process.SystemProcess.
+ create(cmdarray, envp == null ? new String[0] : envp, dir);
}
--
Alexey
On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm confused. Didn't you just report this on Ubuntu?
I have had similar forking problems on Ubuntu 6 (I once found a bug in
classlib related to forking...).
I never figured out why Unbuntu does this, but it seemed that under
memory stress, Ubuntu's fork() fails. Try this - close Eclipse and
run
the test again...
geir
Leo Li wrote:
Thank you.
I have just run it on drlvm of unbuntu, it works.
What a qurious problem!
On 10/16/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Both DRLVM and J9 works for me (SUSE9).
--
Alexey
2006/10/16, Leo Li [EMAIL PROTECTED]:
Hi, all:
The harmony Runtime.exec fails on Linux with ENOMEM.
Here is the testcase:
public class Exec {
public static void main(String[] args) throws Exception {
Runtime.getRuntime().exec(ls);}
}
I have tried it on RedHat Enterprise 4 and Unbuntu, both get
ENOMEM
in
native code.
After digging into it, I found it fails in procimpl.c, line
135:
grdpid = fork ();
If the call to fork is changed to vfork, the testcase will
pass
but
still get exitcode = 1 which indicates that some error has
happened.
The
difference between fork and vfork is just whether page tables is
copied
to
child process or not. But I do not think it is the main cause.
Besides,
vfork has become outdated since it main usage is supplied by fork
with
copy-on-write function implemented in modern linux kernel.
Furthermore,
vfork is also not so safe as fork. So I do not think it is the
accepted
way
to solve the problem.
I will try whether it can be reproduced on drlvm of linux since
I
am
not
sure whether it is relevent to VM or classlib. If any drlvm man
can
tell
me
the result, it can avoid my trouble to build it on linux. :)
--
Leo Li
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]
[classlib][luni][charset]Strange behavior of UnicodeBig
Hi all,
I found this when I tried to debug the failure tests of ant on
harmony. Note the output of testcases below.
import java.io.UnsupportedEncodingException;
import java.nio.charset.Charset;
import junit.framework.TestCase;
public class TestCharset extends TestCase {
public void test1() throws UnsupportedEncodingException {
byte[] b = new byte[] { 'a', 'b', 'c' };
String s = new String(b, UnicodeBig);
assertEquals(abc, s);
}
public void test2() {
Charset.forName(UnicodeBig);
}
}
RI:
test1: junit.framework.ComparisonFailure: expected:abc but was:
test2: java.nio.charset.UnsupportedCharsetException: UnicodeBig
Harmony:
test1:java.nio.charset.UnsupportedCharsetException: UnicodeBig
test2:
java.nio.charset.UnsupportedCharsetException: The unsupported charset
name is UnicodeBig
seems RI can recognize the *UnicodeBig* in Constructor of j.l.String,
whereas Harmony does not support this alias at all.
Do you have any concern about that?
--
Tony Wu
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: [drlvm] [testing] Excluding commit tests until the problem is fixed
2006/10/17, Geir Magnusson Jr. [EMAIL PROTECTED]: Rana Dasgupta wrote: On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: So since I don't have Win 2003, I gotta just commit and let someone else test? Any committer have win 2003? I think that it may be hard to find a test at this point that fails on Windows Server 2003, but passes on XP. But perf etc. characteristics will be different. At some point, gc_v5 etc. is likely to have server specific variations, eg., parallel gc may be on server only. Are we talking of tests in general? I am sorry, but I may not have understood the comment. There is a test that demonstrates a Win 2003 bug... I can just commit it and let someone confirm since I don't have a win 2003 machine It would be nice if Gregory confirmed that Win XP and Win 2003 machines which he compared have identical HW - this might be multicore vs single-CPU (HT does not count) specific rather than OS? Gregory? geir Thanks, Rana - 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][luni]Runtime.exec fails on Linux
This is due to incorrect classlib location specified. Please ensure
you provide correct (better absolute) path in build\drlvm.properties
(if you use it) or external.dep.CLASSLIB.loc property value in
cmdline:
sh build.sh -Dexternal.dep.CLASSLIB.loc=$classlib
This should point to the root of (pre-)built classlib WS.
2006/10/17, Leo Li [EMAIL PROTECTED]:
Hi, all:
I tried to build drlvm on linux, but when build update, it reports such
error:
[echo] downloading XALAN from no_settings_in_config_or_environment
[echo] no_settings_in_config_or_environment
BUILD FAILED
/root/workspaces/workspace/drlvm/build/make/build.xml:240: The following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:273: The following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:275: The following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:442: Warning: Could
not find file
/root/workspaces/workspace/drlvm/build/make/no_settings_in_config_or_environment
to copy.
How can I do with it?
Thanks.
On 10/17/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/10/16, Leo Li [EMAIL PROTECTED]:
It seems not quite related to actual memory stress although the reported
error is ENOMEM.
I have run it both in eclipse and console. And there are enough memory
available.
Furthermore, the case can be repeated even though in the same time a C
program runs well when using fork().
I suspect that it is related with VM since it can be only reproduced by
VM
calling it. I am not sure whether vm does something behind me, but I
have
not thought out of a way that a user-space program have such effect.:)
Actually drlvm provides own impl of j.l.Process. Interesting, would it
work if switched to classlib's impl - then this should be process impl
issue. Could you please try the following patch with DRLVM and see if
it works?
Index: vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java
===
--- vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java
(revision 464817)
+++ vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java (working
copy)
@@ -743,14 +743,15 @@
//#IN004# Should we check: envp != null ?
//#IN004# Should we check envp's direction values: envp[i] !=
null ?
-String dirPathName = (dir != null ? dir.getPath() : null);
+//String dirPathName = (dir != null ? dir.getPath() : null);
-SubProcess sp = new SubProcess();
+//SubProcess sp = new SubProcess();
-sp.execVM(cmdarray, envp, dirPathName);
+//sp.execVM(cmdarray, envp, dirPathName);
-return sp;
-
+//return sp;
+return org.apache.harmony.luni.internal.process.SystemProcess.
+ create(cmdarray, envp == null ? new String[0] : envp, dir);
}
--
Alexey
On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm confused. Didn't you just report this on Ubuntu?
I have had similar forking problems on Ubuntu 6 (I once found a bug in
classlib related to forking...).
I never figured out why Unbuntu does this, but it seemed that under
memory stress, Ubuntu's fork() fails. Try this - close Eclipse and
run
the test again...
geir
Leo Li wrote:
Thank you.
I have just run it on drlvm of unbuntu, it works.
What a qurious problem!
On 10/16/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Both DRLVM and J9 works for me (SUSE9).
--
Alexey
2006/10/16, Leo Li [EMAIL PROTECTED]:
Hi, all:
The harmony Runtime.exec fails on Linux with ENOMEM.
Here is the testcase:
public class Exec {
public static void main(String[] args) throws Exception {
Runtime.getRuntime().exec(ls);}
}
I have tried it on RedHat Enterprise 4 and Unbuntu, both get
ENOMEM
in
native code.
After digging into it, I found it fails in procimpl.c, line
135:
grdpid = fork ();
If the call to fork is changed to vfork, the testcase will
pass
but
still get exitcode = 1 which indicates that some error has
happened.
The
difference between fork and vfork is just whether page tables is
copied
to
child process or not. But I do not think it is the main cause.
Besides,
vfork has become outdated since it main usage is supplied by fork
with
copy-on-write function implemented in modern linux kernel.
Furthermore,
vfork is also not so safe as fork. So I do not think it is the
accepted
way
to solve the problem.
I will try whether it can be reproduced on drlvm of linux since
I
am
not
sure whether it is relevent to VM or classlib. If any drlvm man
can
tell
me
Re: [classlib][awt] Does Harmony awt support win.xpstyle.dllName desktop property in windows XP?
On 10/17/06, Sergey Soldatov [EMAIL PROTECTED] wrote:
No, it doesn't. Unfortunately most of desktop properties are not described
in j2se documentation. If you feel that we need to support this
property please file JIRA issue and we'll try to fix it ASAP.
Thanks Sergey! A JIRA issue (
http://issues.apache.org/jira/browse/HARMONY-1887) was filed. :-)
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi, does Harmony awt support win.xpstyle.dllName desktop property in
windows XP?
Consider following code:
public static void main(String[] args) {
Toolkit toolkit = Toolkit.getDefaultToolkit();
String xpstyleDll = (String) toolkit
.getDesktopProperty(win.xpstyle.dllName);
System.out.println(xpstyleDll);
}
RI Output:
C:\WINDOWS\resources\Themes\luna\luna.msstyles
Harmony Output:
null
--
Best regards,
Andrew Zhang
--
Sergey Soldatov
Intel Middleware Products Division
--
Best regards,
Andrew Zhang
Re: [j9][testing] some classlib unit tests fail
I think that the best choice is to fix the test by implementing test's
security manager. It would make the test be independent from
environment.
As a short-term solution the test run script may be fixed (use option
'-Djava.security.policy==').
Thanks,
Boris
On 10/17/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote:
Hello Boris,
I'm not an expert in security. I even couldn't keep a pin of my credit
card secured from my wife. :-)
Anyway, few weeks ago I faced a problem with tests which failed due to
java.policy file forgotten by a release engineer in his home directory.
We decided that changing the java.security.policy property and invoking
refresh() is a hacker style, so we had to write our security manager
implementation. I have just checked that the guy who actually made the
fix implemented the property hack.
That is why I vote for the second choice. It is much simpler and we can
migrate to the first method later if needed.
Does it make sense?
With best regards,
Alexei Fedotov,
Intel Middleware Products Division
-Original Message-
From: Boris Kuznetsov [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 04, 2006 1:24 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [j9][testing] some classlib unit tests fail
The tests mentioned in HARMONY-1674
http://issues.apache.org/jira/browse/HARMONY-1674 depend on default
system policy file.
But if user policy file exists than, according to the spec, it is
added to system policy. It leads to the tests failures.
There are two options:
1. Rewrite the tests.
2. Use '-Djava.security.policy' to specify policy file and ignore
all
others:
-Djava.security.policy==${java.home}/lib/security/java.policy
I suggest the second one.
Comments?
On 10/4/06, Elena Semukhina [EMAIL PROTECTED] wrote:
Hello, all,
AFAIK, ant test should give 100% pass rate on j9 but I have 5
failures
which seem to be dependent on environment.
I've uploaded the results at
http://harmonytest.org/testapp.do?method=showrunid=9perPage=100page=
1na
me=result=0jira=0
There are also two JIRA issues detailing this:
HARMONY-1664http://issues.apache.org/jira/browse/HARMONY-1664 and
HARMONY-1674 http://issues.apache.org/jira/browse/HARMONY-1664
Can anyone help in analyzing the problem?
--
Thanks,
Elena
--
Best regards,
Boris Kuznetsov
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]
--
Best regards,
Boris Kuznetsov
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni][charset]Strange behavior of UnicodeBig
I think Harmony is more reasonable.
As spec says, if Charset.forName(UnicodeBig) throws
.UnsupportedCharsetException then no support for the named charset is
available in this instance of the Java virtual machine. Then how can we get
new String(b, UnicodeBig) without throwing UnsupportedCharsetException on
the same jvm? The spec for String(byte[] bytes,String charsetName) also says
if the named charset is not supported, UnsupportedCharsetException should be
thrown out.
On 10/17/06, Tony Wu [EMAIL PROTECTED] wrote:
Hi all,
I found this when I tried to debug the failure tests of ant on
harmony. Note the output of testcases below.
import java.io.UnsupportedEncodingException;
import java.nio.charset.Charset;
import junit.framework.TestCase;
public class TestCharset extends TestCase {
public void test1() throws UnsupportedEncodingException {
byte[] b = new byte[] { 'a', 'b', 'c' };
String s = new String(b, UnicodeBig);
assertEquals(abc, s);
}
public void test2() {
Charset.forName(UnicodeBig);
}
}
RI:
test1: junit.framework.ComparisonFailure: expected:abc but was:
test2: java.nio.charset.UnsupportedCharsetException: UnicodeBig
Harmony:
test1:java.nio.charset.UnsupportedCharsetException: UnicodeBig
test2:
java.nio.charset.UnsupportedCharsetException: The unsupported charset
name is UnicodeBig
seems RI can recognize the *UnicodeBig* in Constructor of j.l.String,
whereas Harmony does not support this alias at all.
Do you have any concern about that?
--
Tony Wu
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]
--
Leo Li
China Software Development Lab, IBM
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
My congratulations! Let's move the project faster! :) On 10/17/06, Sergey Soldatov [EMAIL PROTECTED] wrote: Congratulations! Good work! -- Mikhail Fursov
Re: [classlib]Harmony passes 73% on Derby.
Leo, just a simple interest, could you try to run harmony with -Xem:opt, -Xem:jet, -Xem:server, -Xem:server_static options? These are all modes drlvm supports today except the default one (-Xem:client) For example if the test passes with Jitrino.JET (-Xem:jet) and fails with Jitrino.OPT (-Xem:opt) this is a good candidate for JIT bug On 10/17/06, Leo Li [EMAIL PROTECTED] wrote: Hi, The result of Derby is not so obvious, since its test is not junit but some a serial of stand-alone java program calling each other. And the comparing result is a pre-stored data file. So I have to use sometime to set aside all the irrelevant code to spot those related with Harmony classlib. What makes things worse is that as a product, all the exception has been caught... Is there someone who has good idea to pick up problem quickly in this issue? On 10/17/06, Nathan Beyer [EMAIL PROTECTED] wrote: Are there any obvious bugs in Harmony that are of note? Perhaps some unexpected NPEs? On 10/16/06, Leo Li [EMAIL PROTECTED] wrote: Hi, all: I have ran the tests of Derby on Harmony, both on windows xp and ubuntu. The result is similar. On windows, 579 Tests Run 73% Pass (428 tests passed) 27% Fail (151 tests failed) 9 Suites skipped On linux, 579 Tests Run 74% Pass (430 tests passed) 26% Fail (149 tests failed) 9 Suites skipped The result seems a little frustrating since Sian had 82% passed several months before. The version of derby I ran is at revision 464429. The lost passing rate may be due to the modified code and added testcases. To Sian: I made a new patch in the attachment which is an updated version of the patch Sian provides. I will be appreciate if Sian helps to check its validity and thus I will be assured that the lost passing rate is irrelevant to our modification. When I can confirm everything is all right, I will then put the ongoing progress result on Harmony's wiki page. Thank you. -- Leo Li 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Leo Li China Software Development Lab, IBM -- Mikhail Fursov
[DRLVM](JIRA-1886)interior pointer for GCv5 of DRLVM
Hi, the patch attached in JIRA 1886 is an implementation of interior pointer for GCv5 of DRLVM. It would be great if some commiter can help to review and commit it. http://issues.apache.org/jira/browse/HARMONY-1886 Repeat the desciption : Attached patch is an implementation of interior pointer support for GCv5 of DRLVM. To apply the patch, please enter gc_gen/ directory and type `patch -p0 `. This is needed for GCv5 to work with Jitrino.OPT. Since it has no impact on other component, I'd hope it can be committed as early as possible so as to enable GCv5 with Jitrino.OPT. The patch is based on revision 464099. I hope it can be committed to Harmony soon. Thanks. Regards! Yu-Nan
Re: [DRLVM](JIRA-1886)interior pointer for GCv5 of DRLVM
Yu-Nan, to make GCv5 to work with Jitrino.OPT you need WB support. Do you need a help to implement it or you already have the implementation? On 10/17/06, yunan He [EMAIL PROTECTED] wrote: Hi, the patch attached in JIRA 1886 is an implementation of interior pointer for GCv5 of DRLVM. It would be great if some commiter can help to review and commit it. http://issues.apache.org/jira/browse/HARMONY-1886 Repeat the desciption : Attached patch is an implementation of interior pointer support for GCv5 of DRLVM. To apply the patch, please enter gc_gen/ directory and type `patch -p0 `. This is needed for GCv5 to work with Jitrino.OPT. Since it has no impact on other component, I'd hope it can be committed as early as possible so as to enable GCv5 with Jitrino.OPT. The patch is based on revision 464099. I hope it can be committed to Harmony soon. Thanks. Regards! Yu-Nan -- Mikhail Fursov
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
My congratulations! Thanks, Valdimir On 10/17/06, Ilya Okomin [EMAIL PROTECTED] wrote: Congratulations! On 10/17/06, Mikhail Fursov [EMAIL PROTECTED] wrote: My congratulations! Let's move the project faster! :) On 10/17/06, Sergey Soldatov [EMAIL PROTECTED] wrote: Congratulations! Good work! -- Mikhail Fursov -- -- Ilya Okomin Intel Middleware Products Division
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Congratulations! Well done! 2006/10/17, Ilya Okomin [EMAIL PROTECTED]: Congratulations! On 10/17/06, Mikhail Fursov [EMAIL PROTECTED] wrote: My congratulations! Let's move the project faster! :) On 10/17/06, Sergey Soldatov [EMAIL PROTECTED] wrote: Congratulations! Good work! -- Mikhail Fursov -- -- Ilya Okomin Intel Middleware Products Division -- Igor V. Stolyarov Intel Middleware Products Division
Re: [general] POLL : supported platforms
What a flame! :) I am afraid of supporting Gentoo, it's so diverse inside :) For now, my vote would go to: Linux(Ubuntu/Debian/SUSE/FC)/i686/x86_64/gcc-4.1 (all combinations) (to be changed in future) and, yes, windoze.. On the 0x205 day of Apache Harmony Gregory Shimansky wrote: I have Gentoo with gcc 4.1.1 on x86 and x86_64 and I have Windows XP and Windows 2003 server on x86. I also have Windows XP with VS.NET 2005 Community Edition but so far experimenting with 100% free toolchaing on windows shows that it requires a lot of effort to make even classlib work with IBM VME (last time I did it was several months ago so I cannot give a current status), not to mention compiling drlvm on it. It is because of Microsoft secure API initiative, DLL manifests and stuff like that in VS.NET 2005. This is probably a subject for a separate discussion. On Monday 16 October 2006 19:57 Geir Magnusson Jr. wrote: We're a volunteer project, so supported is based on interest in community. Lets be clear by writing down a set of platforms that we as a community commit to support. I think we can define support as - one or more people in the community tests on that platform on a regular basis, there are users that use that platform, and we have people volunteering to find and fix bugs that specifically affect that platform Just throw things out there and we'll gather the results and see what's popular. We'll summarize in 3 days. Please be clear in indicating what you think should be reported. Don't vote against anything. To start, using a broad brush : Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM](JIRA-1886)interior pointer for GCv5 of DRLVM
Mikhail, I have prepared a Jitrino.OPT write barrier implementation and will send it to you for review soon. Thanks. BTW, did the JET WB4C patch commit to the harmony? Yu-Nan On 10/17/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yu-Nan, to make GCv5 to work with Jitrino.OPT you need WB support. Do you need a help to implement it or you already have the implementation? On 10/17/06, yunan He [EMAIL PROTECTED] wrote: Hi, the patch attached in JIRA 1886 is an implementation of interior pointer for GCv5 of DRLVM. It would be great if some commiter can help to review and commit it. http://issues.apache.org/jira/browse/HARMONY-1886 Repeat the desciption : Attached patch is an implementation of interior pointer support for GCv5 of DRLVM. To apply the patch, please enter gc_gen/ directory and type `patch -p0 `. This is needed for GCv5 to work with Jitrino.OPT. Since it has no impact on other component, I'd hope it can be committed as early as possible so as to enable GCv5 with Jitrino.OPT. The patch is based on revision 464099. I hope it can be committed to Harmony soon. Thanks. Regards! Yu-Nan -- Mikhail Fursov
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
On 17/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committers, in alphabetical order : Oliver Deakin Richard Liang Alexey Petrenko Gregory Shimansky Alexey Varlamov Alexei Zakharov Congratulations guys :-) Alex. - 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] POLL : supported platforms
On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Great! Write that down with your votes. (Note, I was just kicking this off, not being comprehensive...) OK, I'll try to add more restrictions to the list. 1) DRLVM JIT has a limitation today: we can run only on PC with SSE/SSE2 support. This can be an advanced task for JIT gurus to add x87 support, but before that we can't claim that we officially support hardware without SSE2. 2) Do we need to add to the 'officially supported' list platforms that are unable to run HelloWorld app? Maybe we can give another name to the list of such platforms and move a platform into the 'officially supported' list only when it runs simple apps? -- Mikhail Fursov
Re: [drlvm] “java.compiler” property
On 10/17/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Seemingly default Java properties are not significant for components loading and should be set after all components init, no overriding. I'm agree if we are speaking only about default Java properties. VM can set them up right before execution of the first Java method. -- Mikhail Fursov
Re: [classlib][luni]Runtime.exec fails on Linux
Hi, Alexey:
Thank you.
I have started to build the system.
Besides, I think the problem is not related to classlib. Since I have
let fork called in a native function, but it fails on J9.
On 10/17/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
This is due to incorrect classlib location specified. Please ensure
you provide correct (better absolute) path in build\drlvm.properties
(if you use it) or external.dep.CLASSLIB.loc property value in
cmdline:
sh build.sh -Dexternal.dep.CLASSLIB.loc=$classlib
This should point to the root of (pre-)built classlib WS.
2006/10/17, Leo Li [EMAIL PROTECTED]:
Hi, all:
I tried to build drlvm on linux, but when build update, it reports
such
error:
[echo] downloading XALAN from no_settings_in_config_or_environment
[echo] no_settings_in_config_or_environment
BUILD FAILED
/root/workspaces/workspace/drlvm/build/make/build.xml:240: The following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:273: The following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:275: The following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:442: Warning:
Could
not find file
/root/workspaces/workspace/drlvm/build/make/no_settings_in_config_or_environment
to copy.
How can I do with it?
Thanks.
On 10/17/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/10/16, Leo Li [EMAIL PROTECTED]:
It seems not quite related to actual memory stress although the
reported
error is ENOMEM.
I have run it both in eclipse and console. And there are enough
memory
available.
Furthermore, the case can be repeated even though in the same time a
C
program runs well when using fork().
I suspect that it is related with VM since it can be only reproduced
by
VM
calling it. I am not sure whether vm does something behind me, but I
have
not thought out of a way that a user-space program have such
effect.:)
Actually drlvm provides own impl of j.l.Process. Interesting, would it
work if switched to classlib's impl - then this should be process impl
issue. Could you please try the following patch with DRLVM and see if
it works?
Index: vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java
===
--- vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java
(revision 464817)
+++ vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java
(working
copy)
@@ -743,14 +743,15 @@
//#IN004# Should we check: envp != null ?
//#IN004# Should we check envp's direction values: envp[i] !=
null ?
-String dirPathName = (dir != null ? dir.getPath() : null);
+//String dirPathName = (dir != null ? dir.getPath() : null);
-SubProcess sp = new SubProcess();
+//SubProcess sp = new SubProcess();
-sp.execVM(cmdarray, envp, dirPathName);
+//sp.execVM(cmdarray, envp, dirPathName);
-return sp;
-
+//return sp;
+return org.apache.harmony.luni.internal.process.SystemProcess
.
+ create(cmdarray, envp == null ? new String[0] : envp,
dir);
}
--
Alexey
On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm confused. Didn't you just report this on Ubuntu?
I have had similar forking problems on Ubuntu 6 (I once found a
bug in
classlib related to forking...).
I never figured out why Unbuntu does this, but it seemed that
under
memory stress, Ubuntu's fork() fails. Try this - close Eclipse
and
run
the test again...
geir
Leo Li wrote:
Thank you.
I have just run it on drlvm of unbuntu, it works.
What a qurious problem!
On 10/16/06, Alexey Varlamov [EMAIL PROTECTED]
wrote:
Both DRLVM and J9 works for me (SUSE9).
--
Alexey
2006/10/16, Leo Li [EMAIL PROTECTED]:
Hi, all:
The harmony Runtime.exec fails on Linux with ENOMEM.
Here is the testcase:
public class Exec {
public static void main(String[] args) throws Exception {
Runtime.getRuntime().exec(ls);}
}
I have tried it on RedHat Enterprise 4 and Unbuntu, both
get
ENOMEM
in
native code.
After digging into it, I found it fails in procimpl.c,
line
135:
grdpid = fork ();
If the call to fork is changed to vfork, the testcase will
pass
but
still get exitcode = 1 which indicates that some error has
happened.
The
difference between fork and vfork is just whether page tables
is
copied
to
child process or not. But I do not think it is the main
cause.
Besides,
vfork has become outdated since it main usage is supplied by
Re: [general] graduate from incubator to be a Top Level Project of the ASF
On 17/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: The Harmony PPMC has been discussing and has approved asking to graduate from the Apache Incubator and become a Top Level Project. This means that we would become an official project of the Apache Software Foundation. Any comments, for or against? I'm sure such a transition would cause the odd slashdot story etc. upon graduation; I think it would be good advertising to have a list of a few known-good apps that run mostly with Harmony (e.g. ant, eclipse etc.) Although it's still a work-in-progress, it would be a good milestone to state the current achievements (and also to ask for further help :-) Other than that observation, great :-) Alex. - 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-1886)interior pointer for GCv5 of DRLVM
Yu-Nan, Yes, please open new JIRA issue with Jitrino.OPT implementation. On 10/17/06, yunan He [EMAIL PROTECTED] wrote: BTW, did the JET WB4C patch commit to the harmony? AFAIK Jitrino.JET does support WB4C and WB4J today. The code is already in SVN and GCv5 or any other generational GC can be tested with it. -- Mikhail Fursov
RE: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Congratulations to all! -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 7:59 AM To: harmony-dev@incubator.apache.org Subject: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov Please join the Apache Harmony PPMC in welcoming the project's newest committers, in alphabetical order : Oliver Deakin Richard Liang Alexey Petrenko Gregory Shimansky Alexey Varlamov Alexei Zakharov These six individuals have shown sustained dedication to the project, an ability to work well with others, and share the common vision we have for Harmony. We all continue to expect great things from them. Gentlemen, you don't have accounts yet. When you finally receive your new committer account information, as a first step to test your almighty powers of committitude, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine 3) Add a public key to .ssh so you can stop using the password 4) Set your SVN password : just type 'svnpasswd' At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, anything checked out of SVN, be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - 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] The first GC helper with fast-path implemented in Java: gc_alloc
I agree with Robin and Rana both. IMO we should move with small steps and support helpers inlining first as Rana said. (Actually this is a big intercomponent task) After we run primitive 'magic' code safely and we have an experience with 'magics' it will be the time to refactor and take into account everything Robin proposed. As for the task status: I'm going post 2 new threads today: Java annotation access interface and Details on implementation of slow helpers(native) calls from Java. I have a local prototype ready, but it should be discussed before adding to JIRA. On 10/17/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Robin, I found your last set of comments very illuminating. Thanks. On your suggestion below...who would manage this object, ie., construct and populate it, etc. before invoking the helper instance method? The jit? I think that some of the VM specific information has started leaking into the jit already! What if we want to attach a new JIT into Harmony/DRLVM ...what would be the requirements for such a jit? Regarding the terse Java in the fastpath code, what one can do in the fastpaths is somewhat constrained, isn't it? They are mostly uninterruptible, shouldn't raise exceptions, cause gc etc. Our java layer in the infrastructure is somewhat localized. Thanks, Rana On 10/15/06, Robin Garner [EMAIL PROTECTED] wrote: Weldon Washburn wrote: Robin, I really like your thinking! I would like to see Harmony drlvm support MMTk fully. this may take a while. Please feel free to keep pushing to do the right thing with the JIT. Well, with this encouragement, there are a few more things I'd like to suggest: - Rather than make TLS access be a magic, how about defining an object with fields that point to all the VM resources (such as TLS) that a helper wants, and then calling the helper as an instance method of that object ? . If devirtualisation of this is problematic for the JIT at the moment, perhaps introduce a magic pragma instead of the TLS access handler - Mikhail's prototype Java helper looks like C transliterated into Java. This is reminiscent of the very early days of JikesRVM. IMO, you should actually use Java here rather than fight it ... define an abstract Allocator class, and a concrete BumpPointer instance for example. One of the lessons of MMTk was how much you can trust the compiler, and each revision uses more and more object orientation. You guys are in an ideal position, because you have control over the compiler as well as the java code. cheers -- Mikhail Fursov
[drlvm][threading] Is it safe to use hythread_suspend_all and hythread_resume_all?
Hi All, I'd like to here you opinion regarding hythread_suspend_all and hythread_resume_all functionality provided by TM. Actually I have to separate questions: 1) I found that hythread_suspend_all calls thread_safe_point_impl inside. There is no assertion regarding thread's state upon entering hythread_suspend_all. So it can be called in suspend disabled state and nobody (at least me) expects to have a safe point during hythread_suspend_all. The problem seems to be very similar with the one discussed in [drlvm][threading] Possible race condition in implementation of conditional variables? Your thoughts? 2) Assume I need to suspend all threads in particular group. Ok I pass that group to hythread_suspend_all. Later when all suspended threads should be resumed I pass the same group to hythread_resume_all. But threads were suspended group has changed. For example one new thread was added to it. So the questions are. Is it acceptable to have such unsafe functionality? Would it better to lock the group in hythread_suspend_all and unlock it in hythread_resume_all. Thanks Evgueni - 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][unit tests] the goal is to achieve 100% pass rate
It seems that the patch for HARMONY-1751http://issues.apache.org/jira/browse/HARMONY-1751 is ready and the patch for HARMONY-1720http://issues.apache.org/jira/browse/HARMONY-1751 is waiting for Alexey Varlamov's evaluation. On 10/13/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Oops, review of HARMONY-1823 should be: The fix is to clean an interrupt flag. Patches are good. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Fedotov, Alexei A Sent: Friday, October 13, 2006 6:12 PM To: [EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org Subject: RE: [drlvm][unit tests] the goal is to achieve 100% pass rate Geir, I reviewed the patches for HARMONY-1816 (non-daemon thread counting is done more accurately) and for HARMONY-1823 - the fix is to clean patches are good. I believe the patches worth to be committed: I've tried the patches for running tests from luni module 162 times and get the following results: $ grep FAILED luni.log | sort | uniq -c 63 [junit] TEST org.apache.harmony.tests.internal.net.www.protocol.http .HttpURLConnectionTest FAILED 162 [junit] TEST tests.api.java.lang.reflect.FieldTest FAILED 6 [junit] TEST tests.api.java.net.InetAddressTest FAILED The following tests were excluded: Index: modules/luni/build.xml === --- modules/luni/build.xml (revision 463342) +++ modules/luni/build.xml (working copy) @@ -325,6 +325,14 @@ exclude name=tests/api/java/net/URLConnectionTest.jav a / exclude name=tests/api/java/net/URLTest.java / exclude name=tests/api/java/net/SocketPermissionTest. java / + +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadGroupTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadLocalTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ClassTest.java / +exclude name=tests/api/java/util/FormatterTest.java / + /fileset /batchtest With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 9:58 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][unit tests] the goal is to achieve 100% pass rate great work - we'll get those applied ASAP. Elena Semukhina wrote: Yesterday I tried the following patches: http://issues.apache.org/jira/browse/HARMONY-1592 http://issues.apache.org/jira/browse/HARMONY-1816 http://issues.apache.org/jira/browse/HARMONY-1823 https://issues.apache.org/jira/browse/HARMONY-1741 They work fine. The first three patches restore recent classlib tests pass rate degradation. On 10/11/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Excellent. As appreciative as I am of J9, I can't wait to work in all-Harmony code :) geir Elena Semukhina wrote: Hello all, I think that the goal of running classlib unit tests on DRLVM with 100% pass rate could be worth to achieve. Actually today we have 99% (without awt/swing) but still have about 30 failures/errors. Most of them have been evaluated and corresponding JIRAs filed. There is a page on Harmony Wiki which lists those JIRA issues: http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM Are there any volunteers to help with DRLVM bugs fixing? Thanks, Elena - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Elena
Re: [classlib]Harmony passes 73% on Derby.
Mikhail, unfortunately derby test cannot run on drlvm. An assert fail exception will be thrown out. I have talked about it in another thread http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg15643.html and raised jira as 1836. On 10/17/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Leo, just a simple interest, could you try to run harmony with -Xem:opt, -Xem:jet, -Xem:server, -Xem:server_static options? These are all modes drlvm supports today except the default one (-Xem:client) For example if the test passes with Jitrino.JET (-Xem:jet) and fails with Jitrino.OPT (-Xem:opt) this is a good candidate for JIT bug On 10/17/06, Leo Li [EMAIL PROTECTED] wrote: Hi, The result of Derby is not so obvious, since its test is not junit but some a serial of stand-alone java program calling each other. And the comparing result is a pre-stored data file. So I have to use sometime to set aside all the irrelevant code to spot those related with Harmony classlib. What makes things worse is that as a product, all the exception has been caught... Is there someone who has good idea to pick up problem quickly in this issue? On 10/17/06, Nathan Beyer [EMAIL PROTECTED] wrote: Are there any obvious bugs in Harmony that are of note? Perhaps some unexpected NPEs? On 10/16/06, Leo Li [EMAIL PROTECTED] wrote: Hi, all: I have ran the tests of Derby on Harmony, both on windows xp and ubuntu. The result is similar. On windows, 579 Tests Run 73% Pass (428 tests passed) 27% Fail (151 tests failed) 9 Suites skipped On linux, 579 Tests Run 74% Pass (430 tests passed) 26% Fail (149 tests failed) 9 Suites skipped The result seems a little frustrating since Sian had 82% passed several months before. The version of derby I ran is at revision 464429. The lost passing rate may be due to the modified code and added testcases. To Sian: I made a new patch in the attachment which is an updated version of the patch Sian provides. I will be appreciate if Sian helps to check its validity and thus I will be assured that the lost passing rate is irrelevant to our modification. When I can confirm everything is all right, I will then put the ongoing progress result on Harmony's wiki page. Thank you. -- Leo Li 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Leo Li China Software Development Lab, IBM -- Mikhail Fursov -- Leo Li China Software Development Lab, IBM
Re: [classlib][luni][charset]Strange behavior of UnicodeBig
On 10/17/06, Leo Li [EMAIL PROTECTED] wrote:
I think Harmony is more reasonable.
As spec says, if Charset.forName(UnicodeBig) throws
.UnsupportedCharsetException then no support for the named charset is
available in this instance of the Java virtual machine. Then how can we
get
new String(b, UnicodeBig) without throwing UnsupportedCharsetException
on
the same jvm? The spec for String(byte[] bytes,String charsetName) also
says
if the named charset is not supported, UnsupportedCharsetException should
be
thrown out.
UNICODEBIG is a java alias for UTF-16BE. I think we'd better support such
mapping in String and follow RI.
On 10/17/06, Tony Wu [EMAIL PROTECTED] wrote:
Hi all,
I found this when I tried to debug the failure tests of ant on
harmony. Note the output of testcases below.
import java.io.UnsupportedEncodingException;
import java.nio.charset.Charset;
import junit.framework.TestCase;
public class TestCharset extends TestCase {
public void test1() throws UnsupportedEncodingException {
byte[] b = new byte[] { 'a', 'b', 'c' };
String s = new String(b, UnicodeBig);
assertEquals(abc, s);
}
public void test2() {
Charset.forName(UnicodeBig);
}
}
RI:
test1: junit.framework.ComparisonFailure: expected:abc but was:
test2: java.nio.charset.UnsupportedCharsetException: UnicodeBig
Harmony:
test1:java.nio.charset.UnsupportedCharsetException: UnicodeBig
test2:
java.nio.charset.UnsupportedCharsetException: The unsupported charset
name is UnicodeBig
seems RI can recognize the *UnicodeBig* in Constructor of j.l.String,
whereas Harmony does not support this alias at all.
Do you have any concern about that?
--
Tony Wu
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]
--
Leo Li
China Software Development Lab, IBM
--
Best regards,
Andrew Zhang
Re: [classlib]Harmony passes 73% on Derby.
Oh, sorry. I read this thread, it mentions the harmonyvm, the stability degradation in the last months so the first thought was about DRLVM and recent BBC affect :) On 10/17/06, Leo Li [EMAIL PROTECTED] wrote: Mikhail, unfortunately derby test cannot run on drlvm. An assert fail exception will be thrown out. I have talked about it in another thread http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg15643.html and raised jira as 1836. On 10/17/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Leo, just a simple interest, could you try to run harmony with -Xem:opt, -Xem:jet, -Xem:server, -Xem:server_static options? These are all modes drlvm supports today except the default one (-Xem:client) For example if the test passes with Jitrino.JET (-Xem:jet) and fails with Jitrino.OPT (-Xem:opt) this is a good candidate for JIT bug On 10/17/06, Leo Li [EMAIL PROTECTED] wrote: Hi, The result of Derby is not so obvious, since its test is not junit but some a serial of stand-alone java program calling each other. And the comparing result is a pre-stored data file. So I have to use sometime to set aside all the irrelevant code to spot those related with Harmony classlib. What makes things worse is that as a product, all the exception has been caught... Is there someone who has good idea to pick up problem quickly in this issue? On 10/17/06, Nathan Beyer [EMAIL PROTECTED] wrote: Are there any obvious bugs in Harmony that are of note? Perhaps some unexpected NPEs? On 10/16/06, Leo Li [EMAIL PROTECTED] wrote: Hi, all: I have ran the tests of Derby on Harmony, both on windows xp and ubuntu. The result is similar. On windows, 579 Tests Run 73% Pass (428 tests passed) 27% Fail (151 tests failed) 9 Suites skipped On linux, 579 Tests Run 74% Pass (430 tests passed) 26% Fail (149 tests failed) 9 Suites skipped The result seems a little frustrating since Sian had 82% passed several months before. The version of derby I ran is at revision 464429. The lost passing rate may be due to the modified code and added testcases. To Sian: I made a new patch in the attachment which is an updated version of the patch Sian provides. I will be appreciate if Sian helps to check its validity and thus I will be assured that the lost passing rate is irrelevant to our modification. When I can confirm everything is all right, I will then put the ongoing progress result on Harmony's wiki page. Thank you. -- Leo Li 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Leo Li China Software Development Lab, IBM -- Mikhail Fursov -- Leo Li China Software Development Lab, IBM -- Mikhail Fursov
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committers, in alphabetical order : Oliver Deakin Richard Liang Alexey Petrenko Gregory Shimansky Alexey Varlamov Alexei Zakharov Congratulations, Oliver, Richard, Gregory and Alexey(s)! - 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][luni][charset]Strange behavior of UnicodeBig
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 10/17/06, Leo Li [EMAIL PROTECTED] wrote:
I think Harmony is more reasonable.
As spec says, if Charset.forName(UnicodeBig) throws
.UnsupportedCharsetException then no support for the named charset is
available in this instance of the Java virtual machine. Then how can we
get
new String(b, UnicodeBig) without throwing UnsupportedCharsetException
on
the same jvm? The spec for String(byte[] bytes,String charsetName) also
says
if the named charset is not supported, UnsupportedCharsetException
should be
thrown out.
UNICODEBIG is a java alias for UTF-16BE. I think we'd better support such
mapping in String and follow RI.
You can find the encoding set from spec. [1]
[1] http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html
On 10/17/06, Tony Wu [EMAIL PROTECTED] wrote:
Hi all,
I found this when I tried to debug the failure tests of ant on
harmony. Note the output of testcases below.
import java.io.UnsupportedEncodingException;
import java.nio.charset.Charset ;
import junit.framework.TestCase;
public class TestCharset extends TestCase {
public void test1() throws UnsupportedEncodingException {
byte[] b = new byte[] { 'a', 'b', 'c' };
String s = new String(b, UnicodeBig);
assertEquals(abc, s);
}
public void test2() {
Charset.forName(UnicodeBig);
}
}
RI:
test1: junit.framework.ComparisonFailure: expected:abc but was:
test2: java.nio.charset.UnsupportedCharsetException: UnicodeBig
Harmony:
test1:java.nio.charset.UnsupportedCharsetException: UnicodeBig
test2:
java.nio.charset.UnsupportedCharsetException: The unsupported charset
name is UnicodeBig
seems RI can recognize the *UnicodeBig* in Constructor of j.l.String,
whereas Harmony does not support this alias at all.
Do you have any concern about that?
--
Tony Wu
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]
--
Leo Li
China Software Development Lab, IBM
--
Best regards,
Andrew Zhang
--
Best regards,
Andrew Zhang
Re: [DRLVM](JIRA-1886)interior pointer for GCv5 of DRLVM
Mikhail, I can not find the code in SVN and could tell me the revision number? Thanks. Yu-Nan On 10/17/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yu-Nan, Yes, please open new JIRA issue with Jitrino.OPT implementation. On 10/17/06, yunan He [EMAIL PROTECTED] wrote: BTW, did the JET WB4C patch commit to the harmony? AFAIK Jitrino.JET does support WB4C and WB4J today. The code is already in SVN and GCv5 or any other generational GC can be tested with it. -- Mikhail Fursov
Re: [drlvm][unit tests] the goal is to achieve 100% pass rate
I added one more issue to http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM. It is http://issues.apache.org/jira/browse/HARMONY-1648. It is drlvm/TM issue and will cause the ThreadGroupTest failure after HARMONY-1625 is applied. Could anyone look at this issue? On 10/17/06, Elena Semukhina [EMAIL PROTECTED] wrote: It seems that the patch for HARMONY-1751http://issues.apache.org/jira/browse/HARMONY-1751 is ready and the patch for HARMONY-1720http://issues.apache.org/jira/browse/HARMONY-1751 is waiting for Alexey Varlamov's evaluation. On 10/13/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Oops, review of HARMONY-1823 should be: The fix is to clean an interrupt flag. Patches are good. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Fedotov, Alexei A Sent: Friday, October 13, 2006 6:12 PM To: [EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org Subject: RE: [drlvm][unit tests] the goal is to achieve 100% pass rate Geir, I reviewed the patches for HARMONY-1816 (non-daemon thread counting is done more accurately) and for HARMONY-1823 - the fix is to clean patches are good. I believe the patches worth to be committed: I've tried the patches for running tests from luni module 162 times and get the following results: $ grep FAILED luni.log | sort | uniq -c 63 [junit] TEST org.apache.harmony.tests.internal.net.www.protocol.http .HttpURLConnectionTest FAILED 162 [junit] TEST tests.api.java.lang.reflect.FieldTest FAILED 6 [junit] TEST tests.api.java.net.InetAddressTest FAILED The following tests were excluded: Index: modules/luni/build.xml === --- modules/luni/build.xml (revision 463342) +++ modules/luni/build.xml (working copy) @@ -325,6 +325,14 @@ exclude name=tests/api/java/net/URLConnectionTest.jav a / exclude name=tests/api/java/net/URLTest.java / exclude name=tests/api/java/net/SocketPermissionTest. java / + +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadGroupTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadLocalTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ClassTest.java / +exclude name=tests/api/java/util/FormatterTest.java / + /fileset /batchtest With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Geir Magnusson Jr. [mailto: [EMAIL PROTECTED] Sent: Friday, October 13, 2006 9:58 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][unit tests] the goal is to achieve 100% pass rate great work - we'll get those applied ASAP. Elena Semukhina wrote: Yesterday I tried the following patches: http://issues.apache.org/jira/browse/HARMONY-1592 http://issues.apache.org/jira/browse/HARMONY-1816 http://issues.apache.org/jira/browse/HARMONY-1823 https://issues.apache.org/jira/browse/HARMONY-1741 They work fine. The first three patches restore recent classlib tests pass rate degradation. On 10/11/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Excellent. As appreciative as I am of J9, I can't wait to work in all-Harmony code :) geir Elena Semukhina wrote: Hello all, I think that the goal of running classlib unit tests on DRLVM with 100% pass rate could be worth to achieve. Actually today we have 99% (without awt/swing) but still have about 30 failures/errors. Most of them have been evaluated and corresponding JIRAs filed. There is a page on Harmony Wiki which lists those JIRA issues: http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM Are there any volunteers to help with DRLVM bugs fixing? Thanks, Elena - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Elena -- Thanks, Elena
Re: [drlvm][unit tests] the goal is to achieve 100% pass rate
HARMONY-1823 is ready for commit. It will increase classlib pass rate significantly! On 10/17/06, Elena Semukhina [EMAIL PROTECTED] wrote: I added one more issue to http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM . It is http://issues.apache.org/jira/browse/HARMONY-1648. It is drlvm/TM issue and will cause the ThreadGroupTest failure after HARMONY-1625 is applied. Could anyone look at this issue? On 10/17/06, Elena Semukhina [EMAIL PROTECTED] wrote: It seems that the patch for HARMONY-1751http://issues.apache.org/jira/browse/HARMONY-1751 is ready and the patch for HARMONY-1720http://issues.apache.org/jira/browse/HARMONY-1751 is waiting for Alexey Varlamov's evaluation. On 10/13/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Oops, review of HARMONY-1823 should be: The fix is to clean an interrupt flag. Patches are good. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Fedotov, Alexei A Sent: Friday, October 13, 2006 6:12 PM To: [EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org Subject: RE: [drlvm][unit tests] the goal is to achieve 100% pass rate Geir, I reviewed the patches for HARMONY-1816 (non-daemon thread counting is done more accurately) and for HARMONY-1823 - the fix is to clean patches are good. I believe the patches worth to be committed: I've tried the patches for running tests from luni module 162 times and get the following results: $ grep FAILED luni.log | sort | uniq -c 63 [junit] TEST org.apache.harmony.tests.internal.net.www.protocol.http .HttpURLConnectionTest FAILED 162 [junit] TEST tests.api.java.lang.reflect.FieldTest FAILED 6 [junit] TEST tests.api.java.net.InetAddressTest FAILED The following tests were excluded: Index: modules/luni/build.xml === --- modules/luni/build.xml (revision 463342) +++ modules/luni/build.xml (working copy) @@ -325,6 +325,14 @@ exclude name=tests/api/java/net/URLConnectionTest.jav a / exclude name=tests/api/java/net/URLTest.java / exclude name=tests/api/java/net/SocketPermissionTest. java / + +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadGroupTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadLocalTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ClassTest.java / +exclude name=tests/api/java/util/FormatterTest.java / + /fileset /batchtest With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Geir Magnusson Jr. [mailto: [EMAIL PROTECTED] Sent: Friday, October 13, 2006 9:58 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][unit tests] the goal is to achieve 100% pass rate great work - we'll get those applied ASAP. Elena Semukhina wrote: Yesterday I tried the following patches: http://issues.apache.org/jira/browse/HARMONY-1592 http://issues.apache.org/jira/browse/HARMONY-1816 http://issues.apache.org/jira/browse/HARMONY-1823 https://issues.apache.org/jira/browse/HARMONY-1741 They work fine. The first three patches restore recent classlib tests pass rate degradation. On 10/11/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Excellent. As appreciative as I am of J9, I can't wait to work in all-Harmony code :) geir Elena Semukhina wrote: Hello all, I think that the goal of running classlib unit tests on DRLVM with 100% pass rate could be worth to achieve. Actually today we have 99% (without awt/swing) but still have about 30 failures/errors. Most of them have been evaluated and corresponding JIRAs filed. There is a page on Harmony Wiki which lists those JIRA issues: http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM Are there any volunteers to help with DRLVM bugs fixing? Thanks, Elena - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use :
Re: [DRLVM](JIRA-1886)interior pointer for GCv5 of DRLVM
It's strange to me that it is not in the trunk too. So I was wrong. I thought it is already there because it was posted to JIRA many days ago and it was very urgent task. So it is still in JIRA: http://issues.apache.org/jira/browse/HARMONY-1785 On 10/17/06, yunan He [EMAIL PROTECTED] wrote: Mikhail, I can not find the code in SVN and could tell me the revision number? Thanks. Yu-Nan On 10/17/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yu-Nan, Yes, please open new JIRA issue with Jitrino.OPT implementation. On 10/17/06, yunan He [EMAIL PROTECTED] wrote: BTW, did the JET WB4C patch commit to the harmony? AFAIK Jitrino.JET does support WB4C and WB4J today. The code is already in SVN and GCv5 or any other generational GC can be tested with it. -- Mikhail Fursov -- Mikhail Fursov
Re: [classlib][luni][charset]Strange behavior of UnicodeBig
Thank you Andrew,
I think I got the point. The j.l.String of RI uses the encoding of IO
whereas Charset.forName use another of NIO.
And the new problem is shall we follow the spec[1] to support the two
suites of charset implemetation? I just have a look and find we does
not support some Canonical Name for java.io and java.lang API such as
UnicodeBigUnmarked,UnicodeLittleUnmarked,UnicodeBig,Unicodelittle,etc.
[1] http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 10/17/06, Leo Li [EMAIL PROTECTED] wrote:
I think Harmony is more reasonable.
As spec says, if Charset.forName(UnicodeBig) throws
.UnsupportedCharsetException then no support for the named charset is
available in this instance of the Java virtual machine. Then how can we
get
new String(b, UnicodeBig) without throwing UnsupportedCharsetException
on
the same jvm? The spec for String(byte[] bytes,String charsetName) also
says
if the named charset is not supported, UnsupportedCharsetException
should be
thrown out.
UNICODEBIG is a java alias for UTF-16BE. I think we'd better support such
mapping in String and follow RI.
You can find the encoding set from spec. [1]
[1] http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html
On 10/17/06, Tony Wu [EMAIL PROTECTED] wrote:
Hi all,
I found this when I tried to debug the failure tests of ant on
harmony. Note the output of testcases below.
import java.io.UnsupportedEncodingException;
import java.nio.charset.Charset ;
import junit.framework.TestCase;
public class TestCharset extends TestCase {
public void test1() throws UnsupportedEncodingException {
byte[] b = new byte[] { 'a', 'b', 'c' };
String s = new String(b, UnicodeBig);
assertEquals(abc, s);
}
public void test2() {
Charset.forName(UnicodeBig);
}
}
RI:
test1: junit.framework.ComparisonFailure: expected:abc but was:
test2: java.nio.charset.UnsupportedCharsetException: UnicodeBig
Harmony:
test1:java.nio.charset.UnsupportedCharsetException: UnicodeBig
test2:
java.nio.charset.UnsupportedCharsetException: The unsupported charset
name is UnicodeBig
seems RI can recognize the *UnicodeBig* in Constructor of j.l.String,
whereas Harmony does not support this alias at all.
Do you have any concern about that?
--
Tony Wu
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]
--
Leo Li
China Software Development Lab, IBM
--
Best regards,
Andrew Zhang
--
Best regards,
Andrew Zhang
--
Tony Wu
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: [drlvm][kernel] Should we be compatible with RI ThreadGroup bug?
As everyone keeps silence, I'd suggest to change implementation to be bug compatible with RI. On 10/15/06, Elena Semukhina [EMAIL PROTECTED] wrote: On 10/14/06, Tim Ellison [EMAIL PROTECTED] wrote: Elena Semukhina wrote: Classlib test ThreadGroupTest.test_setMaxPriorityI() fails on DRLVM because it expects behaviour that conflicts with specification. The test passes on IBM VME and RI. The issue is reported at https://issues.apache.org/jira/browse/HARMONY-1625 . Actually there is a bug report in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4708197 which agreed that this is a bug in RI and it should be fixed. Should we follow RI's behaviour and change drlvm ThreadGroup.java or should we fix the test? I'm off-line at the moment so cannot look at the bug details. The question is whether fixing the 'bug' will likely break any applications? This question was discussed in Sun's bug report as well. A JCK test detected this bug. The first evaluation stated that This is relatively obscure functionality and it's theoretically possible at that changing the behavior will break running apps. The second evaluation suggested to fix the implementation rather than change the spec. The bug is in progress since 2002... 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] -- Thanks, Elena -- Thanks, Elena
Re: [drlvm] Thread me tender, thread me true, never throw an OOM...
On the 0x205 day of Apache Harmony Geir Magnusson, Jr. wrote:
So, with
public class Test implements Runnable {
static int i = 0;
public void run() {
try {
Thread.sleep(1);
} catch (Throwable e) { e.printStackTrace();
}
}
Test() {
new Thread(this).start();
}
public static void main(String args[]) {
for(;;) {
i++;
if (i % 1000 == 0) {
System.out.println(Iteration: + i);
}
new Test();
}
}
}
How far do you get? I get to 340... and then OOM. Why are threads so
heavy?
4435000 on SUSE9 with:
object_handles.cpp:270: ObjectHandlesNew*
oh_add_new_handles(ObjectHandlesNew**): Assertion `n' failed
Jrockit gave no more than 405000. Even more interesting...
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] why not use a defined constant for max int?
Just my $.02: open/types.h : #define MAX_UINT32 0x looks like a good place to add MAX_INT32 definition. On 10/17/06, Alex Astapchuk [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: stdint.h It's part of C99, not C++. #7.18.2 of C99 states about INTn_MAX: 'C++ implementations should define these macros only when _ _STDC_LIMIT_MACROS is defined before stdint.h is included.' (MSVC does not have such file at all.) For C++, the climits (limits.h) is applicable with INT_MAX or a hand-made constant to address specifically 32 bits. Just my $.02 -- Thanks, Alex Ivan Volosyuk wrote: On 10/17/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: When reviewing HARMONY-1672, there are bits like res.i = (int32)2147483647; (not part of the patch, but surrounding code...) What is the downside for using INT32_MAX or something portable and appropriate? Wouldnt' that make the code more readable? geir It is good to use something like. Is it really portable? I cannot find this define in MSVC. - 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] -- Mikhail Fursov
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
The scenario I described earlier is impossible. Resolution of any class referenced in some other class is performed by class loader, which loaded that other class. So, no chance to load A and referencing class loader (UCL) with this UCL. Sorry for confusion. Regards, Pavel. P.S. Still there are concerns why lazy resolution should be supported by JITs. But it is absolutely another story. On 10/17/06, Mikhail Fursov [EMAIL PROTECTED] wrote: IMO we shall be between BEA and SUN: to work if both RI work, to fail if both RI fail and discuss each test in details if only one RI passes. On 10/17/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Friday 13 October 2006 08:04 Alexey Varlamov wrote: I'm curious, if we enable controlled recursion in classloading - will it resolve this kind of issues completely? I'm pretty sure it would resolve at least some scenarios - like the one Pavel described for gc.Finalizers or a case of classloading initiated within SecurityManager.checkPermission() which we also faced not once. Controlled recursion here means counting depth of recursion and allowing at least 1 recursive iteration. I've seen some tricks in URLClassLoader which assume such ability, but they do not work with DRLVM. I think it is different. URLClassLoader is system class which is loaded by bootstrap, so no recursion happens for classes which it itself requires to be loaded when it is being compiled. For the pure user code scenario Pavel suggested above, there may be some nuances leading to truly endless recursion, but still we need to look at particular test first. It is not endless but it is definitely more than 1 level deep. If user sets up his own class loaders, compiling them may trigger loading some of the user classes which are in turn loaded by class loaders set up by user. Shall we then throw NoClassDefFoundError: Class loading recursion limit reached. Please rewrite your code? :) -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mikhail Fursov
Re: [classlib][luni][charset]Strange behavior of UnicodeBig
On 10/17/06, Tony Wu [EMAIL PROTECTED] wrote:
Thank you Andrew,
I think I got the point. The j.l.String of RI uses the encoding of IO
whereas Charset.forName use another of NIO.
exactly!
And the new problem is shall we follow the spec[1] to support the two
suites of charset implemetation? I just have a look and find we does
not support some Canonical Name for java.io and java.lang API such as
UnicodeBigUnmarked,UnicodeLittleUnmarked,UnicodeBig,Unicodelittle,etc.
I think we have no choice because spec has explictly pointed out the basic
charset name for java.io,java.lang and nio, which includes UnicodeBig. So
the problem left is how, not whether. :-)
Mapping may solve this problem. We may map:
1. io/lang - nio
2. nio - io/lang
3. io/lang/nio - icu
BTW, does current nio.charset implementation support UnicodeBig? There're
a little differences between UnicodeBig and UTF-16 BE:
UnicodeBig: Sixteen-bit Unicode Transformation Format, big-endian byte
order, with byte-order mark
UTF-16 BE: Sixteen-bit Unicode Transformation Format, big-endian byte order
[1] http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 10/17/06, Leo Li [EMAIL PROTECTED] wrote:
I think Harmony is more reasonable.
As spec says, if Charset.forName(UnicodeBig) throws
.UnsupportedCharsetException then no support for the named charset
is
available in this instance of the Java virtual machine. Then how can
we
get
new String(b, UnicodeBig) without throwing
UnsupportedCharsetException
on
the same jvm? The spec for String(byte[] bytes,String charsetName)
also
says
if the named charset is not supported, UnsupportedCharsetException
should be
thrown out.
UNICODEBIG is a java alias for UTF-16BE. I think we'd better support
such
mapping in String and follow RI.
You can find the encoding set from spec. [1]
[1] http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html
On 10/17/06, Tony Wu [EMAIL PROTECTED] wrote:
Hi all,
I found this when I tried to debug the failure tests of ant on
harmony. Note the output of testcases below.
import java.io.UnsupportedEncodingException;
import java.nio.charset.Charset ;
import junit.framework.TestCase;
public class TestCharset extends TestCase {
public void test1() throws UnsupportedEncodingException {
byte[] b = new byte[] { 'a', 'b', 'c' };
String s = new String(b, UnicodeBig);
assertEquals(abc, s);
}
public void test2() {
Charset.forName(UnicodeBig);
}
}
RI:
test1: junit.framework.ComparisonFailure: expected:abc but
was:
test2: java.nio.charset.UnsupportedCharsetException: UnicodeBig
Harmony:
test1:java.nio.charset.UnsupportedCharsetException: UnicodeBig
test2:
java.nio.charset.UnsupportedCharsetException: The unsupported
charset
name is UnicodeBig
seems RI can recognize the *UnicodeBig* in Constructor of
j.l.String,
whereas Harmony does not support this alias at all.
Do you have any concern about that?
--
Tony Wu
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]
--
Leo Li
China Software Development Lab, IBM
--
Best regards,
Andrew Zhang
--
Best regards,
Andrew Zhang
--
Tony Wu
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]
--
Best regards,
Andrew Zhang
Re: [classlib][xnet] Problem connecting using SSLSocketImpl
Hello Gerald! It is glad to hear that You are trying to use Harmony's JSSE provider! I'd like to inquire if there is any intention in the future to support any of the TLS AES type cipher suites? Now only the base Cipher Suites (described by RFC 2246) are supported. But the design of the provider allows easily extending its set of suites. The point for extension is org.apache.harmony.xnet.provider.jsse.CipherSuiteclass. Harmony's Cipher provider (implemented by Bouncy Castle) supports AES Cipher, so it won't be a problem. If you have any other ideas on what may be causing this exception please let me know. I think you are 100% right about the nature of failure, but detailed information (std output, stack trace) can help to analyze it accurately. Could you show it please? You may want to file a new JIRA report and provide this detailed information as an attachment for it. Or if it is more convenient you can attach zipped info here. BTW, there are some logging capabilities in JSSE provider. You can turn them on by specifying -Djsse=record,prf,socket as an option to VM. Log output could be useful in problem analysis. Thank You, Alexander Kleymenov
[doc]too many building instructions?
Folks, I've had a strange impression just now that we have too many building instructions for Harmony sources: [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/build_cla sslib.html Building Class Library only [2] http://incubator.apache.org/harmony/quickhelp_contributors.htm [3] http://incubator.apache.org/harmony/quickhelp_users.html - building instructions for the whole bundle (VM + Classlib), in a short and detailed versions; the detailed version (for contributors) has specifics for building classlib and vm in addition to common steps [4] http://wiki.apache.org/harmony/FrontPage - startup Wiki page that has a link to [1], a placeholder for a future page BuildingHintsForClasslib and VMBuildTroubleshooting. The last two pages seem to have similar intentions - show specifics/typical errors when building code. [5] READMEs for Classlib and for VM, with links to some of the sources above or repetition of these sources. Does this not seem like writing about actually the same thing in many places? My suggestion on improving this would be: 1. Remove [1], migrate unique bits (not repeated elsewhere) to [2] or [3] as fits better. 2. Edit [4] to replace the BuildingInstructions link from [1] to [2], so that instructions for both classlib and vm are retrievable. 3. Place a More Details link at [3] to [2], work to minimize repetition between these. 4. Name BuildingHintsForClasslib and VMBuildTroubleshooting in a similar way to show that they are about the same thing. I am sorry if this all sounds confusing or if I missed/misunderstood some things. Just trying to keep things in a minimal number of places - for easier maintenance and browsing. Cheers, Nadya Morozova
Re: [classlib]Harmony passes 73% on Derby.
Hi Leo, I have had a look at your patch and it looks fine. I have also run the tests once or twice since April when I first did it and I saw a lower pass rate too, so I don't think you've done anything wrong. I did run fewer tests in April as I think I was using a 1.4 target, but even so there are still fewer passes in total (437 in April vs. 428 now) so I think there must have been some changes in Harmony to cause this. Regards, Sian On 17/10/06, Leo Li [EMAIL PROTECTED] wrote: Hi, all: I have ran the tests of Derby on Harmony, both on windows xp and ubuntu. The result is similar. On windows, 579 Tests Run 73% Pass (428 tests passed) 27% Fail (151 tests failed) 9 Suites skipped On linux, 579 Tests Run 74% Pass (430 tests passed) 26% Fail (149 tests failed) 9 Suites skipped The result seems a little frustrating since Sian had 82% passed several months before. The version of derby I ran is at revision 464429. The lost passing rate may be due to the modified code and added testcases. To Sian: I made a new patch in the attachment which is an updated version of the patch Sian provides. I will be appreciate if Sian helps to check its validity and thus I will be assured that the lost passing rate is irrelevant to our modification. When I can confirm everything is all right, I will then put the ongoing progress result on Harmony's wiki page. Thank you. -- Leo Li 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] -- Sian January IBM Java Technology Centre, UK
Re: Hot to Write GC requires improvement
Svetlana,
I've looked through your changes.
Mostly they look okay, and they greatly improve the visual presentation.
Originally, GC-howto was created using AsciiDoc[1] toolchain from the source
text file and source .cpp file. Modifying .html file directly means that we
cannot
update the document to keep it in sync with the source code.
I guess this is acceptable, since nobody is changing source code inlets in
GC-howto now,
but be warned: if anyone is to introduce source changes, it would tedious
task to synchronize visual and content changes.
Have you tried to configure asciidoc to produce the content you want?
I will send you the version of gc-howto.txt and gc.cpp that I have,
but Nadya may have a later version, so please check with her.
Since I am not sure attachment will make it to the list, I'll send it to you
directly. (* or to anyone else who might be interested, just ask *)
[1] http://www.methods.co.nz/asciidoc/
Konovalova, Svetlana wrote:
Sorry about that!
I've created a new patch, hope it's the right one you need. Please let
me know if you still have any problems.
[JIRA 1881] http://issues.apache.org/jira/browse/HARMONY-1881
Cheers,
Sveta Konovalova
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 17, 2006 8:50 AM
To: harmony-dev@incubator.apache.org
Subject: Re: Hot to Write GC requires improvement
The problem with the patch is that it's to the rendered output
site/xdoc/subcomponent/drlvm/gc-howto.html
when what we need is the patch to the source document
site/xdoc/subcomponent/drlvm/gc-howto-content.html
Can you add a new patch with that please?
geir
Rana Dasgupta wrote:
This is a good document, thanks Svetlana. Even if a lot of custom gc's
don't
get written, it helps in understanding the current collecor farmework
and
how it plugs into DRLVM.
Rana
On 10/16/06, Konovalova, Svetlana [EMAIL PROTECTED]
wrote:
Folks,
I took a close look at Hot to Write GC [1] and created a patch
for
this doc [JIRA 1881]. I fixed formatting, brushed up the code,
removed
out-dated tags etc.
It would be great if someone can find a chance to look at the
patch.
Thanks in advance!
[1]
http://incubator.apache.org/harmony/subcomponents/drlvm/gc-howto.html
[JIRA 1881] http://issues.apache.org/jira/browse/HARMONY-1881
Cheers,
Sveta Konovalova
-
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]
/**
* 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.
*/
#include assert.h
#include string.h
#include list
#include algorithm
#include open/gc.h
#include open/vm_gc.h
#include open/vm.h
#define LOG_DOMAIN gc
#include cxxlog.h
typedef unsigned char byte;
//
// non-GC utilities
// Included to get critical sections
#include windows.h
struct Lock {
CRITICAL_SECTION cs;
Lock() { InitializeCriticalSection(cs); }
~Lock() { DeleteCriticalSection(cs); }
void lock() { EnterCriticalSection(cs); }
void unlock() { LeaveCriticalSection(cs); }
};
// convenient converter from sizes in bytes to Megabytes
inline int mb (int i) {
return (i + 1048576/2) / 1048576;
}
//
// GC types
// This structure is allocated for each user thread.
// It contains the thread-local allocation area.
struct TLS {
byte* current; // the allocation pointer
byte* limit;// the end of the allocation area
};
struct InteriorPointer {
struct Object* base;
int offset;
struct Object** interior_ref;
};
// Encapsulates all GC data.
struct GC {
unsigned int semisize; // the size of the semispace
unsigned int chunk_size; // the chunk size for thread-local chunks
byte* space;// the pointer to the heap
Lock lock; // the lock to protect global heap access
byte* fromspace;// the allocation space
byte* current; // the allocation marker
Re: Hot to Write GC requires improvement
Svetlana,
I've looked through your changes.
Mostly they look okay, and they greatly improve the visual presentation.
Originally, GC-howto was created using AsciiDoc[1] toolchain from the source
text file and source .cpp file. Modifying .html file directly means that we
cannot
update the document to keep it in sync with the source code.
I guess this is acceptable, since nobody is changing source code inlets in
GC-howto now,
but be warned: if anyone is to introduce source changes, it would tedious
task to synchronize visual and content changes.
Have you tried to configure asciidoc to produce the content you want?
I will send you the version of gc-howto.txt and gc.cpp that I have,
but Nadya may have a later version, so please check with her.
Since I am not sure attachment will make it to the list, I'll send it to you
directly. (* or to anyone else who might be interested, just ask *)
[1] http://www.methods.co.nz/asciidoc/
Konovalova, Svetlana wrote:
Sorry about that!
I've created a new patch, hope it's the right one you need. Please let
me know if you still have any problems.
[JIRA 1881] http://issues.apache.org/jira/browse/HARMONY-1881
Cheers,
Sveta Konovalova
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 17, 2006 8:50 AM
To: harmony-dev@incubator.apache.org
Subject: Re: Hot to Write GC requires improvement
The problem with the patch is that it's to the rendered output
site/xdoc/subcomponent/drlvm/gc-howto.html
when what we need is the patch to the source document
site/xdoc/subcomponent/drlvm/gc-howto-content.html
Can you add a new patch with that please?
geir
Rana Dasgupta wrote:
This is a good document, thanks Svetlana. Even if a lot of custom gc's
don't
get written, it helps in understanding the current collecor farmework
and
how it plugs into DRLVM.
Rana
On 10/16/06, Konovalova, Svetlana [EMAIL PROTECTED]
wrote:
Folks,
I took a close look at Hot to Write GC [1] and created a patch
for
this doc [JIRA 1881]. I fixed formatting, brushed up the code,
removed
out-dated tags etc.
It would be great if someone can find a chance to look at the
patch.
Thanks in advance!
[1]
http://incubator.apache.org/harmony/subcomponents/drlvm/gc-howto.html
[JIRA 1881] http://issues.apache.org/jira/browse/HARMONY-1881
Cheers,
Sveta Konovalova
-
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]
/**
* 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.
*/
#include assert.h
#include string.h
#include list
#include algorithm
#include open/gc.h
#include open/vm_gc.h
#include open/vm.h
#define LOG_DOMAIN gc
#include cxxlog.h
typedef unsigned char byte;
//
// non-GC utilities
// Included to get critical sections
#include windows.h
struct Lock {
CRITICAL_SECTION cs;
Lock() { InitializeCriticalSection(cs); }
~Lock() { DeleteCriticalSection(cs); }
void lock() { EnterCriticalSection(cs); }
void unlock() { LeaveCriticalSection(cs); }
};
// convenient converter from sizes in bytes to Megabytes
inline int mb (int i) {
return (i + 1048576/2) / 1048576;
}
//
// GC types
// This structure is allocated for each user thread.
// It contains the thread-local allocation area.
struct TLS {
byte* current; // the allocation pointer
byte* limit;// the end of the allocation area
};
struct InteriorPointer {
struct Object* base;
int offset;
struct Object** interior_ref;
};
// Encapsulates all GC data.
struct GC {
unsigned int semisize; // the size of the semispace
unsigned int chunk_size; // the chunk size for thread-local chunks
byte* space;// the pointer to the heap
Lock lock; // the lock to protect global heap access
byte* fromspace;// the allocation space
byte* current; // the allocation marker
Re: [classlib][awt] An awt bug? (was Re: [application] [feedback] VM crashed when running Poleposition on Harmony)
Andrew, patch was applied and verified. Could you check, does it fix problem? 2006/10/16, Andrew Zhang [EMAIL PROTECTED]: On 10/16/06, Denis Kishenko [EMAIL PROTECTED] wrote: This issue has been filed and patched three weeks ago but wasn't applied yet (as many others). Thanks Denis! Look forward to committers. :-) See http://issues.apache.org/jira/browse/HARMONY-1585 2006/10/15, Andrew Zhang [EMAIL PROTECTED]: PolePosition(actually JFreeChat) throws IllegalPathStateException when generating test report.The error message looks like (I added a sysout(shape) in CommonGraphics2D#fill method): java.awt.geom.Rectangle2D$Double[x=0.0,y=0.0,width=750.0,height=500.0] [EMAIL PROTECTED] java.awt.geom.IllegalPathStateException: First segment should be SEG_MOVETO type at java.awt.geom.GeneralPath.checkBuf(GeneralPath.java:24) at java.awt.geom.GeneralPath.closePath(GeneralPath.java:260) at java.awt.geom.GeneralPath.append(GeneralPath.java:296) at java.awt.geom.AffineTransform.createTransformedShape( AffineTransform.java:535) at org.apache.harmony.awt.gl.CommonGraphics2D.fill( CommonGraphics2D.java :723) at org.jfree.chart.StandardLegend.drawLegendBox(StandardLegend.java :875) at org.jfree.chart.StandardLegend.draw(StandardLegend.java:757) at org.jfree.chart.StandardLegend.draw(StandardLegend.java:578) On 10/15/06, Andrew Zhang [EMAIL PROTECTED] wrote: I simplified test scenario in PolePosition. Now it throws unexpected exception when generating test report: java.awt.geom.IllegalPathStateException: First segment should be SEG_MOVETO type at java.awt.geom.GeneralPath.checkBuf(GeneralPath.java:204) at java.awt.geom.GeneralPath.closePath(GeneralPath.java:260) at java.awt.geom.GeneralPath.append(GeneralPath.java:296) at java.awt.geom.AffineTransform.createTransformedShape( AffineTransform.java:535) at org.apache.harmony.awt.gl.CommonGraphics2D.fill( CommonGraphics2D.java:722) at org.jfree.chart.StandardLegend.drawLegendBox(StandardLegend.java :875) at org.jfree.chart.StandardLegend.draw(StandardLegend.java:757) at org.jfree.chart.StandardLegend.draw(StandardLegend.java:578) at org.jfree.chart.JFreeChart.draw(JFreeChart.java:966) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java :1157) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java :1136) at org.jfree.chart.JFreeChart.createBufferedImage (JFreeChart.java :1121) at org.polepos.reporters.HTMLReporter.renderLapGraph( HTMLReporter.java :121) at org.polepos.reporters.HTMLReporter.report(HTMLReporter.java:58) at org.polepos.reporters.GraphReporter.endSeason (GraphReporter.java :13) at org.polepos.framework.Racer.run(Racer.java:114) at org.polepos.framework.Racer.init(Racer.java:44) at org.polepos.RunSeason.main(RunSeason.java:93) On 10/14/06, Andrew Zhang [EMAIL PROTECTED] wrote: PolePosition is a benchmark test suite to compare database engines and object-relational mapping technology. ( http://www.polepos.org/). I tried to run PolePosition on Harmony(lastest build), but unfortunately vm crashed during the execution. The DRLVM crashes at the very early stage, while IBM VME crashes after a while. No error message is printed out from DRLVM, while IBM VME gives following message [1]. Any comments about jclclear_23.dll and the extra info 0012FB7C ? [1] IBM VME error message: Unhandled exception Type=Segmentation error vmState=0x0004 J9Generic_Signal_Number=0004 ExceptionCode=c005 ExceptionAddress=7F96A8EC ContextFlags=0001003f Handler1=7FE50390 Handler2=7FD074F0 InaccessibleAddress=0137D580 EDI=0074BB40 ESI=0081F100 EAX=11761268 EBX=0137D568 ECX=000C EDX=0004 EIP=7F96A8EC ESP=0012F81C EBP=001D5500 Module=D:\Harmony\deploy\jdk\jre\bin\default\jclclear_23.dll Module_base_address=7F95 Offset_in_DLL=0001a8ec Target=2_30_20060727_07300_lHdSMR (Windows XP 5.1 build 2600 Service Pack 2) CPU=x86 (1 logical CPUs) (0x1f77c000 RAM) ... _org.apache.harmony.vmi.portlib (extra info: 0012FB7C) -Xjcl:jclclear_23 _j2se_j9=136448 -- Best regards, Andrew Zhang -- Best regards, Andrew Zhang -- Best regards, Andrew Zhang -- Denis M. Kishenko 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] -- Best regards, Andrew Zhang -- Denis M. Kishenko Enterprise Solutions Software Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
2006/10/17, Alexey Varlamov [EMAIL PROTECTED]: 2006/10/17, Geir Magnusson Jr. [EMAIL PROTECTED]: Rana Dasgupta wrote: On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: So since I don't have Win 2003, I gotta just commit and let someone else test? Any committer have win 2003? I think that it may be hard to find a test at this point that fails on Windows Server 2003, but passes on XP. But perf etc. characteristics will be different. At some point, gc_v5 etc. is likely to have server specific variations, eg., parallel gc may be on server only. Are we talking of tests in general? I am sorry, but I may not have understood the comment. There is a test that demonstrates a Win 2003 bug... I can just commit it and let someone confirm since I don't have a win 2003 machine It would be nice if Gregory confirmed that Win XP and Win 2003 machines which he compared have identical HW - this might be multicore vs single-CPU (HT does not count) specific rather than OS? Gregory? The ones that I have are different. XP is on laptop with a single CPU, the server is on P4 with HT enabled. Actually it wasn't me who discovered the problem on 2003 server, it was Elena who created HARMONY-1669. -- Gregory Shimansky, Intel Middleware Products Division
Re: [classlib][awt] Does Harmony awt support win.xpstyle.dllName desktop property in windows XP?
I'll take a look at this issue.
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 10/17/06, Sergey Soldatov [EMAIL PROTECTED] wrote:
No, it doesn't. Unfortunately most of desktop properties are not described
in j2se documentation. If you feel that we need to support this
property please file JIRA issue and we'll try to fix it ASAP.
Thanks Sergey! A JIRA issue (
http://issues.apache.org/jira/browse/HARMONY-1887) was filed. :-)
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi, does Harmony awt support win.xpstyle.dllName desktop property in
windows XP?
Consider following code:
public static void main(String[] args) {
Toolkit toolkit = Toolkit.getDefaultToolkit();
String xpstyleDll = (String) toolkit
.getDesktopProperty(win.xpstyle.dllName);
System.out.println(xpstyleDll);
}
RI Output:
C:\WINDOWS\resources\Themes\luna\luna.msstyles
Harmony Output:
null
--
Best regards,
Andrew Zhang
--
Sergey Soldatov
Intel Middleware Products Division
--
Best regards,
Andrew Zhang
--
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]
Re: [drlvm][kernel] Should we be compatible with RI ThreadGroup bug?
Joshua Bloch said, thread groups are largely obsolete.,Avoid thread groups! I think it is not necessary to fullly comply with RI here ;-) On 10/17/06, Elena Semukhina [EMAIL PROTECTED] wrote: As everyone keeps silence, I'd suggest to change implementation to be bug compatible with RI. On 10/15/06, Elena Semukhina [EMAIL PROTECTED] wrote: On 10/14/06, Tim Ellison [EMAIL PROTECTED] wrote: Elena Semukhina wrote: Classlib test ThreadGroupTest.test_setMaxPriorityI() fails on DRLVM because it expects behaviour that conflicts with specification. The test passes on IBM VME and RI. The issue is reported at https://issues.apache.org/jira/browse/HARMONY-1625 . Actually there is a bug report in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4708197 which agreed that this is a bug in RI and it should be fixed. Should we follow RI's behaviour and change drlvm ThreadGroup.java or should we fix the test? I'm off-line at the moment so cannot look at the bug details. The question is whether fixing the 'bug' will likely break any applications? This question was discussed in Sun's bug report as well. A JCK test detected this bug. The first evaluation stated that This is relatively obscure functionality and it's theoretically possible at that changing the behavior will break running apps. The second evaluation suggested to fix the implementation rather than change the spec. The bug is in progress since 2002... 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] -- Thanks, Elena -- Thanks, Elena -- Tony Wu 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: Re: Hot to Write GC requires improvement
Folks, Yes, I do have a newer version of the source file that produced the GC-howto document currently on the site - see attached. I am not sure we actually need to sync up with the original Asciidoc-input file. Will send a separate email with my thoughts soon. Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Salikh Zakirov Sent: Tuesday, October 17, 2006 1:29 PM To: harmony-dev@incubator.apache.org Subject: Re: Hot to Write GC requires improvement Svetlana, I've looked through your changes. Mostly they look okay, and they greatly improve the visual presentation. Originally, GC-howto was created using AsciiDoc[1] toolchain from the source text file and source .cpp file. Modifying .html file directly means that we cannot update the document to keep it in sync with the source code. I guess this is acceptable, since nobody is changing source code inlets in GC-howto now, but be warned: if anyone is to introduce source changes, it would tedious task to synchronize visual and content changes. Have you tried to configure asciidoc to produce the content you want? I will send you the version of gc-howto.txt and gc.cpp that I have, but Nadya may have a later version, so please check with her. Since I am not sure attachment will make it to the list, I'll send it to you directly. (* or to anyone else who might be interested, just ask *) [1] http://www.methods.co.nz/asciidoc/ Konovalova, Svetlana wrote: Sorry about that! I've created a new patch, hope it's the right one you need. Please let me know if you still have any problems. [JIRA 1881] http://issues.apache.org/jira/browse/HARMONY-1881 Cheers, Sveta Konovalova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 8:50 AM To: harmony-dev@incubator.apache.org Subject: Re: Hot to Write GC requires improvement The problem with the patch is that it's to the rendered output site/xdoc/subcomponent/drlvm/gc-howto.html when what we need is the patch to the source document site/xdoc/subcomponent/drlvm/gc-howto-content.html Can you add a new patch with that please? geir Rana Dasgupta wrote: This is a good document, thanks Svetlana. Even if a lot of custom gc's don't get written, it helps in understanding the current collecor farmework and how it plugs into DRLVM. Rana On 10/16/06, Konovalova, Svetlana [EMAIL PROTECTED] wrote: Folks, I took a close look at Hot to Write GC [1] and created a patch for this doc [JIRA 1881]. I fixed formatting, brushed up the code, removed out-dated tags etc. It would be great if someone can find a chance to look at the patch. Thanks in advance! [1] http://incubator.apache.org/harmony/subcomponents/drlvm/gc-howto.html [JIRA 1881] http://issues.apache.org/jira/browse/HARMONY-1881 Cheers, Sveta Konovalova - 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] How to write DRL GC === [EMAIL PROTECTED], [EMAIL PROTECTED] revision 1.0 // // Copyright 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. // // // Generate HTML version of this document from text source // and configuration file GC-howto.conf using the command // // asciidoc -f GC-howto.conf --unsafe GC-howto.txt // // Download Asciidoc generic distribution archive from // // http://www.methods.co.nz/asciidoc/downloads.html // // unpack it somewhere (e.g. /usr/local/opt/asciidoc), and // symlink /usr/local/opt/asciidoc/asciidoc.py to /usr/local/bin/asciidoc // This section provides instructions on creating a custom garbage collector implementation in C++ and configuring the DRL virtual machine to use it. The section describes the major steps of this procedure, namely: - Establishing the build infrastructure - Implementing the GC interface - Implementing the garbage collector algorithm - Running the VM with the custom GC .Note Plugging-in a user-designed garbage
Re: [drlvm][kernel] Should we be compatible with RI ThreadGroup bug?
BTW, bug evaluation suggests that implementation may be fixed at beginning of the Java SE 7 cycle - one more argument to follow spec. So I vote for applying the H-1625 patch, all the more it fixes several other issues in the test. 2006/10/17, Tony Wu [EMAIL PROTECTED]: Joshua Bloch said, thread groups are largely obsolete.,Avoid thread groups! I think it is not necessary to fullly comply with RI here ;-) On 10/17/06, Elena Semukhina [EMAIL PROTECTED] wrote: As everyone keeps silence, I'd suggest to change implementation to be bug compatible with RI. On 10/15/06, Elena Semukhina [EMAIL PROTECTED] wrote: On 10/14/06, Tim Ellison [EMAIL PROTECTED] wrote: Elena Semukhina wrote: Classlib test ThreadGroupTest.test_setMaxPriorityI() fails on DRLVM because it expects behaviour that conflicts with specification. The test passes on IBM VME and RI. The issue is reported at https://issues.apache.org/jira/browse/HARMONY-1625 . Actually there is a bug report in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4708197 which agreed that this is a bug in RI and it should be fixed. Should we follow RI's behaviour and change drlvm ThreadGroup.java or should we fix the test? I'm off-line at the moment so cannot look at the bug details. The question is whether fixing the 'bug' will likely break any applications? This question was discussed in Sun's bug report as well. A JCK test detected this bug. The first evaluation stated that This is relatively obscure functionality and it's theoretically possible at that changing the behavior will break running apps. The second evaluation suggested to fix the implementation rather than change the spec. The bug is in progress since 2002... 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] -- Thanks, Elena -- Thanks, Elena -- Tony Wu 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription
Richard, I've filed JIRA issue [1] for this problem. To my mind, we should just remove these locale dependent assertions. On the other hand there will be only a few tests left after then. Any other suggestions? Regards, Alexey. P.S. See also related issue [2]: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A:. [1] https://issues.apache.org/jira/browse/HARMONY-1893 [2] https://issues.apache.org/jira/browse/HARMONY-1892 -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 12:06 PM To: harmony-dev@incubator.apache.org Subject: [classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription Hello, The test fails on Windows XP when the locale-setting is zh_CN. It's because that view.getSystemTypeDescription(file) returns Chinese words 文件 instead of File. Could any one help to verify this issue? Thanks a lot. -- Richard Liang China 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] - 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] [testing] Excluding commit tests until the problem is fixed
On 10/17/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: We have mighty guys on this list. Why cannot we just fix these tests instead of excluding them? I suggest starting with basic threading issues such as org.apache.harmony.luni.tests.java.lang.ThreadTest, org.apache.harmony.luni.tests.java.lang.ThreadGroupTest - they reliably fail in my environment. I volunteer for checking reliability of fixes. The ThreadTest fails stabily due to HARMONY-1789 and intermittently due to HARMONY-1876 (the test's problem). I've never seen the ThreadGroupTest failure. Gregory asked why this test fails on RI too. It looks like the RI implementation of Thread.destroy() and ThreadInterrupt() for new, terminated and current thread contradicts the spec. RI failures on getState() look unexpected. I'll look at the test. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 12:01 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] [testing] Excluding commit tests until the problem is fixed Gregory Shimansky wrote: Hello After reading several threads about drlvm tests failing for quite a while I decided we need to exclude them temporarily until the bugs are fixed. When on test fails, it means that other are not run after it because drlvm has several sets of tests which run in different modes, so there are many test runs in one build test command. When some test doesn't work for quite some time it means that other may not be ran for this period and we can get more failures accidently. That's actually not true. I never commit unless all tests (minus some kernel tests) run. The Finalizer and PhanRefQueueTest are flakey - I always repeat until the passed, so the rest could run. I'm just sick of it, so i did the magic @keyword attribute and committed. Excluding tests is not good, but not running some basic commit checks is worse, so I think we need to disable them until the bugs are fixed. So far I know about 3 tests which fail for sure: gc.LOS - stably hangs on windows XP gc.Finalizer and gc.PhantomReferenceQueue - fail because of incorrect CCE condition detected, fail with rate less than 100%. Ok I've just read that Geir has excluded them already Are there any other tests which don't work perfectly to do a clean tests run? I think we need it do make minimal commit checks for drlvm. I've seen java.lang.ThreadTest in kernel tests to output something that it has failed on reference JRE. Is this test correct if it doesn't work on RI? The failure however doesn't seem to make test run to fail so maybe we could leave this test for now. I also have a question about 15 smoke tests excluded with XXX or X_int keywords. They've been disabled since I remember. Is there any reason why they aren't included in test runs? I tried to put some back. StackTest still doesn't work. It's hard to believe... so I gave up and just kept going :) 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] -- Thanks, Elena
[classlib][swing] test hangs: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A:
Hello everyone, When running tests on Windows, FileSystemViewTest.testGetSystemDisplayName() pops up a dialog prompting to insert disk into drive A:. This dialog prevents normal running of other tests. IMO, the problem assertion could be deleted without loss of coverage. Any other comments/opinions? See the JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1892 Regards, Alexey. P.S. The problem code is at lines 85-86 in FileSystemViewTest.java: file = File.listRoots()[0]; assertNotSame(file.getName(), view.getSystemDisplayName(file)); -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][awt] An awt bug? (was Re: [application] [feedback] VM crashed when running Poleposition on Harmony)
It's ok, since we're using platform depended fonts and they are different from RI. On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote: On 10/17/06, Denis Kishenko [EMAIL PROTECTED] wrote: Andrew, patch was applied and verified. Could you check, does it fix problem? Thanks Denis! It works! The generated report looks fine, though has a little problem about text position. The text, which contains lots of spaces, is created with new Font(SansSerif, Font.PLAIN, 10); It seems the distance of spaces is a little longer than RI. :) 2006/10/16, Andrew Zhang [EMAIL PROTECTED]: On 10/16/06, Denis Kishenko [EMAIL PROTECTED] wrote: This issue has been filed and patched three weeks ago but wasn't applied yet (as many others). Thanks Denis! Look forward to committers. :-) See http://issues.apache.org/jira/browse/HARMONY-1585 2006/10/15, Andrew Zhang [EMAIL PROTECTED]: PolePosition(actually JFreeChat) throws IllegalPathStateException when generating test report.The error message looks like (I added a sysout(shape) in CommonGraphics2D#fill method): java.awt.geom.Rectangle2D$Double[x=0.0,y=0.0,width=750.0,height= 500.0] [EMAIL PROTECTED] java.awt.geom.IllegalPathStateException: First segment should be SEG_MOVETO type at java.awt.geom.GeneralPath.checkBuf(GeneralPath.java:24) at java.awt.geom.GeneralPath.closePath(GeneralPath.java:260) at java.awt.geom.GeneralPath.append(GeneralPath.java:296) at java.awt.geom.AffineTransform.createTransformedShape( AffineTransform.java:535) at org.apache.harmony.awt.gl.CommonGraphics2D.fill( CommonGraphics2D.java :723) at org.jfree.chart.StandardLegend.drawLegendBox( StandardLegend.java :875) at org.jfree.chart.StandardLegend.draw(StandardLegend.java:757) at org.jfree.chart.StandardLegend.draw(StandardLegend.java:578) On 10/15/06, Andrew Zhang [EMAIL PROTECTED] wrote: I simplified test scenario in PolePosition. Now it throws unexpected exception when generating test report: java.awt.geom.IllegalPathStateException: First segment should be SEG_MOVETO type at java.awt.geom.GeneralPath.checkBuf(GeneralPath.java:204) at java.awt.geom.GeneralPath.closePath(GeneralPath.java:260) at java.awt.geom.GeneralPath.append(GeneralPath.java:296) at java.awt.geom.AffineTransform.createTransformedShape( AffineTransform.java:535) at org.apache.harmony.awt.gl.CommonGraphics2D.fill( CommonGraphics2D.java:722) at org.jfree.chart.StandardLegend.drawLegendBox( StandardLegend.java :875) at org.jfree.chart.StandardLegend.draw(StandardLegend.java:757) at org.jfree.chart.StandardLegend.draw(StandardLegend.java:578) at org.jfree.chart.JFreeChart.draw(JFreeChart.java:966) at org.jfree.chart.JFreeChart.createBufferedImage( JFreeChart.java :1157) at org.jfree.chart.JFreeChart.createBufferedImage( JFreeChart.java :1136) at org.jfree.chart.JFreeChart.createBufferedImage ( JFreeChart.java :1121) at org.polepos.reporters.HTMLReporter.renderLapGraph( HTMLReporter.java :121) at org.polepos.reporters.HTMLReporter.report(HTMLReporter.java :58) at org.polepos.reporters.GraphReporter.endSeason ( GraphReporter.java :13) at org.polepos.framework.Racer.run(Racer.java:114) at org.polepos.framework.Racer.init(Racer.java:44) at org.polepos.RunSeason.main(RunSeason.java:93) On 10/14/06, Andrew Zhang [EMAIL PROTECTED] wrote: PolePosition is a benchmark test suite to compare database engines and object-relational mapping technology. ( http://www.polepos.org/). I tried to run PolePosition on Harmony(lastest build), but unfortunately vm crashed during the execution. The DRLVM crashes at the very early stage, while IBM VME crashes after a while. No error message is printed out from DRLVM, while IBM VME gives following message [1]. Any comments about jclclear_23.dll and the extra info 0012FB7C ? [1] IBM VME error message: Unhandled exception Type=Segmentation error vmState=0x0004 J9Generic_Signal_Number=0004 ExceptionCode=c005 ExceptionAddress=7F96A8EC ContextFlags=0001003f Handler1=7FE50390 Handler2=7FD074F0 InaccessibleAddress=0137D580 EDI=0074BB40 ESI=0081F100 EAX=11761268 EBX=0137D568 ECX=000C EDX=0004 EIP=7F96A8EC ESP=0012F81C EBP=001D5500 Module=D:\Harmony\deploy\jdk\jre\bin\default\jclclear_23.dll Module_base_address=7F95 Offset_in_DLL=0001a8ec Target=2_30_20060727_07300_lHdSMR (Windows XP 5.1 build 2600 Service Pack 2) CPU=x86 (1 logical CPUs) (0x1f77c000 RAM) ... _org.apache.harmony.vmi.portlib (extra info: 0012FB7C) -Xjcl:jclclear_23 _j2se_j9=136448 -- Best
FW: [doc]too many building instructions?
Sorry for confusion, my mailer broke some of the links. Resending: [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/build_cla sslib.html [2] http://incubator.apache.org/harmony/quickhelp_contributors.html [3] and [4] seem to work normally. Thank you, Nadya Morozova -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 1:26 PM To: harmony-dev@incubator.apache.org Subject: [doc]too many building instructions? Folks, I've had a strange impression just now that we have too many building instructions for Harmony sources: [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/build_cla sslib.html Building Class Library only [2] http://incubator.apache.org/harmony/quickhelp_contributors.htm [3] http://incubator.apache.org/harmony/quickhelp_users.html - building instructions for the whole bundle (VM + Classlib), in a short and detailed versions; the detailed version (for contributors) has specifics for building classlib and vm in addition to common steps [4] http://wiki.apache.org/harmony/FrontPage - startup Wiki page that has a link to [1], a placeholder for a future page BuildingHintsForClasslib and VMBuildTroubleshooting. The last two pages seem to have similar intentions - show specifics/typical errors when building code. [5] READMEs for Classlib and for VM, with links to some of the sources above or repetition of these sources. Does this not seem like writing about actually the same thing in many places? My suggestion on improving this would be: 1. Remove [1], migrate unique bits (not repeated elsewhere) to [2] or [3] as fits better. 2. Edit [4] to replace the BuildingInstructions link from [1] to [2], so that instructions for both classlib and vm are retrievable. 3. Place a More Details link at [3] to [2], work to minimize repetition between these. 4. Name BuildingHintsForClasslib and VMBuildTroubleshooting in a similar way to show that they are about the same thing. I am sorry if this all sounds confusing or if I missed/misunderstood some things. Just trying to keep things in a minimal number of places - for easier maintenance and browsing. Cheers, Nadya Morozova - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: Hot to Write GC requires improvement
Salikh, About your concern for updating resulting HTML and not the source TXT for Asciidoc-generated documents: I agree that technically Sveta's approach is not professional :) However, for the How to Write a GC document, I do not think that the issue is big enough because the doc seems quite stable, no frequent changes are intended. We only have a couple of code snippets in the doc so the dependency on the reference source code is not big. Generally, Asciidoc might be a nice tool, it's just that we don't use it well:) The current chain that we use with it is TXT + CONFIG XHTML XHTML with manual edits to fit to site settings/presentation XML output HTML for website. Now, this is LONG :) If we manage to have AsciiDoc produce XML that is valid for site purposes = that would be great. It would reduce the whole chain to TXT + CONFIG XML HTML for website! I do not know AsciiDoc internals that well now to say whether that's possible. Here are a couple of my personal considerations about using the tool for Harmony docs: Strong points: * Asciidoc enables using code chunks by references the source file, not copy=and=paste from code. * Asciidoc is a freeware common tool, why not use it? * Asciidoc gets TXT as input, so patching is very easy. Weak points: * We have two technologies for writing for website now: XML directly and HTML with docinclude to add to XML. Adding a new one can be another option (good!) or another confusion (bad!). is the effort worth the goal? * Asciidoc formatting is unique, resembles Wiki formatting but is actually different - confused me when I was starting with it. * Asciidoc references into the source code (to get the code snippet directly from the file) rely on a specific line in code - see the GC-howto.txt we've been discussing. For example, the comment before the function to include the function body into the doc. Now, if you update the code, you'll probably update the comment as well - the reference gets broken. This does not seem much better than manually copying the code into the doc. Don't know how to overcome this. Your comments are most welcome :) Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Salikh Zakirov Sent: Tuesday, October 17, 2006 1:29 PM To: harmony-dev@incubator.apache.org Subject: Re: Hot to Write GC requires improvement Svetlana, I've looked through your changes. Mostly they look okay, and they greatly improve the visual presentation. Originally, GC-howto was created using AsciiDoc[1] toolchain from the source text file and source .cpp file. Modifying .html file directly means that we cannot update the document to keep it in sync with the source code. I guess this is acceptable, since nobody is changing source code inlets in GC-howto now, but be warned: if anyone is to introduce source changes, it would tedious task to synchronize visual and content changes. Have you tried to configure asciidoc to produce the content you want? I will send you the version of gc-howto.txt and gc.cpp that I have, but Nadya may have a later version, so please check with her. Since I am not sure attachment will make it to the list, I'll send it to you directly. (* or to anyone else who might be interested, just ask *) [1] http://www.methods.co.nz/asciidoc/ Konovalova, Svetlana wrote: Sorry about that! I've created a new patch, hope it's the right one you need. Please let me know if you still have any problems. [JIRA 1881] http://issues.apache.org/jira/browse/HARMONY-1881 Cheers, Sveta Konovalova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 8:50 AM To: harmony-dev@incubator.apache.org Subject: Re: Hot to Write GC requires improvement The problem with the patch is that it's to the rendered output site/xdoc/subcomponent/drlvm/gc-howto.html when what we need is the patch to the source document site/xdoc/subcomponent/drlvm/gc-howto-content.html Can you add a new patch with that please? geir Rana Dasgupta wrote: This is a good document, thanks Svetlana. Even if a lot of custom gc's don't get written, it helps in understanding the current collecor farmework and how it plugs into DRLVM. Rana On 10/16/06, Konovalova, Svetlana [EMAIL PROTECTED] wrote: Folks, I took a close look at Hot to Write GC [1] and created a patch for this doc [JIRA 1881]. I fixed formatting, brushed up the code, removed out-dated tags etc. It would be great if someone can find a chance to look at the patch. Thanks in advance! [1] http://incubator.apache.org/harmony/subcomponents/drlvm/gc-howto.html [JIRA 1881] http://issues.apache.org/jira/browse/HARMONY-1881 Cheers, Sveta Konovalova - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Congratulations! I believe in us. :) Regards, 2006/10/17, Geir Magnusson Jr [EMAIL PROTECTED]: Please join the Apache Harmony PPMC in welcoming the project's newest committers, in alphabetical order : Oliver Deakin Richard Liang Alexey Petrenko Gregory Shimansky Alexey Varlamov Alexei Zakharov These six individuals have shown sustained dedication to the project, an ability to work well with others, and share the common vision we have for Harmony. We all continue to expect great things from them. Gentlemen, you don't have accounts yet. When you finally receive your new committer account information, as a first step to test your almighty powers of committitude, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine 3) Add a public key to .ssh so you can stop using the password 4) Set your SVN password : just type 'svnpasswd' At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, anything checked out of SVN, be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Thank you all for support and warmhearted words! -- Regards, Alexey 2006/10/17, Alexei Zakharov [EMAIL PROTECTED]: Congratulations! I believe in us. :) Regards, 2006/10/17, Geir Magnusson Jr [EMAIL PROTECTED]: Please join the Apache Harmony PPMC in welcoming the project's newest committers, in alphabetical order : Oliver Deakin Richard Liang Alexey Petrenko Gregory Shimansky Alexey Varlamov Alexei Zakharov These six individuals have shown sustained dedication to the project, an ability to work well with others, and share the common vision we have for Harmony. We all continue to expect great things from them. Gentlemen, you don't have accounts yet. When you finally receive your new committer account information, as a first step to test your almighty powers of committitude, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine 3) Add a public key to .ssh so you can stop using the password 4) Set your SVN password : just type 'svnpasswd' At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, anything checked out of SVN, be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - 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] An awt bug? (was Re: [application] [feedback] VM crashed when running Poleposition on Harmony)
The generated report looks fine, though has a little problem about text position. So how are we scored? - 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] An awt bug? (was Re: [application] [feedback] VM crashed when running Poleposition on Harmony)
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote: On 10/17/06, Denis Kishenko [EMAIL PROTECTED] wrote: Andrew, patch was applied and verified. Could you check, does it fix problem? Thanks Denis! It works! The generated report looks fine, though has a little problem about text position. The text, which contains lots of spaces, is created with new Font(SansSerif, Font.PLAIN, 10); It seems the distance of spaces is a little longer than RI. :) Hello, Andrew! It's great that you are testing gui in Harmony!! Now question concerning fonts: if you mean that Harmony's SansSerif font in the application looks different than RI's one and space's width is not the same, I can explain. RI uses it's own physical fonts if you use logical name (e.g. SansSerif, Dialog, etc) You can find them in the 'jre/lib/fonts', they are redistributed with jdk1.5.0 package. In Harmony logical font is created according to the font.properties file and if it is missed - default font created instead. Spaces widths should be the same (or almost the same +/- 1 pixel) if you choose physical font installed on your OS instead of logical font, you just have to use create Font using family name (e.g. Arial). If results differs again than it is possibly a bug. Regards, Ilya. 2006/10/16, Andrew Zhang [EMAIL PROTECTED]: On 10/16/06, Denis Kishenko [EMAIL PROTECTED] wrote: This issue has been filed and patched three weeks ago but wasn't applied yet (as many others). Thanks Denis! Look forward to committers. :-) See http://issues.apache.org/jira/browse/HARMONY-1585 2006/10/15, Andrew Zhang [EMAIL PROTECTED]: PolePosition(actually JFreeChat) throws IllegalPathStateException when generating test report.The error message looks like (I added a sysout(shape) in CommonGraphics2D#fill method): java.awt.geom.Rectangle2D$Double[x=0.0,y=0.0,width=750.0,height= 500.0] [EMAIL PROTECTED] java.awt.geom.IllegalPathStateException: First segment should be SEG_MOVETO type at java.awt.geom.GeneralPath.checkBuf(GeneralPath.java:24) at java.awt.geom.GeneralPath.closePath(GeneralPath.java:260) at java.awt.geom.GeneralPath.append(GeneralPath.java:296) at java.awt.geom.AffineTransform.createTransformedShape( AffineTransform.java:535) at org.apache.harmony.awt.gl.CommonGraphics2D.fill( CommonGraphics2D.java :723) at org.jfree.chart.StandardLegend.drawLegendBox( StandardLegend.java :875) at org.jfree.chart.StandardLegend.draw(StandardLegend.java:757) at org.jfree.chart.StandardLegend.draw(StandardLegend.java:578) On 10/15/06, Andrew Zhang [EMAIL PROTECTED] wrote: I simplified test scenario in PolePosition. Now it throws unexpected exception when generating test report: java.awt.geom.IllegalPathStateException: First segment should be SEG_MOVETO type at java.awt.geom.GeneralPath.checkBuf(GeneralPath.java:204) at java.awt.geom.GeneralPath.closePath(GeneralPath.java:260) at java.awt.geom.GeneralPath.append(GeneralPath.java:296) at java.awt.geom.AffineTransform.createTransformedShape( AffineTransform.java:535) at org.apache.harmony.awt.gl.CommonGraphics2D.fill( CommonGraphics2D.java:722) at org.jfree.chart.StandardLegend.drawLegendBox( StandardLegend.java :875) at org.jfree.chart.StandardLegend.draw(StandardLegend.java:757) at org.jfree.chart.StandardLegend.draw(StandardLegend.java:578) at org.jfree.chart.JFreeChart.draw(JFreeChart.java:966) at org.jfree.chart.JFreeChart.createBufferedImage( JFreeChart.java :1157) at org.jfree.chart.JFreeChart.createBufferedImage( JFreeChart.java :1136) at org.jfree.chart.JFreeChart.createBufferedImage ( JFreeChart.java :1121) at org.polepos.reporters.HTMLReporter.renderLapGraph( HTMLReporter.java :121) at org.polepos.reporters.HTMLReporter.report(HTMLReporter.java :58) at org.polepos.reporters.GraphReporter.endSeason ( GraphReporter.java :13) at org.polepos.framework.Racer.run(Racer.java:114) at org.polepos.framework.Racer.init(Racer.java:44) at org.polepos.RunSeason.main(RunSeason.java:93) On 10/14/06, Andrew Zhang [EMAIL PROTECTED] wrote: PolePosition is a benchmark test suite to compare database engines and object-relational mapping technology. ( http://www.polepos.org/). I tried to run PolePosition on Harmony(lastest build), but unfortunately vm crashed during the execution. The DRLVM crashes at the very early stage, while IBM VME crashes after a while. No error message is printed out from DRLVM, while IBM VME gives following message [1]. Any comments about jclclear_23.dll and the extra info 0012FB7C ? [1] IBM VME error message: Unhandled exception Type=Segmentation error vmState=0x0004
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
My 2003 server is installed on a single core P4 with HT. The test attached to HARMONY-1669 works fine for me both with and without patch :) I may get an access to dual core server as described in JIRA but I am afraid it will take a few days. Probably we can just apply the patch since it doesn't seem to do any harm. 2006/10/17, Geir Magnusson Jr. [EMAIL PROTECTED]: Rana Dasgupta wrote: On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: So since I don't have Win 2003, I gotta just commit and let someone else test? Any committer have win 2003? I think that it may be hard to find a test at this point that fails on Windows Server 2003, but passes on XP. But perf etc. characteristics will be different. At some point, gc_v5 etc. is likely to have server specific variations, eg., parallel gc may be on server only. Are we talking of tests in general? I am sorry, but I may not have understood the comment. There is a test that demonstrates a Win 2003 bug... I can just commit it and let someone confirm since I don't have a win 2003 machine geir -- Gregory Shimansky, Intel Middleware Products Division
Re: [classlib][awt] Does Harmony awt support win.xpstyle.dllName desktop property in windows XP?
Andrew, which version of RI do you have? On my JRockit 1.5.0(Windows
XP) output of your test is null...
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 10/17/06, Sergey Soldatov [EMAIL PROTECTED] wrote:
No, it doesn't. Unfortunately most of desktop properties are not described
in j2se documentation. If you feel that we need to support this
property please file JIRA issue and we'll try to fix it ASAP.
Thanks Sergey! A JIRA issue (
http://issues.apache.org/jira/browse/HARMONY-1887) was filed. :-)
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi, does Harmony awt support win.xpstyle.dllName desktop property in
windows XP?
Consider following code:
public static void main(String[] args) {
Toolkit toolkit = Toolkit.getDefaultToolkit();
String xpstyleDll = (String) toolkit
.getDesktopProperty(win.xpstyle.dllName);
System.out.println(xpstyleDll);
}
RI Output:
C:\WINDOWS\resources\Themes\luna\luna.msstyles
Harmony Output:
null
--
Best regards,
Andrew Zhang
--
Sergey Soldatov
Intel Middleware Products Division
--
Best regards,
Andrew Zhang
--
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]
[classlib] logging (was: Re: [classlib][xnet] Problem connecting using SSLSocketImpl)
2006/10/17, Alexander Kleymenov [EMAIL PROTECTED]: Hello Gerald! It is glad to hear that You are trying to use Harmony's JSSE provider! I'd like to inquire if there is any intention in the future to support any of the TLS AES type cipher suites? Now only the base Cipher Suites (described by RFC 2246) are supported. But the design of the provider allows easily extending its set of suites. The point for extension is org.apache.harmony.xnet.provider.jsse.CipherSuiteclass. Harmony's Cipher provider (implemented by Bouncy Castle) supports AES Cipher, so it won't be a problem. If you have any other ideas on what may be causing this exception please let me know. I think you are 100% right about the nature of failure, but detailed information (std output, stack trace) can help to analyze it accurately. Could you show it please? You may want to file a new JIRA report and provide this detailed information as an attachment for it. Or if it is more convenient you can attach zipped info here. Hi Tim BTW, there are some logging capabilities in JSSE provider. You can turn them on by specifying -Djsse=record,prf,socket as an option to VM. Log output could be useful in problem analysis. You asked why we need logging. Now we have an example. Thanks, Mikhail Thank You, Alexander Kleymenov - 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] Does Harmony awt support win.xpstyle.dllName desktop property in windows XP?
Sorry, RI version doesn't matter, I just had Windows XP themes turned off :)
On 10/17/06, Dmitry Durnev [EMAIL PROTECTED] wrote:
Andrew, which version of RI do you have? On my JRockit 1.5.0(Windows
XP) output of your test is null...
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 10/17/06, Sergey Soldatov [EMAIL PROTECTED] wrote:
No, it doesn't. Unfortunately most of desktop properties are not described
in j2se documentation. If you feel that we need to support this
property please file JIRA issue and we'll try to fix it ASAP.
Thanks Sergey! A JIRA issue (
http://issues.apache.org/jira/browse/HARMONY-1887) was filed. :-)
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi, does Harmony awt support win.xpstyle.dllName desktop property in
windows XP?
Consider following code:
public static void main(String[] args) {
Toolkit toolkit = Toolkit.getDefaultToolkit();
String xpstyleDll = (String) toolkit
.getDesktopProperty(win.xpstyle.dllName);
System.out.println(xpstyleDll);
}
RI Output:
C:\WINDOWS\resources\Themes\luna\luna.msstyles
Harmony Output:
null
--
Best regards,
Andrew Zhang
--
Sergey Soldatov
Intel Middleware Products Division
--
Best regards,
Andrew Zhang
--
Dmitry A. Durnev,
Intel Middleware Products Division
--
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]
Re: [general] graduate from incubator to be a Top Level Project of the ASF
+1. I'm for it. Regards, Tim Geir Magnusson Jr wrote: The Harmony PPMC has been discussing and has approved asking to graduate from the Apache Incubator and become a Top Level Project. This means that we would become an official project of the Apache Software Foundation. In terms of our day-to-day life, nothing should change. We'd get a new URL for the project (http://harmony.apache.org) and our mail lists would change to whatever@harmony.apache.org. There also may be contributors out there that are more comfortable contributing to a top-level project rather than one in the Incubator, but given how solid this project is (IMO), I don't see how that matters. I mean, if it was good enough for all of us to participate in, and for Intel, IBM, ITC to make contributions to :) Anyway, unless there is opposition from the community, we'll start moving forward with this. Any comments, for or against? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Well done everyone -- keep up the good work! Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committers, in alphabetical order : Oliver Deakin Richard Liang Alexey Petrenko Gregory Shimansky Alexey Varlamov Alexei Zakharov These six individuals have shown sustained dedication to the project, an ability to work well with others, and share the common vision we have for Harmony. We all continue to expect great things from them. Gentlemen, you don't have accounts yet. When you finally receive your new committer account information, as a first step to test your almighty powers of committitude, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine 3) Add a public key to .ssh so you can stop using the password 4) Set your SVN password : just type 'svnpasswd' At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, anything checked out of SVN, be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
[classlib] javax.activity package. where to go?
There is javax.activity package that has 3 exception classes and nothing else. I doubt we need a dedicated module for them. I think they should go to RMI module. If no objections, I'll implement them there. This red line in Japi reports makes me unhappy. Thanks, Mikhail - 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] graduate from incubator to be a Top Level Project of the ASF
+1 Wonderful! On 10/17/06, Tim Ellison [EMAIL PROTECTED] wrote: +1. I'm for it. Regards, Tim Geir Magnusson Jr wrote: The Harmony PPMC has been discussing and has approved asking to graduate from the Apache Incubator and become a Top Level Project. This means that we would become an official project of the Apache Software Foundation. In terms of our day-to-day life, nothing should change. We'd get a new URL for the project (http://harmony.apache.org) and our mail lists would change to whatever@harmony.apache.org. There also may be contributors out there that are more comfortable contributing to a top-level project rather than one in the Incubator, but given how solid this project is (IMO), I don't see how that matters. I mean, if it was good enough for all of us to participate in, and for Intel, IBM, ITC to make contributions to :) Anyway, unless there is opposition from the community, we'll start moving forward with this. Any comments, for or against? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] -- Weldon Washburn Intel Middleware Products Division
Re: [classlib][luni]Runtime.exec fails on Linux
What? That error is related to not being able to find a built classlib.
One easy way, if you are using /enhanced/trunk as per the directions in
the getting started section of the website, is to rename the example
drlvm.properties.example in working_vm/build and use that.
geir
Leo Li wrote:
Hi, Alexey:
Thank you.
I have started to build the system.
Besides, I think the problem is not related to classlib. Since I have
let fork called in a native function, but it fails on J9.
On 10/17/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
This is due to incorrect classlib location specified. Please ensure
you provide correct (better absolute) path in build\drlvm.properties
(if you use it) or external.dep.CLASSLIB.loc property value in
cmdline:
sh build.sh -Dexternal.dep.CLASSLIB.loc=$classlib
This should point to the root of (pre-)built classlib WS.
2006/10/17, Leo Li [EMAIL PROTECTED]:
Hi, all:
I tried to build drlvm on linux, but when build update, it reports
such
error:
[echo] downloading XALAN from no_settings_in_config_or_environment
[echo] no_settings_in_config_or_environment
BUILD FAILED
/root/workspaces/workspace/drlvm/build/make/build.xml:240: The
following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:273: The
following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:275: The
following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:442: Warning:
Could
not find file
/root/workspaces/workspace/drlvm/build/make/no_settings_in_config_or_environment
to copy.
How can I do with it?
Thanks.
On 10/17/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/10/16, Leo Li [EMAIL PROTECTED]:
It seems not quite related to actual memory stress although the
reported
error is ENOMEM.
I have run it both in eclipse and console. And there are enough
memory
available.
Furthermore, the case can be repeated even though in the same
time a
C
program runs well when using fork().
I suspect that it is related with VM since it can be only
reproduced
by
VM
calling it. I am not sure whether vm does something behind me,
but I
have
not thought out of a way that a user-space program have such
effect.:)
Actually drlvm provides own impl of j.l.Process. Interesting,
would it
work if switched to classlib's impl - then this should be process
impl
issue. Could you please try the following patch with DRLVM and see if
it works?
Index: vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java
===
--- vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java
(revision 464817)
+++ vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java
(working
copy)
@@ -743,14 +743,15 @@
//#IN004# Should we check: envp != null ?
//#IN004# Should we check envp's direction values:
envp[i] !=
null ?
-String dirPathName = (dir != null ? dir.getPath() : null);
+//String dirPathName = (dir != null ? dir.getPath() : null);
-SubProcess sp = new SubProcess();
+//SubProcess sp = new SubProcess();
-sp.execVM(cmdarray, envp, dirPathName);
+//sp.execVM(cmdarray, envp, dirPathName);
-return sp;
-
+//return sp;
+return
org.apache.harmony.luni.internal.process.SystemProcess
.
+ create(cmdarray, envp == null ? new String[0] : envp,
dir);
}
--
Alexey
On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm confused. Didn't you just report this on Ubuntu?
I have had similar forking problems on Ubuntu 6 (I once found a
bug in
classlib related to forking...).
I never figured out why Unbuntu does this, but it seemed that
under
memory stress, Ubuntu's fork() fails. Try this - close Eclipse
and
run
the test again...
geir
Leo Li wrote:
Thank you.
I have just run it on drlvm of unbuntu, it works.
What a qurious problem!
On 10/16/06, Alexey Varlamov [EMAIL PROTECTED]
wrote:
Both DRLVM and J9 works for me (SUSE9).
--
Alexey
2006/10/16, Leo Li [EMAIL PROTECTED]:
Hi, all:
The harmony Runtime.exec fails on Linux with ENOMEM.
Here is the testcase:
public class Exec {
public static void main(String[] args) throws Exception {
Runtime.getRuntime().exec(ls);}
}
I have tried it on RedHat Enterprise 4 and Unbuntu, both
get
ENOMEM
in
native code.
After digging into it, I found it fails in procimpl.c,
line
135:
grdpid = fork ();
If the call to fork is changed to vfork, the testcase
will
pass
but
Re: [classlib][awt] Does Harmony awt support win.xpstyle.dllName desktop property in windows XP?
How many are there that aren't described?
Sergey Soldatov wrote:
No, it doesn't. Unfortunately most of desktop properties are not described
in j2se documentation. If you feel that we need to support this
property please file JIRA issue and we'll try to fix it ASAP.
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi, does Harmony awt support win.xpstyle.dllName desktop property in
windows XP?
Consider following code:
public static void main(String[] args) {
Toolkit toolkit = Toolkit.getDefaultToolkit();
String xpstyleDll = (String) toolkit
.getDesktopProperty(win.xpstyle.dllName);
System.out.println(xpstyleDll);
}
RI Output:
C:\WINDOWS\resources\Themes\luna\luna.msstyles
Harmony Output:
null
--
Best regards,
Andrew Zhang
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ECJ set as default compiler (WAS: [general] version of gcc and other tools)
Nathan Beyer wrote:
I haven't figured out to configure the ECJ options via the Ant task
yet, so if anyone know, please let the list know.
Add a compilerarg nested element, e.g.
Index: build-java.xml
===
--- build-java.xml (revision 464908)
+++ build-java.xml (working copy)
@@ -141,6 +141,9 @@
source=${hy.javac.source}
target=${hy.javac.target}
debug=${hy.javac.debug}
+
+compilerarg value=-warn:unusedImport /
+
src path=modules/accessibility/src/main/java/ /
src path=modules/annotation/src/main/java/ /
src path=modules/applet/src/main/java /
where the argument is taken from this list:
http://dev.eclipse.org/viewcvs/index.cgi/*checkout*/jdt-core-home/howto/batch%20compile/batchCompile.html?rev=HEADcontent-type=text/html
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]
[classlib][luni] Please review HARMONY-1858 (Eclipse Help failure)
Hi all, Could anyone please review the problem description and the fix suggested for https://issues.apache.org/jira/browse/HARMONY-1858#action_12442838? Although the problem reported is not reproducible with the fix, I suspect that the issue might need more thorough investigation and a better fix. Thank you in advance! Best regards, Nina Rinskaya - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][swing] test hangs: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A:
2006/10/17, Ivanov, Alexey A [EMAIL PROTECTED]: Hello everyone, When running tests on Windows, FileSystemViewTest.testGetSystemDisplayName() pops up a dialog prompting to insert disk into drive A:. This dialog prevents normal running of other tests. LOL IMO, the problem assertion could be deleted without loss of coverage. Any other comments/opinions? See the JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1892 Regards, Alexey. P.S. The problem code is at lines 85-86 in FileSystemViewTest.java: file = File.listRoots()[0]; assertNotSame(file.getName(), view.getSystemDisplayName(file)); The assertion doesn't look foolproof anyway. Accordingly to spec getSystemDisplayName() should return *some* name, max what we may assert that it is not null and not empty. -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] the big soup of VM properties (HARMONY-1626)
Is there any progress in this area? Just an interest, because I think that properties refactoring is rather important task. + Does anybody knows the answer on the following question: All JIT settings are VM properties. User can change the behaviour by redefining them. Does it affect TCK certification? On 10/12/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Wednesday 11 October 2006 09:41 Mikhail Fursov wrote: +1 to Eugueni and Alexey and -1 to use String type in the intercomponent interface. + AFAIK the String type is VM internal type only. Ok you've convinced me. +1 for const char * On 10/11/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/10/11, Evgueni Brevnov [EMAIL PROTECTED]: Gregory, My 2cents: 1cent) I think we should not integrate property module so tight (by using StringPool) with VM internals. Let it be independent enough. 2cent) I also don't think we should pollute StringPool any further. Instead I would like to see if we can get it smaller say by splitting into two pools whatever... Agreed. Besides properties are used in VM almost solely during init, no performance gain here. So -1 to using Strings for properties. Evgueni On 10/11/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Tuesday 10 October 2006 11:36 Geir Magnusson Jr. wrote: Inline Dmitry Yershov wrote: [snip] VM properties proposal == The general purpose of VM Properties subcomponent is to provide centralized access to a common properties table. A property is meant as a pair of key and value. The properties stored in VM Properties table represent configuration settings for a separate component (such as VMCore, GC, JIT etc) or for the whole system. Another use case for the properties is communication between different components. Requirements 1) The key and value are represented as string (i.e. char*). and I propose that on each operation, a copy is made, so that the caller frees the string that they got or gave. Hmm... I thought of another type. VM has a String class which represents an internal strings implementation. String pointers all refer to the same interned const char * memory location so comparing them is faster, you just compare pointers. Would it be better to have key and value be String * instead of const char *? It would save memory allocation, copying and comparing and lookup in properties hash table could be done using a pointer. I don't think it is a very performance critical place, properties aren't accessed very often, but at least it may reduce memory footprint and will cause less memory leaks when someone forgets to free a returned copy. On the other hand, String storage is global to the whole VM, so there are tons of strings kept inside of it. Lookup inside of a small hash table like properties may be much faster than lookup through all the strings that VM keeps... Hmm now I am not sure I want to suggest this way, just want it to be considered. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mikhail Fursov
Re: Hot to Write GC requires improvement
I agree with Rana's, Geir's and Salikh's comments. One minor comment. Section 2 is titled, Implementing the GC interface. A better description might be something like, Implementing a collector that uses the GC interface. On 10/16/06, Konovalova, Svetlana [EMAIL PROTECTED] wrote: Folks, I took a close look at Hot to Write GC [1] and created a patch for this doc [JIRA 1881]. I fixed formatting, brushed up the code, removed out-dated tags etc. It would be great if someone can find a chance to look at the patch. Thanks in advance! [1] http://incubator.apache.org/harmony/subcomponents/drlvm/gc-howto.html [JIRA 1881] http://issues.apache.org/jira/browse/HARMONY-1881 Cheers, Sveta Konovalova - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division
Re: [general] POLL : supported platforms
Mikhail Fursov wrote: On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Great! Write that down with your votes. (Note, I was just kicking this off, not being comprehensive...) OK, I'll try to add more restrictions to the list. 1) DRLVM JIT has a limitation today: we can run only on PC with SSE/SSE2 support. This can be an advanced task for JIT gurus to add x87 support, but before that we can't claim that we officially support hardware without SSE2. 2) Do we need to add to the 'officially supported' list platforms that are unable to run HelloWorld app? I don't understand - how would it be supported if it didn't work? Maybe we can give another name to the list of such platforms and move a platform into the 'officially supported' list only when it runs simple apps? - 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] graduate from incubator to be a Top Level Project of the ASF
Alex Blewitt wrote: On 17/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: The Harmony PPMC has been discussing and has approved asking to graduate from the Apache Incubator and become a Top Level Project. This means that we would become an official project of the Apache Software Foundation. Any comments, for or against? I'm sure such a transition would cause the odd slashdot story etc. upon graduation; I think it would be good advertising to have a list of a few known-good apps that run mostly with Harmony (e.g. ant, eclipse etc.) Although it's still a work-in-progress, it would be a good milestone to state the current achievements (and also to ask for further help :-) Absolutely. I was just trying to relay the idea that our lives won't change - we have lots of work to do and we'll keep doing it in the way we have been. geir Other than that observation, great :-) 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: [drlvm] Thread me tender, thread me true, never throw an OOM...
Gier,
I do some experiments on this issue.
It is funny, but it is reproduced only by ubuntu user that logged to console.
It does not reproduce on SuSe at all.
Following sequence is more funny : ))
[EMAIL PROTECTED] java Test
fail ... on 370
[EMAIL PROTECTED] su - kna
[EMAIL PROTECTED] java Test
passed with 470
[EMAIL PROTECTED] su - ali
[EMAIL PROTECTED] java Test
passed with 470
I'll try to solve the mystery.
It could be a problem with freeing memory from dead threads and with
the linkage.
Attached build fix introduce -lpthread shared linkage. This allows
specify thread stack size in our VM (1M by default). thread count int
Test increase from 370 to 1000.
Thanks
Artem
On 17 Oct 2006 16:14:58 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x205 day of Apache Harmony Geir Magnusson, Jr. wrote:
So, with
public class Test implements Runnable {
static int i = 0;
public void run() {
try {
Thread.sleep(1);
} catch (Throwable e) { e.printStackTrace();
}
}
Test() {
new Thread(this).start();
}
public static void main(String args[]) {
for(;;) {
i++;
if (i % 1000 == 0) {
System.out.println(Iteration: + i);
}
new Test();
}
}
}
How far do you get? I get to 340... and then OOM. Why are threads so
heavy?
4435000 on SUSE9 with:
object_handles.cpp:270: ObjectHandlesNew*
oh_add_new_handles(ObjectHandlesNew**): Assertion `n' failed
Jrockit gave no more than 405000. Even more interesting...
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: build/make/components/vm/vmcore.xml
===
--- build/make/components/vm/vmcore.xml (revision 464417)
+++ build/make/components/vm/vmcore.xml (working copy)
@@ -292,13 +292,6 @@
select os=lnx
syslibset type=shared libs=m,dl,stdc++,z,xml2,pthread,gcc_s,rt /
-linkerarg value=--export-dynamic /
-!--linkerarg value=-lz /
-linkerarg value=-lxml2 /
-linkerarg value=-lm /
-linkerarg value=-ldl /
-linkerarg value=-lpthread /
-linkerarg value=-lstdc++ /--
/select
/linker
/target
Index: build/make/components/vm/hythr.xml
===
--- build/make/components/vm/hythr.xml (revision 464417)
+++ build/make/components/vm/hythr.xml (working copy)
@@ -95,11 +95,11 @@
/select
select os=lnx
-syslibset libs=rt /
+syslibset libs=pthread,rt /
linkerarg value=-Wl,-init /
linkerarg value=-Wl,hythread_library_init /
linkerarg value=-Wl,--version-script,${src}/thread/src/hythr.exp /
-/select
+ /select
select os=win
syslibset libs=advapi32,ws2_32 /
Index: build/make/targets/common_vm.xml
===
--- build/make/targets/common_vm.xml (revision 464417)
+++ build/make/targets/common_vm.xml (working copy)
@@ -207,8 +207,8 @@
syslibset libs=advapi32,odbc32,userenv,ws2_32,mswsock /
/select
select os=lnx arch=ia32
-syslibset type=static libs=z,pthread,xml2 /
-syslibset type=shared libs=m,dl,stdc++,rt /
+syslibset type=static libs=z,xml2 /
+syslibset type=shared libs=m,dl,stdc++,rt,pthread /
/select
select os=lnx cxx=gcc arch=ia32
linkerarg value=-lgcc_s /
Index: build/make/targets/common_extra.xml
===
--- build/make/targets/common_extra.xml (revision 464417)
+++ build/make/targets/common_extra.xml (working copy)
@@ -46,8 +46,8 @@
syslibset libs=advapi32,odbc32,userenv,ws2_32,mswsock /
/select
select os=lnx
-syslibset type=static libs=z,pthread,xml2 /
-syslibset type=shared libs=m,dl,stdc++ /
+syslibset type=static libs=z,xml2 /
+syslibset type=shared libs=m,dl,stdc++,pthread /
/select
select os=lnx cxx=gcc
syslibset type=shared libs=gcc_s /
-
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][unit tests] the goal is to achieve 100% pass rate
HARMONY-1720 patch has been evaluated by Alexey Varlamov and could be committed too. On 10/17/06, Elena Semukhina [EMAIL PROTECTED] wrote: HARMONY-1823 is ready for commit. It will increase classlib pass rate significantly! On 10/17/06, Elena Semukhina [EMAIL PROTECTED] wrote: I added one more issue to http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM . It is http://issues.apache.org/jira/browse/HARMONY-1648 . It is drlvm/TM issue and will cause the ThreadGroupTest failure after HARMONY-1625 is applied. Could anyone look at this issue? On 10/17/06, Elena Semukhina [EMAIL PROTECTED] wrote: It seems that the patch for HARMONY-1751http://issues.apache.org/jira/browse/HARMONY-1751 is ready and the patch for HARMONY-1720http://issues.apache.org/jira/browse/HARMONY-1751 is waiting for Alexey Varlamov's evaluation. On 10/13/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Oops, review of HARMONY-1823 should be: The fix is to clean an interrupt flag. Patches are good. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Fedotov, Alexei A Sent: Friday, October 13, 2006 6:12 PM To: [EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org Subject: RE: [drlvm][unit tests] the goal is to achieve 100% pass rate Geir, I reviewed the patches for HARMONY-1816 (non-daemon thread counting is done more accurately) and for HARMONY-1823 - the fix is to clean patches are good. I believe the patches worth to be committed: I've tried the patches for running tests from luni module 162 times and get the following results: $ grep FAILED luni.log | sort | uniq -c 63 [junit] TEST org.apache.harmony.tests.internal.net.www.protocol.http .HttpURLConnectionTest FAILED 162 [junit] TEST tests.api.java.lang.reflect.FieldTestFAILED 6 [junit] TEST tests.api.java.net.InetAddressTest FAILED The following tests were excluded: Index: modules/luni/build.xml === --- modules/luni/build.xml (revision 463342) +++ modules/luni/build.xml (working copy) @@ -325,6 +325,14 @@ exclude name=tests/api/java/net/URLConnectionTest.jav a / exclude name=tests/api/java/net/URLTest.java / exclude name=tests/api/java/net/SocketPermissionTest. java / + +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadGroupTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadLocalTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ClassTest.java / +exclude name=tests/api/java/util/FormatterTest.java / + /fileset /batchtest With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Geir Magnusson Jr. [mailto: [EMAIL PROTECTED] Sent: Friday, October 13, 2006 9:58 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][unit tests] the goal is to achieve 100% pass rate great work - we'll get those applied ASAP. Elena Semukhina wrote: Yesterday I tried the following patches: http://issues.apache.org/jira/browse/HARMONY-1592 http://issues.apache.org/jira/browse/HARMONY-1816 http://issues.apache.org/jira/browse/HARMONY-1823 https://issues.apache.org/jira/browse/HARMONY-1741 They work fine. The first three patches restore recent classlib tests pass rate degradation. On 10/11/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Excellent. As appreciative as I am of J9, I can't wait to work in all-Harmony code :) geir Elena Semukhina wrote: Hello all, I think that the goal of running classlib unit tests on DRLVM with 100% pass rate could be worth to achieve. Actually today we have 99% (without awt/swing) but still have about 30 failures/errors. Most of them have been evaluated and corresponding JIRAs filed. There is a page on Harmony Wiki which lists those JIRA issues: http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM Are there any volunteers to help with DRLVM bugs fixing? 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]
Re: [general] graduate from incubator to be a Top Level Project of the ASF
:( It's a peak of the evolutionary process inside of Apache. Nothing to dream about left here.. On 10/17/06, Weldon Washburn [EMAIL PROTECTED] wrote: +1 Wonderful! On 10/17/06, Tim Ellison [EMAIL PROTECTED] wrote: +1. I'm for it. Regards, Tim Geir Magnusson Jr wrote: The Harmony PPMC has been discussing and has approved asking to graduate from the Apache Incubator and become a Top Level Project. This means that we would become an official project of the Apache Software Foundation. In terms of our day-to-day life, nothing should change. We'd get a new URL for the project (http://harmony.apache.org) and our mail lists would change to whatever@harmony.apache.org. There also may be contributors out there that are more comfortable contributing to a top-level project rather than one in the Incubator, but given how solid this project is (IMO), I don't see how that matters. I mean, if it was good enough for all of us to participate in, and for Intel, IBM, ITC to make contributions to :) Anyway, unless there is opposition from the community, we'll start moving forward with this. Any comments, for or against? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] -- Weldon Washburn Intel Middleware Products Division -- Mikhail Fursov
Re: [drlvm][unit tests] the goal is to achieve 100% pass rate
which patch of the two should be applied? Or both? (please respond on the JIRA...) Elena Semukhina wrote: HARMONY-1823 is ready for commit. It will increase classlib pass rate significantly! On 10/17/06, Elena Semukhina [EMAIL PROTECTED] wrote: I added one more issue to http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM . It is http://issues.apache.org/jira/browse/HARMONY-1648. It is drlvm/TM issue and will cause the ThreadGroupTest failure after HARMONY-1625 is applied. Could anyone look at this issue? On 10/17/06, Elena Semukhina [EMAIL PROTECTED] wrote: It seems that the patch for HARMONY-1751http://issues.apache.org/jira/browse/HARMONY-1751 is ready and the patch for HARMONY-1720http://issues.apache.org/jira/browse/HARMONY-1751 is waiting for Alexey Varlamov's evaluation. On 10/13/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Oops, review of HARMONY-1823 should be: The fix is to clean an interrupt flag. Patches are good. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Fedotov, Alexei A Sent: Friday, October 13, 2006 6:12 PM To: [EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org Subject: RE: [drlvm][unit tests] the goal is to achieve 100% pass rate Geir, I reviewed the patches for HARMONY-1816 (non-daemon thread counting is done more accurately) and for HARMONY-1823 - the fix is to clean patches are good. I believe the patches worth to be committed: I've tried the patches for running tests from luni module 162 times and get the following results: $ grep FAILED luni.log | sort | uniq -c 63 [junit] TEST org.apache.harmony.tests.internal.net.www.protocol.http .HttpURLConnectionTest FAILED 162 [junit] TEST tests.api.java.lang.reflect.FieldTest FAILED 6 [junit] TEST tests.api.java.net.InetAddressTest FAILED The following tests were excluded: Index: modules/luni/build.xml === --- modules/luni/build.xml (revision 463342) +++ modules/luni/build.xml (working copy) @@ -325,6 +325,14 @@ exclude name=tests/api/java/net/URLConnectionTest.jav a / exclude name=tests/api/java/net/URLTest.java / exclude name=tests/api/java/net/SocketPermissionTest. java / + +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadGroupTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadLocalTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ClassTest.java / +exclude name=tests/api/java/util/FormatterTest.java / + /fileset /batchtest With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Geir Magnusson Jr. [mailto: [EMAIL PROTECTED] Sent: Friday, October 13, 2006 9:58 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][unit tests] the goal is to achieve 100% pass rate great work - we'll get those applied ASAP. Elena Semukhina wrote: Yesterday I tried the following patches: http://issues.apache.org/jira/browse/HARMONY-1592 http://issues.apache.org/jira/browse/HARMONY-1816 http://issues.apache.org/jira/browse/HARMONY-1823 https://issues.apache.org/jira/browse/HARMONY-1741 They work fine. The first three patches restore recent classlib tests pass rate degradation. On 10/11/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Excellent. As appreciative as I am of J9, I can't wait to work in all-Harmony code :) geir Elena Semukhina wrote: Hello all, I think that the goal of running classlib unit tests on DRLVM with 100% pass rate could be worth to achieve. Actually today we have 99% (without awt/swing) but still have about 30 failures/errors. Most of them have been evaluated and corresponding JIRAs filed. There is a page on Harmony Wiki which lists those JIRA issues: http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM Are there any volunteers to help with DRLVM bugs fixing? 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](JIRA-1886)interior pointer for GCv5 of DRLVM
Weldon? Mikhail Fursov wrote: It's strange to me that it is not in the trunk too. So I was wrong. I thought it is already there because it was posted to JIRA many days ago and it was very urgent task. So it is still in JIRA: http://issues.apache.org/jira/browse/HARMONY-1785 On 10/17/06, yunan He [EMAIL PROTECTED] wrote: Mikhail, I can not find the code in SVN and could tell me the revision number? Thanks. Yu-Nan On 10/17/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yu-Nan, Yes, please open new JIRA issue with Jitrino.OPT implementation. On 10/17/06, yunan He [EMAIL PROTECTED] wrote: BTW, did the JET WB4C patch commit to the harmony? AFAIK Jitrino.JET does support WB4C and WB4J today. The code is already in SVN and GCv5 or any other generational GC can be tested with it. -- Mikhail Fursov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] POLL : supported platforms
On 10/17/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: 2) Do we need to add to the 'officially supported' list platforms that are unable to run HelloWorld app? I don't understand - how would it be supported if it didn't work? Neither do I. But I see in the list OsX, IPF... -- Mikhail Fursov
Re: [drlvm][kernel] Should we be compatible with RI ThreadGroup bug?
Agreed. Lets match J9 and RI for now. We can always revisit as it will be logged, right? :) Elena Semukhina wrote: As everyone keeps silence, I'd suggest to change implementation to be bug compatible with RI. On 10/15/06, Elena Semukhina [EMAIL PROTECTED] wrote: On 10/14/06, Tim Ellison [EMAIL PROTECTED] wrote: Elena Semukhina wrote: Classlib test ThreadGroupTest.test_setMaxPriorityI() fails on DRLVM because it expects behaviour that conflicts with specification. The test passes on IBM VME and RI. The issue is reported at https://issues.apache.org/jira/browse/HARMONY-1625 . Actually there is a bug report in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4708197 which agreed that this is a bug in RI and it should be fixed. Should we follow RI's behaviour and change drlvm ThreadGroup.java or should we fix the test? I'm off-line at the moment so cannot look at the bug details. The question is whether fixing the 'bug' will likely break any applications? This question was discussed in Sun's bug report as well. A JCK test detected this bug. The first evaluation stated that This is relatively obscure functionality and it's theoretically possible at that changing the behavior will break running apps. The second evaluation suggested to fix the implementation rather than change the spec. The bug is in progress since 2002... 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] -- 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]
Re: [drlvm] Thread me tender, thread me true, never throw an OOM...
Artem Aliev wrote:
Gier,
I do some experiments on this issue.
It is funny, but it is reproduced only by ubuntu user that logged to
console.
It does not reproduce on SuSe at all.
This is related to my instinct that there's something weird about Ubuntu
and memory. Remember the fork() ENOMOM issue that we found in
classlib? I could repeat it when Eclipse was running (separate process)
and it went away when it wasn't. And someone else is struggling with
under Ubuntu?
Following sequence is more funny : ))
[EMAIL PROTECTED] java Test
fail ... on 370
[EMAIL PROTECTED] su - kna
[EMAIL PROTECTED] java Test
passed with 470
[EMAIL PROTECTED] su - ali
[EMAIL PROTECTED] java Test
passed with 470
I'll try to solve the mystery.
It could be a problem with freeing memory from dead threads and with
the linkage.
Attached build fix introduce -lpthread shared linkage. This allows
specify thread stack size in our VM (1M by default). thread count int
Test increase from 370 to 1000.
That number is still low.
I'm glad it's just on Ubuntu and not a general issue. I'll try it under
Ubuntu 5.
geir
Thanks
Artem
On 17 Oct 2006 16:14:58 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x205 day of Apache Harmony Geir Magnusson, Jr. wrote:
So, with
public class Test implements Runnable {
static int i = 0;
public void run() {
try {
Thread.sleep(1);
} catch (Throwable e) { e.printStackTrace();
}
}
Test() {
new Thread(this).start();
}
public static void main(String args[]) {
for(;;) {
i++;
if (i % 1000 == 0) {
System.out.println(Iteration: + i);
}
new Test();
}
}
}
How far do you get? I get to 340... and then OOM. Why are threads so
heavy?
4435000 on SUSE9 with:
object_handles.cpp:270: ObjectHandlesNew*
oh_add_new_handles(ObjectHandlesNew**): Assertion `n' failed
Jrockit gave no more than 405000. Even more interesting...
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: build/make/components/vm/vmcore.xml
===
--- build/make/components/vm/vmcore.xml (revision 464417)
+++ build/make/components/vm/vmcore.xml (working copy)
@@ -292,13 +292,6 @@
select os=lnx
syslibset type=shared libs=m,dl,stdc++,z,xml2,pthread,gcc_s,rt /
-linkerarg value=--export-dynamic /
-!--linkerarg value=-lz /
-linkerarg value=-lxml2 /
-linkerarg value=-lm /
-linkerarg value=-ldl /
-linkerarg value=-lpthread /
-linkerarg value=-lstdc++ /--
/select
/linker
/target
Index: build/make/components/vm/hythr.xml
===
--- build/make/components/vm/hythr.xml (revision 464417)
+++ build/make/components/vm/hythr.xml (working copy)
@@ -95,11 +95,11 @@
/select
select os=lnx
-syslibset libs=rt /
+syslibset libs=pthread,rt /
linkerarg value=-Wl,-init /
linkerarg value=-Wl,hythread_library_init /
linkerarg
value=-Wl,--version-script,${src}/thread/src/hythr.exp /
-/select
+ /select
select os=win
syslibset libs=advapi32,ws2_32 /
Index: build/make/targets/common_vm.xml
===
--- build/make/targets/common_vm.xml(revision 464417)
+++ build/make/targets/common_vm.xml(working copy)
@@ -207,8 +207,8 @@
syslibset libs=advapi32,odbc32,userenv,ws2_32,mswsock /
/select
select os=lnx arch=ia32
-syslibset type=static libs=z,pthread,xml2 /
-syslibset type=shared libs=m,dl,stdc++,rt /
+syslibset type=static libs=z,xml2 /
+syslibset type=shared libs=m,dl,stdc++,rt,pthread /
/select
select os=lnx cxx=gcc arch=ia32
linkerarg value=-lgcc_s /
Index: build/make/targets/common_extra.xml
===
--- build/make/targets/common_extra.xml (revision 464417)
+++ build/make/targets/common_extra.xml (working copy)
@@ -46,8 +46,8 @@
syslibset libs=advapi32,odbc32,userenv,ws2_32,mswsock /
/select
select os=lnx
-syslibset type=static libs=z,pthread,xml2 /
-
Re: [drlvm] Thread me tender, thread me true, never throw an OOM...
Geir,
I am running Test.java on windows with an svn revision from late last week.
Right now, it is at Iteration: 140 and still going. Because of MMTk
porting, GCV4.0 is configured in. Perhaps you can try with GCV4.0 to narrow
down where the bug is?
On 17 Oct 2006 16:14:58 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x205 day of Apache Harmony Geir Magnusson, Jr. wrote:
So, with
public class Test implements Runnable {
static int i = 0;
public void run() {
try {
Thread.sleep(1);
} catch (Throwable e) { e.printStackTrace();
}
}
Test() {
new Thread(this).start();
}
public static void main(String args[]) {
for(;;) {
i++;
if (i % 1000 == 0) {
System.out.println(Iteration: + i);
}
new Test();
}
}
}
How far do you get? I get to 340... and then OOM. Why are threads so
heavy?
4435000 on SUSE9 with:
object_handles.cpp:270: ObjectHandlesNew*
oh_add_new_handles(ObjectHandlesNew**): Assertion `n' failed
Jrockit gave no more than 405000. Even more interesting...
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
Re: [drlvm] Thread me tender, thread me true, never throw an OOM...
-Dvm.finalize=off also help :)
On 10/17/06, Weldon Washburn [EMAIL PROTECTED] wrote:
Geir,
I am running Test.java on windows with an svn revision from late last week.
Right now, it is at Iteration: 140 and still going. Because of MMTk
porting, GCV4.0 is configured in. Perhaps you can try with GCV4.0 to narrow
down where the bug is?
On 17 Oct 2006 16:14:58 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x205 day of Apache Harmony Geir Magnusson, Jr. wrote:
So, with
public class Test implements Runnable {
static int i = 0;
public void run() {
try {
Thread.sleep(1);
} catch (Throwable e) { e.printStackTrace();
}
}
Test() {
new Thread(this).start();
}
public static void main(String args[]) {
for(;;) {
i++;
if (i % 1000 == 0) {
System.out.println(Iteration: + i);
}
new Test();
}
}
}
How far do you get? I get to 340... and then OOM. Why are threads so
heavy?
4435000 on SUSE9 with:
object_handles.cpp:270: ObjectHandlesNew*
oh_add_new_handles(ObjectHandlesNew**): Assertion `n' failed
Jrockit gave no more than 405000. Even more interesting...
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [DRLVM](JIRA-1886)interior pointer for GCv5 of DRLVM
I will get to it today. On 10/17/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Weldon? Mikhail Fursov wrote: It's strange to me that it is not in the trunk too. So I was wrong. I thought it is already there because it was posted to JIRA many days ago and it was very urgent task. So it is still in JIRA: http://issues.apache.org/jira/browse/HARMONY-1785 On 10/17/06, yunan He [EMAIL PROTECTED] wrote: Mikhail, I can not find the code in SVN and could tell me the revision number? Thanks. Yu-Nan On 10/17/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yu-Nan, Yes, please open new JIRA issue with Jitrino.OPT implementation. On 10/17/06, yunan He [EMAIL PROTECTED] wrote: BTW, did the JET WB4C patch commit to the harmony? AFAIK Jitrino.JET does support WB4C and WB4J today. The code is already in SVN and GCv5 or any other generational GC can be tested with it. -- Mikhail Fursov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division
Re: Coverage (was Re: 37% of total test execution time is spent in a single test)
Vladimir Do you know why javax.swing.text.html tests weren't computed by the coverage tool if they are present in the SVN tree? Gabriel Miretti 2006/10/10, Vladimir Ivanov [EMAIL PROTECTED]: On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: - '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. It will fine if somebody do it :). We have updated version of CC ( HARMONY-995 http://issues.apache.org/jira/browse/HARMONY-995) and coverage scripts (HARMONY-564 http://issues.apache.org/jira/browse/HARMONY-564 ). I hope we will have a japi script soon. Now I'm going to: - improve notification for CC to include txt files (output of cunit and smoke tests for DRLVM); - add imageio/print/applet modules to coverage script. I hope, it will be small updated to 'buildtest' module instead of reattach to jira a whole scripts again. thanks, Vladimir 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ECJ set as default compiler (WAS: [general] version of gcc and other tools)
how do you turn off the default ones?
Tim Ellison wrote:
Nathan Beyer wrote:
I haven't figured out to configure the ECJ options via the Ant task
yet, so if anyone know, please let the list know.
Add a compilerarg nested element, e.g.
Index: build-java.xml
===
--- build-java.xml (revision 464908)
+++ build-java.xml (working copy)
@@ -141,6 +141,9 @@
source=${hy.javac.source}
target=${hy.javac.target}
debug=${hy.javac.debug}
+
+compilerarg value=-warn:unusedImport /
+
src path=modules/accessibility/src/main/java/ /
src path=modules/annotation/src/main/java/ /
src path=modules/applet/src/main/java /
where the argument is taken from this list:
http://dev.eclipse.org/viewcvs/index.cgi/*checkout*/jdt-core-home/howto/batch%20compile/batchCompile.html?rev=HEADcontent-type=text/html
Regards,
Tim
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Thanks for all your messages, and congratulations to all the other new committers :) Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committers, in alphabetical order : Oliver Deakin Richard Liang Alexey Petrenko Gregory Shimansky Alexey Varlamov Alexei Zakharov These six individuals have shown sustained dedication to the project, an ability to work well with others, and share the common vision we have for Harmony. We all continue to expect great things from them. Gentlemen, you don't have accounts yet. When you finally receive your new committer account information, as a first step to test your almighty powers of committitude, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine 3) Add a public key to .ssh so you can stop using the password 4) Set your SVN password : just type 'svnpasswd' At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, anything checked out of SVN, be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - 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]
Re: [general] graduate from incubator to be a Top Level Project of the ASF
Mikhail Fursov wrote: :( It's a peak of the evolutionary process inside of Apache. Nothing to dream about left here.. are you kidding? Hows this for a dream : Our dream is to be the first compatible open source implementation of Java SE. June of 2007 is Sun's target date for completing the open sourcing of their implementation of Java SE. We have our target date for Apache Harmony 1.0. :) On 10/17/06, Weldon Washburn [EMAIL PROTECTED] wrote: +1 Wonderful! On 10/17/06, Tim Ellison [EMAIL PROTECTED] wrote: +1. I'm for it. Regards, Tim Geir Magnusson Jr wrote: The Harmony PPMC has been discussing and has approved asking to graduate from the Apache Incubator and become a Top Level Project. This means that we would become an official project of the Apache Software Foundation. In terms of our day-to-day life, nothing should change. We'd get a new URL for the project (http://harmony.apache.org) and our mail lists would change to whatever@harmony.apache.org. There also may be contributors out there that are more comfortable contributing to a top-level project rather than one in the Incubator, but given how solid this project is (IMO), I don't see how that matters. I mean, if it was good enough for all of us to participate in, and for Intel, IBM, ITC to make contributions to :) Anyway, unless there is opposition from the community, we'll start moving forward with this. Any comments, for or against? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] -- 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] POLL : supported platforms
2006/10/17, Geir Magnusson Jr. [EMAIL PROTECTED]: Mikhail Fursov wrote: On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Great! Write that down with your votes. (Note, I was just kicking this off, not being comprehensive...) OK, I'll try to add more restrictions to the list. 1) DRLVM JIT has a limitation today: we can run only on PC with SSE/SSE2 support. This can be an advanced task for JIT gurus to add x87 support, but before that we can't claim that we officially support hardware without SSE2. 2) Do we need to add to the 'officially supported' list platforms that are unable to run HelloWorld app? I don't understand - how would it be supported if it didn't work? What do you mean by work? Runs hello world app? At the point we decide to support a new platform it's unlikely that the new platform works. But if we don't support a platform then we doubtfully will be able to make it running even hello, because each our commit could make the code for that unsupported platform worse and worse. I think if we decide to support a platform then we define a set of tests that must pass on that platform after each commit and we do roll back if they fail. That is how I understand support Thanks, Mikhail Maybe we can give another name to the list of such platforms and move a platform into the 'officially supported' list only when it runs simple apps? - 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] Calling native methods from Java code: implementation details
All, Finally we have almost everything finished to post helper's fast-path inlining framework into JIRA. The issue is left is how to call native slow-path versions of the from Java code. We already discussed some of the aspects, but there was no detailed discussion with a final agreement what API we will use. Let's make a final decision so I can add the code into JIRA. I'm sending my vision of the solution. Correct me or advise another approach. Step 1: How JIT will know if a Java method must be replaced with a native helper call. Solution 1.A: Every Java method that must be replaced with native call must be a static method and must have special Native runtime method annotation. Step 2: How JIT will get the address of the native method to generate a direct call? Solution 2.A: Every Java method that must be replaced with native call must have special Component annotation. JIT will use this annotation to ask Component Manager to access to the specified component by it's name and call void* getAddress(const char* methodName) component's method to get the address of a helper. That is every component that have native calls from Java must provide this interface. Step 3: How JIT will know which calling convention to use? Solution 3.A: Use method's annotation again. These were all of the problems with native calls. Now we need to agree if the solution proposed is OK or find another one. Please note, that this is just the first implementation. We can extend it with more features in the future. -- Mikhail Fursov
