Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Evgueni, 1) Which of the patches is a final? 2) It looks like you do not find a way to remove hythread_library_t from parameters and JavaVM from thread manager code. Well, leave it as is, I will try to fix this later. 2) Is the following global variable is necessary? extern hythread_library_t TM_LIBRARY; Thanks Artem - 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] removing \t from sources
Yes, I am really upset. Code formater is ok, any means are good. :)
Thanks.
2006/10/2, Tim Ellison [EMAIL PROTECTED]:
if it is upsetting you so much, I'll run the code formatter over beans
tests -- that will do the whitespace replacements. We have been
replacing them incrementally to date.
Not a slur on your script you know.
Regards
Tim
Alexey Petrenko wrote:
I mean that {space, space, tab} will be converted to the same
number of spaces as simple tab by the most of editors.
SY, Alexey
2006/10/2, Alexei Zakharov [EMAIL PROTECTED]:
What do you mean? Convert \t to something? If so please see the
new fully customized version of my mega-script :-)
The usage pattern in your case will be:
ant -f tabs2spaces_v2.xml -Dsrc.dir=dir with sources -Dpattern= \t
Regards,
2006/10/2, Alexey Petrenko [EMAIL PROTECTED]:
Does it work with the sequences like {space, space, tab} etc?
2006/10/2, Alexei Zakharov [EMAIL PROTECTED]:
Hi all,
I noticed that the tab character (0x09) is still widely used in our
classlib source code. At least in tests. From my recent experience
this leads to broken indentation. I mean the situation when patch
with
spaces is applied to the source there tab character is used for
indentation. Someone knows that according to Sun code conventions the
tab should be exactly 8 spaces. The other person knows that exactly
four spaces should be used as the unit of indentation [1]. As a
result
we have all methods indented with the single tab character and the
patched methods indented with 4 spaces. And if your IDE is configured
to display tabs as 8 spaces you will see broken indentation. Or vice
versa.
I have created small ANT script - see HARMONY-1660 [2]. This script
converts all tabs to spaces in all found sources under the given
directory recursively. I will be grateful if someone runs this script
(tab - 4 spaces) at least for beans tests (I currently working with)
and integrates the results. It is really painful to deal with this
broken alignment every day. And it is too boring (and IMHO silly) to
convert it file by file and send patches for each case.
[1]
http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html#262
[3] http://issues.apache.org/jira/browse/HARMONY-1660
Thanks,
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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]
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [class][awt] RI bug??? BufferedImage.isTileWritable(int,int) throws IllegalArgumentException while Harmony throws ArrayIndexOutOfBoundsException
On 10/2/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Seems this is RI bug.
Apparently, RI doesn't comply with spec this time. But I think
IllealArgumentException is also acceptable. Therefore, I suggest to follow
RI and mark this issue as Non-bug differences from spec as
exception-throwing guideline[1] suggests. Thanks!
[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
RI implementation of BufferedImage.isTileWritable(int,int) throws
IllegalArgumentException while Harmony throws
ArrayIndexOutOfBoundsException to follow spec.
== Spec =
public boolean isTileWritable(int tileX, int tileY)
Throws:
ArrayIndexOutOfBoundsException - if both tileX and tileY are not equal to
0
Test
import java.awt.image.*;
public class Test {
public static void main(String[] argv) {
BufferedImage img = new BufferedImage(10, 16,
BufferedImage.TYPE_4BYTE_ABGR);
img.isTileWritable(1,1);
}
}
== RI output =
java.lang.IllegalArgumentException: Only 1 tile in image
at java.awt.image.BufferedImage.isTileWritable(BufferedImage.java:1526)
at Test.main(Test.java:6)
= Harmony output
java.lang.ArrayIndexOutOfBoundsException: Both tileX and tileY are not
equal to 0
at java.awt.image.BufferedImage.isTileWritable(BufferedImage.java:603)
So I have filed issue as non-bug.
Any comments?
2006/10/2, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[class][awt] BufferedImage.isTileWritable(int,int) throws
IllegalArgumentException while Harmony throws ArrayIndexOutOfBoundsException
Key: HARMONY-1658
URL: http://issues.apache.org/jira/browse/HARMONY-1658
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Denis Kishenko
RI implementation of BufferedImage.isTileWritable(int,int) throws
IllegalArgumentException while Harmony throws ArrayIndexOutOfBoundsException
to follow spec.
== Spec =
public boolean isTileWritable(int tileX, int tileY)
Throws:
ArrayIndexOutOfBoundsException - if both tileX and tileY are not equal
to 0
Test
import java.awt.image.*;
public class Test {
public static void main(String[] argv) {
BufferedImage img = new BufferedImage(10, 16,
BufferedImage.TYPE_4BYTE_ABGR);
img.isTileWritable(1,1);
}
}
== RI output =
java.lang.IllegalArgumentException: Only 1 tile in image
at java.awt.image.BufferedImage.isTileWritable(BufferedImage.java
:1526)
at Test.main(Test.java:6)
= Harmony output
java.lang.ArrayIndexOutOfBoundsException: Both tileX and tileY are not
equal to 0
at java.awt.image.BufferedImage.isTileWritable(BufferedImage.java
:603)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
--
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
Re: [classlib] removing \t from sources
I see. This IMHO is another argument why \t is bad. My script will not
be able to handle this, it just replaces one string pattern with
another. So such cases should be handled manually or with the code
formatter. However, the drawback of the code formatter is that it
removes the author's personality from the code.
But IMHO mixing spaces with tabs in the single unit of indentation is
even worse than just using tabs. Normally people use either tabs or
spaces. I suppose that mixes appear when the original source with tabs
is being edited with IDE configured to use spaces. I haven't seen many
of such cases in HY code, at least in the modules I worked with.
With best regards,
2006/10/2, Alexey Petrenko [EMAIL PROTECTED]:
I mean that {space, space, tab} will be converted to the same
number of spaces as simple tab by the most of editors.
SY, Alexey
2006/10/2, Alexei Zakharov [EMAIL PROTECTED]:
What do you mean? Convert \t to something? If so please see the
new fully customized version of my mega-script :-)
The usage pattern in your case will be:
ant -f tabs2spaces_v2.xml -Dsrc.dir=dir with sources -Dpattern= \t
Regards,
2006/10/2, Alexey Petrenko [EMAIL PROTECTED]:
Does it work with the sequences like {space, space, tab} etc?
2006/10/2, Alexei Zakharov [EMAIL PROTECTED]:
Hi all,
I noticed that the tab character (0x09) is still widely used in our
classlib source code. At least in tests. From my recent experience
this leads to broken indentation. I mean the situation when patch with
spaces is applied to the source there tab character is used for
indentation. Someone knows that according to Sun code conventions the
tab should be exactly 8 spaces. The other person knows that exactly
four spaces should be used as the unit of indentation [1]. As a result
we have all methods indented with the single tab character and the
patched methods indented with 4 spaces. And if your IDE is configured
to display tabs as 8 spaces you will see broken indentation. Or vice
versa.
I have created small ANT script - see HARMONY-1660 [2]. This script
converts all tabs to spaces in all found sources under the given
directory recursively. I will be grateful if someone runs this script
(tab - 4 spaces) at least for beans tests (I currently working with)
and integrates the results. It is really painful to deal with this
broken alignment every day. And it is too boring (and IMHO silly) to
convert it file by file and send patches for each case.
[1] http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html#262
[3] http://issues.apache.org/jira/browse/HARMONY-1660
Thanks,
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
On 10/3/06, Artem Aliev [EMAIL PROTECTED] wrote: Evgueni, Artem, 1) Which of the patches is a final? invocation_api.4.patch is final. so far :-) 2) It looks like you do not find a way to remove hythread_library_t from parameters and JavaVM from thread manager code. Well, leave it as is, I will try to fix this later. No problems, I agree to review it later 2) Is the following global variable is necessary? extern hythread_library_t TM_LIBRARY; Unfortunately, yes. I believe we need to get rid of that for multi-VM but it seems to be another story... Thanks a lot Evgueni Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [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: [class][awt] RI bug??? BufferedImage.isTileWritable(int,int) throws IllegalArgumentException while Harmony throws ArrayIndexOutOfBoundsException
Andrew thanks for answer.
I have checked RI 1.4 behavior and spec, it's the same -
IllegalArgumentException. May be it's just JavaDoc mistake.
RI and mark this issue as Non-bug differences from spec as
exception-throwing guideline[1] suggests. Thanks!
Unfortunatelly JIRA hasn't such category.
So I will fix this issue.
2006/10/3, Andrew Zhang [EMAIL PROTECTED]:
On 10/2/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Seems this is RI bug.
Apparently, RI doesn't comply with spec this time. But I think
IllealArgumentException is also acceptable. Therefore, I suggest to follow
RI and mark this issue as Non-bug differences from spec as
exception-throwing guideline[1] suggests. Thanks!
[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
RI implementation of BufferedImage.isTileWritable(int,int) throws
IllegalArgumentException while Harmony throws
ArrayIndexOutOfBoundsException to follow spec.
== Spec =
public boolean isTileWritable(int tileX, int tileY)
Throws:
ArrayIndexOutOfBoundsException - if both tileX and tileY are not equal to
0
Test
import java.awt.image.*;
public class Test {
public static void main(String[] argv) {
BufferedImage img = new BufferedImage(10, 16,
BufferedImage.TYPE_4BYTE_ABGR);
img.isTileWritable(1,1);
}
}
== RI output =
java.lang.IllegalArgumentException: Only 1 tile in image
at java.awt.image.BufferedImage.isTileWritable(BufferedImage.java:1526)
at Test.main(Test.java:6)
= Harmony output
java.lang.ArrayIndexOutOfBoundsException: Both tileX and tileY are not
equal to 0
at java.awt.image.BufferedImage.isTileWritable(BufferedImage.java:603)
So I have filed issue as non-bug.
Any comments?
2006/10/2, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[class][awt] BufferedImage.isTileWritable(int,int) throws
IllegalArgumentException while Harmony throws ArrayIndexOutOfBoundsException
Key: HARMONY-1658
URL: http://issues.apache.org/jira/browse/HARMONY-1658
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Denis Kishenko
RI implementation of BufferedImage.isTileWritable(int,int) throws
IllegalArgumentException while Harmony throws ArrayIndexOutOfBoundsException
to follow spec.
== Spec =
public boolean isTileWritable(int tileX, int tileY)
Throws:
ArrayIndexOutOfBoundsException - if both tileX and tileY are not equal
to 0
Test
import java.awt.image.*;
public class Test {
public static void main(String[] argv) {
BufferedImage img = new BufferedImage(10, 16,
BufferedImage.TYPE_4BYTE_ABGR);
img.isTileWritable(1,1);
}
}
== RI output =
java.lang.IllegalArgumentException: Only 1 tile in image
at java.awt.image.BufferedImage.isTileWritable(BufferedImage.java
:1526)
at Test.main(Test.java:6)
= Harmony output
java.lang.ArrayIndexOutOfBoundsException: Both tileX and tileY are not
equal to 0
at java.awt.image.BufferedImage.isTileWritable(BufferedImage.java
:603)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
--
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
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] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Andrey, Just to be clear I agree with you it is more convenient if jthread_create takes JNIEnv instead of JavaVM. It reflects that current thread has been attached already. Do you think it makes sense to get rid of JNIEnv and use jthread_get_JNI_env in that case? The jthread_* layer is designed like if it were a regular JNI application which is meant to be called from the Java code, hence every function on that layer receives JNIenv. We can probably get rid of the JNEnv parameter for jthread_* functions, assuming that TM can always extract JNIenv for the current thread with jthread_get_JNI_env(). My only concern would be the performance - once the JNIenv is already known for the native part of the kernel classes impl, it must be cheaper to pass JNIEnv to TM as an extra parameter rather than extract it from the TLS again. Other than that, I see no strong advantages in keeping JNIEnv parameter. Regarding jthread_attach. I still didn't get your point Clarify it please if you think jhread_attach should be modified. Sorry for being not clear: I think for jthread_attach, we have two options: 1) Make JNIEnv input parameter - it must be new JNIEnv that VM pre-allocates for the new Java thread. jthread_attach would just associate it with the current thread. 2) Obtain JNIEnv via vm_attach() callback. In this case, if vm_attach() callback implementation needs to know for which JavaVM new JNIenv has to be allocated, then we'll need to add JavaVM as input parameter for jthread_attach(). I think both options should be fine, (1) would probably keep TM interface a bit lighter, though (2) may look more closer to the JNI invocation API idea. So I think adding JavaVM specifically for jthread_attach may make sense given the explanation you provided earlier. The concern I would have regarding the proposed jthread_attach implementation is a call to vm_create_jthread() - this call introduces an extra dependency of TM on vmcore that I'd prefer to be avoided. In the original version, jthread_attach() was taking jthread argument of the already prepared j.l.Thread. Do you think it makes sense to replace a single jthread parameter with a variety of stuff (like thread group, name)? It seems the only purpose of at these args is to be passed back to VM for vm_jthread_create(). I would suggest to change this and try doing either of: 1) Make signature of jthread_attach with 3 args, JavaVM, jthread and the daemon. 2) Move the implementation of vm_create_jtrhead() to thread_java_basic.c - could it be written in pure JNI without using internal VM API like class_alloc_new_object()? Thanks, Andrey. Thank you Evgueni On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/29/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 9/29/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Artem, Thank you for your feedback find my inlined. On 9/29/06, Artem Aliev [EMAIL PROTECTED] wrote: Evgueni, I got most of your changes, but still disagree with all hythread/jthread interface changes. Could leave interface unchanged. See following possible solutions, that could solve the same problems without interface changes. 1) daemon attribute is a java specific. (Andrey mentioned this already). Could you please move it back. to the jthread layer. It is better to rename hythread_wait_for_all_nondaemon_threads() to jthread_wait_for_all_nondaemon_threads(). Ok, I see no problems to move daemon to java layer. In that case: 1) I will move hythread_wait_for_all_nondaemon_threads() from thread_init.c to one which implements java layer. 2) I will move daemon field from HyThread structure. Agree? Sounds good to me. OK, will do that. 2) JavaVM could be retrieved from JNIEnv by jni_get_java_vm(). So let the jthread_create() and others to use JNIEnv (that is passed from java native method). The vm_attach could get old JNI env and create new one for the new thread. The first JNIEnv is created in CreateVM call and could be passed to the first thread at startup. No, no, no. I completely disagree with that!!! Why do you like JNIEnv but JavaVM. Why do you think that passing JavaVM instead of JNIEnv makes TM less modular? I don't see any difference here It seems for me like a big big hack to grab JNIEnv from another thread and pass it to jthread_attach to perform operations in the current thread. TM needs to know JNIEnv, mainly for managing the references to objects, throwing exceptions and calling run() method of a new thread. JNI spec proposes that JNIEnv is valid within the given thread, this is why TM holds the JNIEnv pointer at the moment. This is why TM likes the JNIEnv. Having the JNIEnv, one is able to get JavaVM but not vise versa. This is why TM doesn't like the JavaVM :) I see your point. Only one note this is
[r451637] - Code cleanup - ... - Remove unnecessary comments
Nathan,
I've seen you dropped many TODOs in - Code cleanup - series of commits;
I'd like to know what reasoning was behind this? I think it's a bit
early to erase TODOs without appropriate consideration...
In particular, could you please undo the following change, it produces
garbage messages during AUTH testing:
modules/auth/src/main/java/common/org/apache/harmony/auth/login/DefaultConfigurationParser.java
===
@@ -216,12 +206,12 @@ public class DefaultConfigurationParser
try {
val = PolicyUtils.expand(st.sval, system);
} catch (Exception e) {
- //TODO: warning log
- }
+ e.printStackTrace();
+ }
}
--
WBR,
Alexey
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm][kernel exception handling] several issues
Dear committers, I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the suggested patches. So, to avoid redoubling efforts or superposition of commits because of delay could somebody take them under a control to estimate and apply if it is necessary? All the more, the 1650 and 1573 issues seem to be able to upset somehow the execution stability of a big application. Great thanks in advance, Serguei
Re: [classlib] Trying to catch patternset errors earlier
Mark Hindess wrote:
On 28 September 2006 at 14:58, Alexey Petrenko [EMAIL PROTECTED] wrote:
2006/9/28, Mark Hindess [EMAIL PROTECTED]:
On 28 September 2006 at 14:30, Alexey Petrenko [EMAIL PROTECTED]
om wrote:
I think that it will be better to add another target to build for
this check.
Because of two reasons:
1. It is unclear that clean is also checks something
This simple check can only happen part way through the clean target -
after the modules have done their cleaning and before the top-level
cleanup is done.
I see your point.
But let's review the sitatuation from another viewpoint...
What do we need in general?
We need up-to-date list of all packages in the specified module. Right?
If so we can create simple script to update patternset files... Or
even create them at build time. But will cost us build time itself :)
That's a reasonable point. I had a look at what it would take to get
rid of the patternsets completely. It's quite easy for some modules.
For example, for accessibility, we can just replace the classes
fileset with:
fileset id=classes dir=${hy.build}
or
present targetdir=${hy.accessibility.src.main.java} /
present targetdir=${hy.accessibility.src.main.java}
mapper type=regexp
from=^(.*?)(\$$[^/\\\.]*)?\.class$$
to=\1.java/
/present
/or
/fileset
Which basically says include files if they are also present in
the source directory - typically resource files - or if they are
.class files and have an obviously-named source file in the source
directory[0].
+1 to building the patternset on the fly rather than relying on file
lists being manually
kept up to date. I can't see any reason for keeping the patternset files.
This works for most modules. The present tags are duplicated for
modules with platform source directories.
However, it doesn't work very well for awt, beans, jndi, luni, and
security. Why? Because they have some source files defining two
classes. For instance, java.awt.ContextImpl defined in:
modules/awt/src/main/java/common/java/awt/Component.java
We could hardcode these special case - there are only a few. Or perhaps
we could split them in to distinct source files?
I'd go for splitting them out into separate files - hardcoding them
means that you're still
keeping a manual file list for those classes. Does anyone have an issue
with separating
these classes out?
I have some patches ready to make this change but I've not committed
anything.
Personally I think getting rid of the patternsets would be a good idea
since it reduces the coupling - although really the coupling is only
strictly necessary for luni and security.
It is important to note that even if we do something like this, leaving
the catch-all check in the clean target still helps stop problems - if
people forget to add the hardcoded special cases or if we split them
people add new source defining two classes in one file.
Agreed - keeping the clean target check helps us make sure that no one
breaks the
jar packaging in the future. As long as it completes the clean before
failing, that's
fine.
Regards,
Oliver
Regards,
Mark.
[0] The simpler 'mapper type=glob from=*.class to=*.java'
doesn't work because it misses inner classes.
2006/9/28, Mark Hindess [EMAIL PROTECTED]:
On 28 September 2006 at 11:07, Tim Ellison [EMAIL PROTECTED] wrot
e:
Sounds reasonable. The alternative is to not make clean fail, just
print the warning and tidy up the remainder. That may be too easy to
ignore though.
Yes. I considered that and had the same concern. Even if I wrote the
code to print the warning, I think I'd ignore it since it would scroll
too quickly off the top of my screen at the beginning of the build.
-Mark.
Regards,
Tim
Mark Hindess wrote:
Yesterday, while looking at something unrelated, I noticed that som
e
of the patternsets that are used to select the jars for the classli
b
modules were not up to date with the result that some classes would
be
missing from the resulting jars[0].
While it makes me slightly uneasy having a clean target that might
fail
,
it turns out that this is one place where it is quite easy to check
whether the patternsets are out of date. (Because if after the mod
ules
have cleaned classes in their patternsets there are still files lef
t
over then something is being create that isn't accounted for by the
patternsets.)
So the clean target will now fail with a message like (tested
by reverting yesterdays change to the sound patternset):
Built files still exist after module clean targets have run. Thi
s
probably means that one or more
Re: [classlib][build] Improvements to build system
I had a quick look at the Ant website - I can't see anything obvious in 1.7 that will make a big difference to us. Most of the information I found was concerned with antlibs. Anyone spotted anything we could use? Regards, Oliver Geir Magnusson Jr. wrote: Also, should we update to ant 1.7? Any new features that could help? I know it's still in beta, but still... since you are about to refactor, might be worth considering. geir On Sep 29, 2006, at 10:07 AM, Mark Hindess wrote: On 29 September 2006 at 13:14, Oliver Deakin [EMAIL PROTECTED] wrote: Hi all - Ive been away from the list this week, so sorry if Ive missed a few mails. Ill try and get back to them as soon as possible. In the meantime Ive been thinking about the classlib build system, and spotted a couple of things that Id like to fix/cleanup: 1) Although we can build a specific module with -Dbuild.module, currently we cannot just clean or rebuild a single module. I'd like to be able to run ant -Dbuild.module=luni rebuild and have it clean only the luni java and native binaries and rebuild them. Currently this call results in a total clean of all modules, and then all the native code being rebuilt, but only the java code for luni (so you end up with only luni.jar in lib/boot)! It would also be nice to be able to use the new rebuild-java and rebuild-native targets on a per module basis. 2) In the top level build script we have a number of public and private targets (the private ones are prefixed by a hyphen so that they cannot be run from the command line). However at the modular level the build scripts do not have this separation of external and internal targets, even though it is expected that developers may run these scripts directly. I would like to setup these scripts in the same way as the top level build.xml- with build, build-java, build-native etc. external targets and all others as internal and prefixed with a hyphen. I notice that Mark has done some cleanup of the build scripts under make recently, but I think the modular scripts still require tidying up. Does anyone have any objections to these? Any ideas of other relevant activities I can carry out while Im in there? The other things I was thinking about were: 1) Replacing antcall tasks with task dependencies 2) Moving stuff out of the make/build-java.xml file to a module where there is an obvious module that these files should be associated with. For instance, the ant for moving the ecj.jar really belongs with the tools module - since if you aren't building the tools module you would not need that jar. 3) Fixing the way we build the test support jar too frequently - i.e. the fact that we delete it before we test even if it hasn't changed. 4) Whether we can make make/build-native.xml derive some information from the modules - which ones need calling in which order - rather than hard coding this information 5) Modular building and testing with an hdk? As usual, I'm sure I'll find more work when I start looking more closely. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1 Geir Magnusson Jr. wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - 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]
[drlvm][JIRA] Can 1594 be committed?
Dear committers, please, commit HARMONY-1594 to fix gcc 4.* build for Jitrino and jet sources. Otherwise, it is a bit more complex to live on a linux with compiler version 4.0 and above. Regards, Pavel Pervov. Intel Middleware Products Division.
Re: [drlvm][JIRA] Can 1594 be committed?
I'll take a look. -Mark. On 3 October 2006 at 14:42, Pavel Pervov [EMAIL PROTECTED] wrote: Dear committers, please, commit HARMONY-1594 to fix gcc 4.* build for Jitrino and jet sources. Otherwise, it is a bit more complex to live on a linux with compiler version 4.0 and above. Regards, Pavel Pervov. Intel Middleware Products Division. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][JIRA] Can 1594 be committed?
Ok. I'll look. It must be the case that the whole thing can compile w/ GCC 4.*, not just Jitrino and jet, including classlib. This isssue, the version of GCC, is one of the things that snags people. Are there any backwards compat issues if we make it all 4.x compatible? geir Pavel Pervov wrote: Dear committers, please, commit HARMONY-1594 to fix gcc 4.* build for Jitrino and jet sources. Otherwise, it is a bit more complex to live on a linux with compiler version 4.0 and above. Regards, Pavel Pervov. Intel Middleware Products Division. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][JIRA] Can 1594 be committed?
After posting, I noticed that Geir has pick up this JIRA so, while I'll still take a look, I wont steal the JIRA or commit any changes. Geir feel free to re-assign it if you decide you don't want it. ;-) -Mark. On 3 October 2006 at 12:02, Mark Hindess [EMAIL PROTECTED] wrote: I'll take a look. -Mark. On 3 October 2006 at 14:42, Pavel Pervov [EMAIL PROTECTED] wrote: Dear committers, please, commit HARMONY-1594 to fix gcc 4.* build for Jitrino and jet sources. Otherwise, it is a bit more complex to live on a linux with compiler version 4.0 and above. Regards, Pavel Pervov. Intel Middleware Products Division. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][kernel exception handling] several issues
Serguei Zapreyev wrote: Dear committers, I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the suggested patches. I was looking at 1573 last night, but was too tired to follow the instructions :) (Take the third attachment, combine with the first, to produce the second test that can be used on any Thursday in an odd-numbered month. Carry the 7, cross out each second vowel, and ...) Yes, I'll look at all three today. the last three were hidden - you didn't assign to the DRLVM component, so I missed them yesterday. So, to avoid redoubling efforts or superposition of commits because of delay could somebody take them under a control to estimate and apply if it is necessary? All the more, the 1650 and 1573 issues seem to be able to upset somehow the execution stability of a big application. Does that mean the patches fix them, or make big apps less stable? geir Great thanks in advance, Serguei - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][jit] Internal testing framework for Jitrino.OPT compiler
yes, I saw - thanks for that. I was trying to get 1531 to work yesterday, and I seemed to do something wrong. Can you look at 1531 and comment? geir Ivan Kollegov wrote: Hi, I opened new JIRA http://issues.apache.org/jira/browse/HARMONY-1586 and attach my contribution to keep things clearer, could you just open a fresh JIRA, attach your contribition, and then link back to 1531? It makes it much easier to track who has given what... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] removing \t from sources
I've committed the reformatted code in r452415.
Now you can feel calm again :-)
The other modules are being cleaned-up piece by piece.
Regards,
Tim
Alexei Zakharov wrote:
I see. This IMHO is another argument why \t is bad. My script will not
be able to handle this, it just replaces one string pattern with
another. So such cases should be handled manually or with the code
formatter. However, the drawback of the code formatter is that it
removes the author's personality from the code.
But IMHO mixing spaces with tabs in the single unit of indentation is
even worse than just using tabs. Normally people use either tabs or
spaces. I suppose that mixes appear when the original source with tabs
is being edited with IDE configured to use spaces. I haven't seen many
of such cases in HY code, at least in the modules I worked with.
With best regards,
2006/10/2, Alexey Petrenko [EMAIL PROTECTED]:
I mean that {space, space, tab} will be converted to the same
number of spaces as simple tab by the most of editors.
SY, Alexey
2006/10/2, Alexei Zakharov [EMAIL PROTECTED]:
What do you mean? Convert \t to something? If so please see the
new fully customized version of my mega-script :-)
The usage pattern in your case will be:
ant -f tabs2spaces_v2.xml -Dsrc.dir=dir with sources -Dpattern= \t
Regards,
2006/10/2, Alexey Petrenko [EMAIL PROTECTED]:
Does it work with the sequences like {space, space, tab} etc?
2006/10/2, Alexei Zakharov [EMAIL PROTECTED]:
Hi all,
I noticed that the tab character (0x09) is still widely used in our
classlib source code. At least in tests. From my recent experience
this leads to broken indentation. I mean the situation when
patch with
spaces is applied to the source there tab character is used for
indentation. Someone knows that according to Sun code
conventions the
tab should be exactly 8 spaces. The other person knows that exactly
four spaces should be used as the unit of indentation [1]. As a
result
we have all methods indented with the single tab character and the
patched methods indented with 4 spaces. And if your IDE is
configured
to display tabs as 8 spaces you will see broken indentation. Or
vice
versa.
I have created small ANT script - see HARMONY-1660 [2]. This script
converts all tabs to spaces in all found sources under the given
directory recursively. I will be grateful if someone runs this
script
(tab - 4 spaces) at least for beans tests (I currently working
with)
and integrates the results. It is really painful to deal with this
broken alignment every day. And it is too boring (and IMHO
silly) to
convert it file by file and send patches for each case.
[1]
http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html#262
[3] http://issues.apache.org/jira/browse/HARMONY-1660
Thanks,
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][kernel exception handling] several issues
2006/10/3, Serguei Zapreyev [EMAIL PROTECTED]: Dear committers, I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the suggested patches. So, to avoid redoubling efforts or superposition of commits because of delay could somebody take them under a control to estimate and apply if it is necessary? All the more, the 1650 and 1573 issues seem to be able to upset somehow the execution stability of a big application. Serguei, the HARMONY-1573 is mostly about j.l.Process impl. I believe we shoud consider reusing org\apache\harmony\luni\internal\process\SystemProcess.java available in luni rather than fixing alternative impl in DRLVM. What do you think? -- Regards, Alexey Great thanks in advance, Serguei - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] AWT/Swing deps
Mikhail Loenko wrote: For the short term it sounds good. For the long term the deps would better be built on the fly IMHO Why? We don't build other deps on the fly. By using a binary distro, we all have the same, predictable thing. And seems like some of this code hasn't changed since last century :) geir Thanks, Mikhail 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: Ok, that was fun. Not. We need to finish making this easier for developers to build by having pre-built binaries somewhere. To start, I'm going to put a well-documented tree that contains the stuff needed for /png, /lcms and /jpg on my personal account and note it. If we can then make that part of fetch-depends, all will be well. Comments? Other ideas? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][kernel exception handling] several issues
On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Serguei Zapreyev wrote: Dear committers, I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the suggested patches. I was looking at 1573 last night, but was too tired to follow the instructions :) (Take the third attachment, combine with the first, to produce the second test that can be used on any Thursday in an odd-numbered month. Carry the 7, cross out each second vowel, and ...) Sorry. I'll try to avoid such cases in the future. Yes, I'll look at all three today. the last three were hidden - you didn't assign to the DRLVM component, so I missed them yesterday. So, to avoid redoubling efforts or superposition of commits because of delay could somebody take them under a control to estimate and apply if it is necessary? All the more, the 1650 and 1573 issues seem to be able to upset somehow the execution stability of a big application. Does that mean the patches fix them, or make big apps less stable? Yes, of course, I meant the patches fix them. Thanks, Serguei geir Great thanks in advance, Serguei - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Serguei
Re: [drlvm][JIRA] Can 1594 be committed?
Congratulations! You're the proud owner of 1594! Please make sure things still compile w/ 3.4 :) geir Mark Hindess wrote: After posting, I noticed that Geir has pick up this JIRA so, while I'll still take a look, I wont steal the JIRA or commit any changes. Geir feel free to re-assign it if you decide you don't want it. ;-) -Mark. On 3 October 2006 at 12:02, Mark Hindess [EMAIL PROTECTED] wrote: I'll take a look. -Mark. On 3 October 2006 at 14:42, Pavel Pervov [EMAIL PROTECTED] wrote: Dear committers, please, commit HARMONY-1594 to fix gcc 4.* build for Jitrino and jet sources. Otherwise, it is a bit more complex to live on a linux with compiler version 4.0 and above. Regards, Pavel Pervov. Intel Middleware Products Division. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] AWT/Swing deps
I agree that downloading of prebuilt libraries is better choice. So we got only two options: 1. Find prebuilt libraries somewhere. 2. Build them ourselves and store them somewhere. I've tried to find prebuilt libraries but I was not successful. So it seems that the only option is to build them ourselves. And the only question is: Where to store them? Any ideas? SY, Alexey 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Mikhail Loenko wrote: For the short term it sounds good. For the long term the deps would better be built on the fly IMHO Why? We don't build other deps on the fly. By using a binary distro, we all have the same, predictable thing. And seems like some of this code hasn't changed since last century :) geir Thanks, Mikhail 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: Ok, that was fun. Not. We need to finish making this easier for developers to build by having pre-built binaries somewhere. To start, I'm going to put a well-documented tree that contains the stuff needed for /png, /lcms and /jpg on my personal account and note it. If we can then make that part of fetch-depends, all will be well. Comments? Other ideas? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
On 10/3/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Andrey, Just to be clear I agree with you it is more convenient if jthread_create takes JNIEnv instead of JavaVM. It reflects that current thread has been attached already. Do you think it makes sense to get rid of JNIEnv and use jthread_get_JNI_env in that case? The jthread_* layer is designed like if it were a regular JNI application which is meant to be called from the Java code, hence every function on that layer receives JNIenv. We can probably get rid of the JNEnv parameter for jthread_* functions, assuming that TM can always extract JNIenv for the current thread with jthread_get_JNI_env(). My only concern would be the performance - once the JNIenv is already known for the native part of the kernel classes impl, it must be cheaper to pass JNIEnv to TM as an extra parameter rather than extract it from the TLS again. Other than that, I see no strong advantages in keeping JNIEnv parameter. Regarding jthread_attach. I still didn't get your point Clarify it please if you think jhread_attach should be modified. Sorry for being not clear: I think for jthread_attach, we have two options: 1) Make JNIEnv input parameter - it must be new JNIEnv that VM pre-allocates for the new Java thread. jthread_attach would just associate it with the current thread. 2) Obtain JNIEnv via vm_attach() callback. In this case, if vm_attach() callback implementation needs to know for which JavaVM new JNIenv has to be allocated, then we'll need to add JavaVM as input parameter for jthread_attach(). I think both options should be fine, (1) would probably keep TM interface a bit lighter, though (2) may look more closer to the JNI invocation API idea. So I think adding JavaVM specifically for jthread_attach may make sense given the explanation you provided earlier. The concern I would have regarding the proposed jthread_attach implementation is a call to vm_create_jthread() - this call introduces an extra dependency of TM on vmcore that I'd prefer to be avoided. In the original version, jthread_attach() was taking jthread argument of the already prepared j.l.Thread. I understand your concern. Unfortunately I don't see what we can do here. Let me explain. In the beginning you have an unattached native thread. To be able to call java code (which is required for constructing j.l.Thread instance) the thread should be attached first. To be specific it should be attached to VM by calling vm_attach which will return a valid JNIEnv It is valid to use JNI from that moment. Obtained JNIEnv can be used to execute java code and create j.l.Thread instance. Since we do vm_attach in jthread_attach we need to do vm_create_jthread inside jthread_atach as well. Of course it can be an alternative to do vm_attach and vm_create_jthread outside of TM right before jthread_attach. Sure it will reduce one dependence between VM and TM. But it seems like artificial action for me just because of dependency Do you think it makes sense to replace a single jthread parameter with a variety of stuff (like thread group, name)? It seems the only purpose of at these args is to be passed back to VM for vm_jthread_create(). I would suggest to change this and try doing either of: 1) Make signature of jthread_attach with 3 args, JavaVM, jthread and the daemon. Why do you want to pass daemon to TM but thread's name and group. Just because current TM doesn't need such information? What if it is required to get thread name later? Say by introducing jthread_get_name... What will you do in that case? Let me guess you will call j.l.Thread.getName. Right. Ok! In that case I see no problems to call j.l.Thread.isDaemon. Do you agree? So it doesn't seems to be a good design to pass only part of the information to jthread_atach. Lets look at the signature of AttachCurrentThread. It takes exactly these three parameters (daemon, name, group) passed as a structure. I was thinking about having exactly the same structure as third parameter of jthread_attach but it occured to be more convinient to pass them seperatly. Although I don't see strong reasons against having a structure a third parameter. 2) Move the implementation of vm_create_jtrhead() to thread_java_basic.c - could it be written in pure JNI without using internal VM API like class_alloc_new_object()? Yes, this can be done but it doesn't fix the problem. You still need to know about internal constructor of j.l.Thread Thanks Evgueni Thanks, Andrey. Thank you Evgueni On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/29/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 9/29/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Artem, Thank you for your feedback find my inlined. On 9/29/06, Artem Aliev [EMAIL PROTECTED] wrote: Evgueni, I got most of your changes, but still disagree with all hythread/jthread interface
[drlvm] HARMONY-1607 : where is the right place to put it?
I haven't used MSVC in about 6 years, so where is the right place to put the files from 1607 so that they are easily used by an MSVC user? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] AWT/Swing deps
2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Petrenko wrote: I agree that downloading of prebuilt libraries is better choice. So we got only two options: 1. Find prebuilt libraries somewhere. 2. Build them ourselves and store them somewhere. I've tried to find prebuilt libraries but I was not successful. So it seems that the only option is to build them ourselves. And the only question is: Where to store them? Any ideas? As I threatened in my original post, I put them in http://people.apache.org/~geirm/harmony/ I could move them to the snapshot directory too, but I figure no one is going to assume that we are formally distributing them if they are in a personal directory. Your personal directory looks ok for me. You can get prebuilt libraries from the HARMONY-1297 or build them yourself... SY, Alexey http://issues.apache.org/jira/browse/HARMONY-1297 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Mikhail Loenko wrote: For the short term it sounds good. For the long term the deps would better be built on the fly IMHO Why? We don't build other deps on the fly. By using a binary distro, we all have the same, predictable thing. And seems like some of this code hasn't changed since last century :) geir Thanks, Mikhail 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: Ok, that was fun. Not. We need to finish making this easier for developers to build by having pre-built binaries somewhere. To start, I'm going to put a well-documented tree that contains the stuff needed for /png, /lcms and /jpg on my personal account and note it. If we can then make that part of fetch-depends, all will be well. Comments? Other ideas? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][kernel exception handling] several issues
On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/10/3, Serguei Zapreyev [EMAIL PROTECTED]: Dear committers, I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the suggested patches. So, to avoid redoubling efforts or superposition of commits because of delay could somebody take them under a control to estimate and apply if it is necessary? All the more, the 1650 and 1573 issues seem to be able to upset somehow the execution stability of a big application. Serguei, the HARMONY-1573 is mostly about j.l.Process impl. I believe we shoud consider reusing org\apache\harmony\luni\internal\process\SystemProcess.java available in luni rather than fixing alternative impl in DRLVM. What do you think? Alexey, I guess few items should be took into consideration before doing some conclusions here. First, DRLVM's implementation of Runtime has been checked during a lot of testing milestones. Second, its code is well known for DRLVM developers, so it's easy to maintain it in this hot time. Third, we have no good test set (like TCK) to compare the discussed impls. Forth, we have no methods to estimate performance of impls. ... So, I think your suggestion isn't too actual just now and may be considered some later. There is no need to upset the current stability just now. I think the attached patches should be applayed in the nearest time to improve the used code. All the more, this patch combines some issues apart from the Process. Thanks, Serguei -- Regards, Alexey Great thanks in advance, Serguei - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Serguei
Re: [classlib] AWT/Swing deps
2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Petrenko wrote: I agree that downloading of prebuilt libraries is better choice. So we got only two options: 1. Find prebuilt libraries somewhere. 2. Build them ourselves and store them somewhere. I've tried to find prebuilt libraries but I was not successful. So it seems that the only option is to build them ourselves. And the only question is: Where to store them? Any ideas? As I threatened in my original post, I put them in http://people.apache.org/~geirm/harmony/ I could move them to the snapshot directory too, but I figure no one is going to assume that we are formally distributing them if they are in a personal directory. Interesting statement. IANAL, but I'd assume we are Thanks, Mikhail geir SY, Alexey 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Mikhail Loenko wrote: For the short term it sounds good. For the long term the deps would better be built on the fly IMHO Why? We don't build other deps on the fly. By using a binary distro, we all have the same, predictable thing. And seems like some of this code hasn't changed since last century :) geir Thanks, Mikhail 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: Ok, that was fun. Not. We need to finish making this easier for developers to build by having pre-built binaries somewhere. To start, I'm going to put a well-documented tree that contains the stuff needed for /png, /lcms and /jpg on my personal account and note it. If we can then make that part of fetch-depends, all will be well. Comments? Other ideas? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
Alexey, Thanks for pointing to that test - I created my tests using this approach. Please see HARMONY-1671 for tests. If you think that some more options should be covered - please let me know - I'll try to make tests for them. On 9/29/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Anton, Many thanks for volunteering. You might be interested to look at org.apache.harmony.archive.tests.java.util.jar.JarOutputStreamTest in archive module - it gives some basic coverage in this area. I know about it because just recently fixed it, see HARMONY-1622. -- Alexey 2006/9/29, Anton Luht [EMAIL PROTECTED]: Hello, I'd like to volunteer. Just an idea: I'm going to create a number of .class and .jar files and test various combinations of launching using SupportExec On 9/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: We desperately need tests for this. Anyone want to volunteer, to even make simple ones? We can stuff into the smoke or other frameworks... geir Pavel Pervov wrote: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] AWT/Swing deps
Alexey Petrenko wrote: 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Petrenko wrote: I agree that downloading of prebuilt libraries is better choice. So we got only two options: 1. Find prebuilt libraries somewhere. 2. Build them ourselves and store them somewhere. I've tried to find prebuilt libraries but I was not successful. So it seems that the only option is to build them ourselves. And the only question is: Where to store them? Any ideas? As I threatened in my original post, I put them in http://people.apache.org/~geirm/harmony/ I could move them to the snapshot directory too, but I figure no one is going to assume that we are formally distributing them if they are in a personal directory. Your personal directory looks ok for me. You can get prebuilt libraries from the HARMONY-1297 or build them yourself... They are already there. I built them myself. That gives me an idea. Can I stuff them in JIRA and and just have the build fetch from there? The URL should be stable. geir SY, Alexey http://issues.apache.org/jira/browse/HARMONY-1297 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Mikhail Loenko wrote: For the short term it sounds good. For the long term the deps would better be built on the fly IMHO Why? We don't build other deps on the fly. By using a binary distro, we all have the same, predictable thing. And seems like some of this code hasn't changed since last century :) geir Thanks, Mikhail 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: Ok, that was fun. Not. We need to finish making this easier for developers to build by having pre-built binaries somewhere. To start, I'm going to put a well-documented tree that contains the stuff needed for /png, /lcms and /jpg on my personal account and note it. If we can then make that part of fetch-depends, all will be well. Comments? Other ideas? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Egor, HARMONY-1673 is filed. I've tried both -Xem:opt -Xem:jet. Regards, 03 Oct 2006 00:06:16 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote: The same result with the -Xem:opt. Could you file a JIRA for that, please? With steps to reproduce. Please, also check with -Xem:jet. Thanks for pointing out failures like that. The exact command in my environment was (WinXP SP2): == C:\mydoc\projects\tests\beans2echo %JAVA_HOME% C:\Java\harmony-hdk-r450941\jdk\jre C:\mydoc\projects\tests\beans2%JAVA_HOME%\bin\java -Xbootclasspath/p:.\build\classes;.\build\tests;C:\Java\harmony\enhanced\classlib\trunk\depends\jars\junit_3.8.2\junit.jar -Xem:opt junit.textui.TestRunner org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest ... An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 ExceptionCode=c005 ExceptionAddress=0052A340 ContextFlags=0001003f Handler1=00401010 Handler2=11105CE0 InaccessibleAddress= EDI= ESI= EAX=0013F1AC EBX= ECX=007129FC EDX= EIP=0052A340 ESP=0013F17C EBP= Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll Module_base_address=0051 Offset_in_DLL=0001a340 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. == Regards, 02 Oct 2006 20:14:11 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote: Agree. In case somebody is interested: org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest (from bootclasspath), harmony-hdk-r450941, WinXP. Is that reproducible on Linux? how does it run on pure OPT (-Xem:opt), JET? Crash info: == [junit] An unhandled error (4) has occurred. [junit] HyGeneric_Signal_Number=0004 [junit] ExceptionCode=c005 [junit] ExceptionAddress=0052A340 [junit] ContextFlags=0001003f [junit] Handler1=00401010 [junit] Handler2=11105CE0 [junit] InaccessibleAddress= [junit] EDI= [junit] ESI= [junit] EAX=0013D69C [junit] EBX= [junit] ECX=007129FC [junit] EDX= [junit] EIP=0052A340 [junit] ESP=0013D66C [junit] EBP= [junit] Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll [junit] Module_base_address=0051 [junit] Offset_in_DLL=0001a340 [junit] This application has requested the Runtime to terminate it in an unusual way. [junit] Please contact the application's support team for more information. [junit] Test org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest FAILED == Thanks, 2006/10/2, Vladimir Ivanov [EMAIL PROTECTED]: On 10/2/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Juist my two cents. Some test even from such a high-level module as beans fail if they run from bootclasspath (BeansTest for example). Moreover, they crash DRLVM :) Seems, it is should be evaluated by VM peoples. The vm crash is not good reaction for test failure. thanks, Vladimir BTW, personally I use custom-made build file to develop with HDK and single-module checkout. -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] AWT/Swing deps
2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Petrenko wrote: 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Petrenko wrote: I agree that downloading of prebuilt libraries is better choice. So we got only two options: 1. Find prebuilt libraries somewhere. 2. Build them ourselves and store them somewhere. I've tried to find prebuilt libraries but I was not successful. So it seems that the only option is to build them ourselves. And the only question is: Where to store them? Any ideas? As I threatened in my original post, I put them in http://people.apache.org/~geirm/harmony/ I could move them to the snapshot directory too, but I figure no one is going to assume that we are formally distributing them if they are in a personal directory. Your personal directory looks ok for me. You can get prebuilt libraries from the HARMONY-1297 or build them yourself... They are already there. I built them myself. That gives me an idea. Can I stuff them in JIRA and and just have the build fetch from there? The URL should be stable. There are in JIRA already with the corresponding patch to the build... http://issues.apache.org/jira/browse/HARMONY-1297 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Mikhail Loenko wrote: For the short term it sounds good. For the long term the deps would better be built on the fly IMHO Why? We don't build other deps on the fly. By using a binary distro, we all have the same, predictable thing. And seems like some of this code hasn't changed since last century :) geir Thanks, Mikhail 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: Ok, that was fun. Not. We need to finish making this easier for developers to build by having pre-built binaries somewhere. To start, I'm going to put a well-documented tree that contains the stuff needed for /png, /lcms and /jpg on my personal account and note it. If we can then make that part of fetch-depends, all will be well. Comments? Other ideas? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] AWT/Swing deps
On 3 October 2006 at 7:49, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Alexey Petrenko wrote: I agree that downloading of prebuilt libraries is better choice. So we got only two options: 1. Find prebuilt libraries somewhere. 2. Build them ourselves and store them somewhere. I've tried to find prebuilt libraries but I was not successful. So it seems that the only option is to build them ourselves. And the only question is: Where to store them? Any ideas? As I threatened in my original post, I put them in http://people.apache.org/~geirm/harmony/ I could move them to the snapshot directory too, but I figure no one is going to assume that we are formally distributing them if they are in a personal directory. Agreed. In a personal directory is a bit better. But if we point 'ant fetch-depends' at it on an apache server even in a personal directory, that seems be a bit more like distributing them formally to me. BTW, I made changes to move the unix fetch-awt-depends.sh[0] to the ant fetch-depends target in anticipation of doing some downloads to fetch them for windows. If you want me to add the windows downloads, where ever they end up, just ask. I've left a warning in the now obsolete script. I'll remove the script next week, so please test the new ant code - which is currently protected by with.awt.swing property. I'll remove this property completely[0] when we've added the windows downloads to 'ant fetch-depends'. -Mark. [0] Though we need to think about headless/non-headless tests. 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Mikhail Loenko wrote: For the short term it sounds good. For the long term the deps would better be built on the fly IMHO Why? We don't build other deps on the fly. By using a binary distro, we all have the same, predictable thing. And seems like some of this code hasn't changed since last century :) geir Thanks, Mikhail 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: Ok, that was fun. Not. We need to finish making this easier for developers to build by having pre-built binaries somewhere. To start, I'm going to put a well-documented tree that contains the stuff needed for /png, /lcms and /jpg on my personal account and note it. If we can then make that part of fetch-depends, all will be well. Comments? Other ideas? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][kernel exception handling] several issues
I tend to agree. I think that it's a good idea to consider for the future, but right now, if the fixes help stabilize, great. I think that stabilization is key right now. geir Serguei Zapreyev wrote: On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/10/3, Serguei Zapreyev [EMAIL PROTECTED]: Dear committers, I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the suggested patches. So, to avoid redoubling efforts or superposition of commits because of delay could somebody take them under a control to estimate and apply if it is necessary? All the more, the 1650 and 1573 issues seem to be able to upset somehow the execution stability of a big application. Serguei, the HARMONY-1573 is mostly about j.l.Process impl. I believe we shoud consider reusing org\apache\harmony\luni\internal\process\SystemProcess.java available in luni rather than fixing alternative impl in DRLVM. What do you think? Alexey, I guess few items should be took into consideration before doing some conclusions here. First, DRLVM's implementation of Runtime has been checked during a lot of testing milestones. Second, its code is well known for DRLVM developers, so it's easy to maintain it in this hot time. Third, we have no good test set (like TCK) to compare the discussed impls. Forth, we have no methods to estimate performance of impls. ... So, I think your suggestion isn't too actual just now and may be considered some later. There is no need to upset the current stability just now. I think the attached patches should be applayed in the nearest time to improve the used code. All the more, this patch combines some issues apart from the Process. Thanks, Serguei -- Regards, Alexey Great thanks in advance, Serguei - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] AWT/Swing deps
On 3 October 2006 at 19:16, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Petrenko wrote: I agree that downloading of prebuilt libraries is better choice. So we got only two options: 1. Find prebuilt libraries somewhere. 2. Build them ourselves and store them somewhere. I've tried to find prebuilt libraries but I was not successful. So it seems that the only option is to build them ourselves. And the only question is: Where to store them? Any ideas? As I threatened in my original post, I put them in http://people.apache.org/~geirm/harmony/ I could move them to the snapshot directory too, but I figure no one is going to assume that we are formally distributing them if they are in a personal directory. Interesting statement. IANAL, but I'd assume we are Certainly we are in that sense but I don't think that is the issue Geir was trying to address. (This certainly means we needed to meet the license requirements for distribution - though IIRC they are fairly minimal for these particular packages.) The issue is whether the Apache Software Foundation is considered to be formally responsible or if it is just something Geir is doing personally. -Mark. 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Mikhail Loenko wrote: For the short term it sounds good. For the long term the deps would better be built on the fly IMHO Why? We don't build other deps on the fly. By using a binary distro, we all have the same, predictable thing. And seems like some of this code hasn't changed since last century :) geir Thanks, Mikhail 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: Ok, that was fun. Not. We need to finish making this easier for developers to build by having pre-built binaries somewhere. To start, I'm going to put a well-documented tree that contains the stuff needed for /png, /lcms and /jpg on my personal account and note it. If we can then make that part of fetch-depends, all will be well. Comments? Other ideas? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] g - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] AWT/Swing deps
Mikhail Loenko wrote: 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Petrenko wrote: I agree that downloading of prebuilt libraries is better choice. So we got only two options: 1. Find prebuilt libraries somewhere. 2. Build them ourselves and store them somewhere. I've tried to find prebuilt libraries but I was not successful. So it seems that the only option is to build them ourselves. And the only question is: Where to store them? Any ideas? As I threatened in my original post, I put them in http://people.apache.org/~geirm/harmony/ I could move them to the snapshot directory too, but I figure no one is going to assume that we are formally distributing them if they are in a personal directory. Interesting statement. IANAL, but I'd assume we are The key is the definition of distribute. The project (and therefore the ASF) has not decided to distribute the software. It's being made available for use by our developers in our project tree. (It's structured as a drop-in for the right place in classlib/depends) This is very different from us creating a release and voting on it. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
nice work Anton Luht wrote: Alexey, Thanks for pointing to that test - I created my tests using this approach. Please see HARMONY-1671 for tests. If you think that some more options should be covered - please let me know - I'll try to make tests for them. On 9/29/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Anton, Many thanks for volunteering. You might be interested to look at org.apache.harmony.archive.tests.java.util.jar.JarOutputStreamTest in archive module - it gives some basic coverage in this area. I know about it because just recently fixed it, see HARMONY-1622. -- Alexey 2006/9/29, Anton Luht [EMAIL PROTECTED]: Hello, I'd like to volunteer. Just an idea: I'm going to create a number of .class and .jar files and test various combinations of launching using SupportExec On 9/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: We desperately need tests for this. Anyone want to volunteer, to even make simple ones? We can stuff into the smoke or other frameworks... geir Pavel Pervov wrote: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] AWT/Swing deps
Mark Hindess wrote: On 3 October 2006 at 19:16, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Petrenko wrote: I agree that downloading of prebuilt libraries is better choice. So we got only two options: 1. Find prebuilt libraries somewhere. 2. Build them ourselves and store them somewhere. I've tried to find prebuilt libraries but I was not successful. So it seems that the only option is to build them ourselves. And the only question is: Where to store them? Any ideas? As I threatened in my original post, I put them in http://people.apache.org/~geirm/harmony/ I could move them to the snapshot directory too, but I figure no one is going to assume that we are formally distributing them if they are in a personal directory. Interesting statement. IANAL, but I'd assume we are Certainly we are in that sense but I don't think that is the issue Geir was trying to address. (This certainly means we needed to meet the license requirements for distribution - though IIRC they are fairly minimal for these particular packages.) The issue is whether the Apache Software Foundation is considered to be formally responsible or if it is just something Geir is doing personally. Well, if the project build is tied to it, it should be considered something we are doing as a project *for ourselves*. In the same way that we stuff things into SVN for our use, we aren't claiming to be a distributor of those things. Sure, it's available to evereyone, but that's because of the open way we work. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1 (with apologies for taking so long to complete the review) Tim Geir Magnusson Jr. wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. 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: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
I have one more question about coverage: should it be the part of the BT infrastructure or integrated to the current classlib build system? From my point of view it should be a part of BTI while it is rarely used functionality and no needs to waste regular build by this data (it does not required to duplicate code while coverage depends on regular build and we should describe it in the readme.txt). By the way, we (at least I :) ) going to have some different scripts in the BI modules: - code coverage (issue 564); - cruise control (issue 995); - japi script (In progress); - script to simple download and run tests against HDK. Seems, that it will OK to have some wrapper for these scripts and one set of properties. Something like: 'ant cc' - to run cruise control, 'ant coverage' - to calculate coverage etc. If no objections I will try to implement it after 'run japi' script. Thanks, Vladimir On 10/2/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: The coverage information was updated on the wiki to current state (issue 564 also was updated): http://wiki.apache.org/harmony/Coverage_information thanks, Vladimir
Re: [classlib] AWT/Swing deps
On 3 October 2006 at 9:33, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Mark Hindess wrote: On 3 October 2006 at 19:16, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Petrenko wrote: I agree that downloading of prebuilt libraries is better choice. So we got only two options: 1. Find prebuilt libraries somewhere. 2. Build them ourselves and store them somewhere. I've tried to find prebuilt libraries but I was not successful. So it seems that the only option is to build them ourselves. And the only question is: Where to store them? Any ideas? As I threatened in my original post, I put them in http://people.apache.org/~geirm/harmony/ I could move them to the snapshot directory too, but I figure no one is going to assume that we are formally distributing them if they are in a personal directory. Interesting statement. IANAL, but I'd assume we are Certainly we are in that sense but I don't think that is the issue Geir was trying to address. (This certainly means we needed to meet the license requirements for distribution - though IIRC they are fairly minimal for these particular packages.) The issue is whether the Apache Software Foundation is considered to be formally responsible or if it is just something Geir is doing personally. Well, if the project build is tied to it, it should be considered something we are doing as a project *for ourselves*. In the same way that we stuff things into SVN for our use, we aren't claiming to be a distributor of those things. Sure, it's available to evereyone, but that's because of the open way we work. That seems a reasonable argument. I'll start looking at the fetch-depends tweaks. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
On 3 October 2006 at 21:08, Vladimir Ivanov [EMAIL PROTECTED] wrote: I have one more question about coverage: should it be the part of the BT infrastructure or integrated to the current classlib build system? From my point of view it should be a part of BTI while it is rarely used functionality and no needs to waste regular build by this data (it does not required to duplicate code while coverage depends on regular build and we should describe it in the readme.txt). By the way, we (at least I :) ) going to have some different scripts in the BI modules: - code coverage (issue 564); - cruise control (issue 995); - japi script (In progress); - script to simple download and run tests against HDK. Seems, that it will OK to have some wrapper for these scripts and one set of properties. Something like: 'ant cc' - to run cruise control, 'ant coverage' - to calculate coverage etc. If no objections I will try to implement it after 'run japi' script. Regarding the 'run japi' script what are you planning to do here? The IBM Build/test builds also run japi (on linux only since we get enough information using one platform and linux is easier). We might as well share ant code. Also note that to get anything like reasonable data you need to be running the latest japi from CVS. Regards, Mark. Thanks, Vladimir On 10/2/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: The coverage information was updated on the wiki to current state (issue 564 also was updated): http://wiki.apache.org/harmony/Coverage_information thanks, Vladimir --=_Part_60236_8031756.1159884501259-- - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][kernel exception handling] several issues
Sure, this can wait - say, until classlib tests 100% pass on DRLVM, - just to let current pace of major changes slow down. Other than that, I see no compelling reasons to maintain duplicate impl in DRLVM. And you bet the reference impl in classlib is mature enough to not affect VM stability ;) -- Alexey 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: I tend to agree. I think that it's a good idea to consider for the future, but right now, if the fixes help stabilize, great. I think that stabilization is key right now. geir Serguei Zapreyev wrote: On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/10/3, Serguei Zapreyev [EMAIL PROTECTED]: Dear committers, I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the suggested patches. So, to avoid redoubling efforts or superposition of commits because of delay could somebody take them under a control to estimate and apply if it is necessary? All the more, the 1650 and 1573 issues seem to be able to upset somehow the execution stability of a big application. Serguei, the HARMONY-1573 is mostly about j.l.Process impl. I believe we shoud consider reusing org\apache\harmony\luni\internal\process\SystemProcess.java available in luni rather than fixing alternative impl in DRLVM. What do you think? Alexey, I guess few items should be took into consideration before doing some conclusions here. First, DRLVM's implementation of Runtime has been checked during a lot of testing milestones. Second, its code is well known for DRLVM developers, so it's easy to maintain it in this hot time. Third, we have no good test set (like TCK) to compare the discussed impls. Forth, we have no methods to estimate performance of impls. ... So, I think your suggestion isn't too actual just now and may be considered some later. There is no need to upset the current stability just now. I think the attached patches should be applayed in the nearest time to improve the used code. All the more, this patch combines some issues apart from the Process. Thanks, Serguei -- Regards, Alexey Great thanks in advance, Serguei - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
On 10/3/06, Mark Hindess [EMAIL PROTECTED] wrote: Regarding the 'run japi' script what are you planning to do here? The IBM Build/test builds also run japi (on linux only since we get enough information using one platform and linux is easier). We might as well share ant code. Also note that to get anything like reasonable data you need to be running the latest japi from CVS. Please, share the code (as part of BTI) :) It will be enough I think thanks, Vladimir Regards, Mark. Thanks, Vladimir On 10/2/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: The coverage information was updated on the wiki to current state (issue 564 also was updated): http://wiki.apache.org/harmony/Coverage_information thanks, Vladimir --=_Part_60236_8031756.1159884501259-- - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[patch][drlvm] fix junit.jar download
Geir,
it looks like the commit
[r452245] HARMONY-698 This should be equivalent to what HARMONY-698
broken the downloading of junit.jar (which we used to take from Eclipse
distribution).
The below patch adds junit.jar as a separate download from ibiblio jar
repository.
--- 8 ---
added downloading of junit.jar
diff --git build/make/lnx.properties build/make/lnx.properties
index c4f6c56..1404b5b 100644
--- build/make/lnx.properties
+++ build/make/lnx.properties
@@ -57,6 +57,10 @@ # APR-iconv, version 1.1.1 or above
# http://apr.apache.org/download.cgi
remote.APRICONV.archive=http://apache.reverse.net/pub/apache/apr/apr-iconv-1.1.1.tar.gz
+# JUnit, version 3.8.1 or above
+remote.JUNIT.archive=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
+remote.JUNIT.archive.type=asis
+
# LOG4CXX, svn revision 416779
# http://logging.apache.org/site/cvs-repositories.html
remote.LOG4CXX.archive=-r 416779
http://svn.apache.org/repos/asf/logging/log4cxx/trunk
diff --git build/make/setup.xml build/make/setup.xml
index e570ae0..be28782 100644
--- build/make/setup.xml
+++ build/make/setup.xml
@@ -105,6 +105,7 @@ Version: $Revision: 1.5.2.33 $
property name=CLASSLIB.check.file value=native-src/README.txt /
property name=XALAN.check.file value=xalan.jar /
property name=VM.check.file value=vmcore/src/init/vm_main.cpp /
+ property name=JUNIT.check.file value=junit-3.8.1.jar /
property name=ANTLR.check.file value=antlr-2.7.5.jar /
property name=PATCHES.check.file value=README.txt /
/target
@@ -148,6 +149,12 @@ Version: $Revision: 1.5.2.33 $
target name=copy.nessessary.jars
+copy tofile=tmp/junit.jar
+fileset dir=${build.precopied.dir}/common/JUNIT
+include name=junit*.jar /
+/fileset
+/copy
+
propertyregex property=build.XALAN.path input=${if.XALAN.exist}
regexp=(.*)/${XALAN.check.f
ile} select=\1 /
copy file=${build.XALAN.path}/xalan.jar todir=tmp /
@@ -176,7 +183,7 @@ Version: $Revision: 1.5.2.33 $
target name=setup.resources depends=plugin.antcontrib
-property name=common.resources
value=LOG4CXX,CPPTASKS,XALAN,VM,ANTLR,PATCHES /
+property name=common.resources
value=LOG4CXX,CPPTASKS,XALAN,VM,ANTLR,PATCHES,JUNIT /
property name=build.resources value=CPPTASKS /
if
isset property=if.lnx /
diff --git build/make/win.properties build/make/win.properties
index 51274f1..6753d2b 100644
--- build/make/win.properties
+++ build/make/win.properties
@@ -60,6 +60,10 @@ # APR-iconv, version 1.1.1 or above
# http://apr.apache.org/download.cgi
remote.APRICONV.archive=http://apache.reverse.net/pub/apache/apr/apr-iconv-1.1.1-win32-src.zip
+# JUnit, version 3.8.1 or above
+remote.JUNIT.archive=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
+remote.JUNIT.archive.type=asis
+
# LOG4CXX, svn revision 416779
remote.LOG4CXX.archive=-r 416779
http://svn.apache.org/repos/asf/logging/log4cxx/trunk
remote.LOG4CXX.archive.type=svn
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] fix junit.jar download
Can't we just take junit.jar from classlib's depends (as we do with XALAN)?
2006/10/3, Salikh Zakirov [EMAIL PROTECTED]:
Geir,
it looks like the commit
[r452245] HARMONY-698 This should be equivalent to what HARMONY-698
broken the downloading of junit.jar (which we used to take from Eclipse
distribution).
The below patch adds junit.jar as a separate download from ibiblio jar
repository.
--- 8 ---
added downloading of junit.jar
diff --git build/make/lnx.properties build/make/lnx.properties
index c4f6c56..1404b5b 100644
--- build/make/lnx.properties
+++ build/make/lnx.properties
@@ -57,6 +57,10 @@ # APR-iconv, version 1.1.1 or above
# http://apr.apache.org/download.cgi
remote.APRICONV.archive=http://apache.reverse.net/pub/apache/apr/apr-iconv-1.1.1.tar.gz
+# JUnit, version 3.8.1 or above
+remote.JUNIT.archive=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
+remote.JUNIT.archive.type=asis
+
# LOG4CXX, svn revision 416779
# http://logging.apache.org/site/cvs-repositories.html
remote.LOG4CXX.archive=-r 416779
http://svn.apache.org/repos/asf/logging/log4cxx/trunk
diff --git build/make/setup.xml build/make/setup.xml
index e570ae0..be28782 100644
--- build/make/setup.xml
+++ build/make/setup.xml
@@ -105,6 +105,7 @@ Version: $Revision: 1.5.2.33 $
property name=CLASSLIB.check.file value=native-src/README.txt /
property name=XALAN.check.file value=xalan.jar /
property name=VM.check.file value=vmcore/src/init/vm_main.cpp /
+ property name=JUNIT.check.file value=junit-3.8.1.jar /
property name=ANTLR.check.file value=antlr-2.7.5.jar /
property name=PATCHES.check.file value=README.txt /
/target
@@ -148,6 +149,12 @@ Version: $Revision: 1.5.2.33 $
target name=copy.nessessary.jars
+copy tofile=tmp/junit.jar
+fileset dir=${build.precopied.dir}/common/JUNIT
+include name=junit*.jar /
+/fileset
+/copy
+
propertyregex property=build.XALAN.path input=${if.XALAN.exist}
regexp=(.*)/${XALAN.check.f
ile} select=\1 /
copy file=${build.XALAN.path}/xalan.jar todir=tmp /
@@ -176,7 +183,7 @@ Version: $Revision: 1.5.2.33 $
target name=setup.resources depends=plugin.antcontrib
-property name=common.resources
value=LOG4CXX,CPPTASKS,XALAN,VM,ANTLR,PATCHES /
+property name=common.resources
value=LOG4CXX,CPPTASKS,XALAN,VM,ANTLR,PATCHES,JUNIT /
property name=build.resources value=CPPTASKS /
if
isset property=if.lnx /
diff --git build/make/win.properties build/make/win.properties
index 51274f1..6753d2b 100644
--- build/make/win.properties
+++ build/make/win.properties
@@ -60,6 +60,10 @@ # APR-iconv, version 1.1.1 or above
# http://apr.apache.org/download.cgi
remote.APRICONV.archive=http://apache.reverse.net/pub/apache/apr/apr-iconv-1.1.1-win32-src.zip
+# JUnit, version 3.8.1 or above
+remote.JUNIT.archive=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
+remote.JUNIT.archive.type=asis
+
# LOG4CXX, svn revision 416779
remote.LOG4CXX.archive=-r 416779
http://svn.apache.org/repos/asf/logging/log4cxx/trunk
remote.LOG4CXX.archive.type=svn
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][jit] Internal testing framework for Jitrino.OPT compiler
Geir, my comment is in JIRA. On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: yes, I saw - thanks for that. I was trying to get 1531 to work yesterday, and I seemed to do something wrong. Can you look at 1531 and comment? geir Ivan Kollegov wrote: Hi, I opened new JIRA http://issues.apache.org/jira/browse/HARMONY-1586 and attach my contribution to keep things clearer, could you just open a fresh JIRA, attach your contribition, and then link back to 1531? It makes it much easier to track who has given what... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mikhail Fursov
Re: [patch][drlvm] fix junit.jar download
Alexey Varlamov wrote:
Can't we just take junit.jar from classlib's depends (as we do with XALAN)?
I agree, that would be a better solution.
It just didn't occur to me that we already have it in classlib's depends.
So, the below change seems to be sufficient.
--- build/make/setup.xml
+++ build/make/setup.xml
@@ -148,6 +148,8 @@ Version: $Revision: 1.5.2.33 $
target name=copy.nessessary.jars
+copy
file=${external.dep.CLASSLIB}/depends/jars/junit_3.8.2/junit.jar todir=tmp
/
+
propertyregex property=build.XALAN.path input=${if.XALAN.exist}
regexp=(.*)/${XALAN.check.file} select=\1 /
copy file=${build.XALAN.path}/xalan.jar todir=tmp /
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][jit] Internal testing framework for Jitrino.OPT compiler
Ivan, Thank you for the fix. I checked the diff and it looks OK. Actually, with this patch you remove the extra state from CFG - the special behaviour of CFG without exit/entry nodes. And I think that this is right. Now it's time to ask commiters to apply the patch. On 10/3/06, Ivan Kollegov [EMAIL PROTECTED] wrote: Hi Mikhail, I created fix for this bag and posted my diff to https://issues.apache.org/jira/browse/HARMONY-1665 I added 2 ifs for entry and exit nodes, to verify if the node is not null. If the node is null, then return. Can you check my fix? On 9/27/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Ivan, I've checked all of the tests - this is very good beginning! I see 2 directions to advance: 1) Integrate Jitrino tests into common harmony test system. So we can ask people to use our test suite. 2) Start to test not only CFG but more complex IR examples. I mean to test IR with instructions using optimizations. I want to get item 1 as TODO for myself. Could you take item 2 and write several IR templates with instructions and use these templates in tests? getNodeCountTest2 - this is a real bug. This bug does not affect any of JIT algorithms today, but anyway it must be fixed. Could you create and post the fix into JIRA? If you have questions I can help you with the fix. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mikhail Fursov
Re: [classlib] removing \t from sources
Thanks, Tim :-)
Regards,
2006/10/3, Tim Ellison [EMAIL PROTECTED]:
I've committed the reformatted code in r452415.
Now you can feel calm again :-)
The other modules are being cleaned-up piece by piece.
Regards,
Tim
Alexei Zakharov wrote:
I see. This IMHO is another argument why \t is bad. My script will not
be able to handle this, it just replaces one string pattern with
another. So such cases should be handled manually or with the code
formatter. However, the drawback of the code formatter is that it
removes the author's personality from the code.
But IMHO mixing spaces with tabs in the single unit of indentation is
even worse than just using tabs. Normally people use either tabs or
spaces. I suppose that mixes appear when the original source with tabs
is being edited with IDE configured to use spaces. I haven't seen many
of such cases in HY code, at least in the modules I worked with.
With best regards,
2006/10/2, Alexey Petrenko [EMAIL PROTECTED]:
I mean that {space, space, tab} will be converted to the same
number of spaces as simple tab by the most of editors.
SY, Alexey
2006/10/2, Alexei Zakharov [EMAIL PROTECTED]:
What do you mean? Convert \t to something? If so please see the
new fully customized version of my mega-script :-)
The usage pattern in your case will be:
ant -f tabs2spaces_v2.xml -Dsrc.dir=dir with sources -Dpattern= \t
Regards,
2006/10/2, Alexey Petrenko [EMAIL PROTECTED]:
Does it work with the sequences like {space, space, tab} etc?
2006/10/2, Alexei Zakharov [EMAIL PROTECTED]:
Hi all,
I noticed that the tab character (0x09) is still widely used in our
classlib source code. At least in tests. From my recent experience
this leads to broken indentation. I mean the situation when
patch with
spaces is applied to the source there tab character is used for
indentation. Someone knows that according to Sun code
conventions the
tab should be exactly 8 spaces. The other person knows that exactly
four spaces should be used as the unit of indentation [1]. As a
result
we have all methods indented with the single tab character and the
patched methods indented with 4 spaces. And if your IDE is
configured
to display tabs as 8 spaces you will see broken indentation. Or
vice
versa.
I have created small ANT script - see HARMONY-1660 [2]. This script
converts all tabs to spaces in all found sources under the given
directory recursively. I will be grateful if someone runs this
script
(tab - 4 spaces) at least for beans tests (I currently working
with)
and integrates the results. It is really painful to deal with this
broken alignment every day. And it is too boring (and IMHO
silly) to
convert it file by file and send patches for each case.
[1]
http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html#262
[3] http://issues.apache.org/jira/browse/HARMONY-1660
Thanks,
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][build] Improvements to build system
--- Alexey Varlamov [EMAIL PROTECTED] wrote: Guys, I have a kind request for test target customization: 1) need ability to pass extra arguments to tested jre. This is useful for testing various configurations of VM, e.g. different execution engines in DRLVM. you mean like passing nested sysproperty and syspropertyset to junit? These are available. 2) easy switching between fork modes perTest once. This is actual for testing unstable VMs. So just use a junit.forkmode property defaulted to once and overridable with -D from the command line. Another popular strategy for using user-specific setup is to have your buildfiles attempt to load a properties file by a well-known name early on (first thing): property file=build.properties / If the file does not exist, no harm, no foul. If it does exist it is a convenient place to override default property settings. -Matt Or I'm just not aware of smth? Hmm, seems we can use harmonyvm.properties to workaround item 1) ... -- Alexey [SNIP] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] fix junit.jar download
1) Salikh - thanks for catching this
2) Alexey - yes, I think that would be better. Can someone offer a patch?
geir
Alexey Varlamov wrote:
Can't we just take junit.jar from classlib's depends (as we do with XALAN)?
2006/10/3, Salikh Zakirov [EMAIL PROTECTED]:
Geir,
it looks like the commit
[r452245] HARMONY-698 This should be equivalent to what HARMONY-698
broken the downloading of junit.jar (which we used to take from
Eclipse distribution).
The below patch adds junit.jar as a separate download from ibiblio jar
repository.
--- 8 ---
added downloading of junit.jar
diff --git build/make/lnx.properties build/make/lnx.properties
index c4f6c56..1404b5b 100644
--- build/make/lnx.properties
+++ build/make/lnx.properties
@@ -57,6 +57,10 @@ # APR-iconv, version 1.1.1 or above
# http://apr.apache.org/download.cgi
remote.APRICONV.archive=http://apache.reverse.net/pub/apache/apr/apr-iconv-1.1.1.tar.gz
+# JUnit, version 3.8.1 or above
+remote.JUNIT.archive=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
+remote.JUNIT.archive.type=asis
+
# LOG4CXX, svn revision 416779
# http://logging.apache.org/site/cvs-repositories.html
remote.LOG4CXX.archive=-r 416779
http://svn.apache.org/repos/asf/logging/log4cxx/trunk
diff --git build/make/setup.xml build/make/setup.xml
index e570ae0..be28782 100644
--- build/make/setup.xml
+++ build/make/setup.xml
@@ -105,6 +105,7 @@ Version: $Revision: 1.5.2.33 $
property name=CLASSLIB.check.file
value=native-src/README.txt /
property name=XALAN.check.file value=xalan.jar /
property name=VM.check.file
value=vmcore/src/init/vm_main.cpp /
+ property name=JUNIT.check.file value=junit-3.8.1.jar /
property name=ANTLR.check.file
value=antlr-2.7.5.jar /
property name=PATCHES.check.file value=README.txt /
/target
@@ -148,6 +149,12 @@ Version: $Revision: 1.5.2.33 $
target name=copy.nessessary.jars
+copy tofile=tmp/junit.jar
+fileset dir=${build.precopied.dir}/common/JUNIT
+include name=junit*.jar /
+/fileset
+/copy
+
propertyregex property=build.XALAN.path
input=${if.XALAN.exist} regexp=(.*)/${XALAN.check.f
ile} select=\1 /
copy file=${build.XALAN.path}/xalan.jar todir=tmp /
@@ -176,7 +183,7 @@ Version: $Revision: 1.5.2.33 $
target name=setup.resources depends=plugin.antcontrib
-property name=common.resources
value=LOG4CXX,CPPTASKS,XALAN,VM,ANTLR,PATCHES /
+property name=common.resources
value=LOG4CXX,CPPTASKS,XALAN,VM,ANTLR,PATCHES,JUNIT /
property name=build.resources value=CPPTASKS /
if
isset property=if.lnx /
diff --git build/make/win.properties build/make/win.properties
index 51274f1..6753d2b 100644
--- build/make/win.properties
+++ build/make/win.properties
@@ -60,6 +60,10 @@ # APR-iconv, version 1.1.1 or above
# http://apr.apache.org/download.cgi
remote.APRICONV.archive=http://apache.reverse.net/pub/apache/apr/apr-iconv-1.1.1-win32-src.zip
+# JUnit, version 3.8.1 or above
+remote.JUNIT.archive=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
+remote.JUNIT.archive.type=asis
+
# LOG4CXX, svn revision 416779
remote.LOG4CXX.archive=-r 416779
http://svn.apache.org/repos/asf/logging/log4cxx/trunk
remote.LOG4CXX.archive.type=svn
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][jit] Internal testing framework for Jitrino.OPT compiler
so is my response :) Mikhail Fursov wrote: Geir, my comment is in JIRA. On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: yes, I saw - thanks for that. I was trying to get 1531 to work yesterday, and I seemed to do something wrong. Can you look at 1531 and comment? geir Ivan Kollegov wrote: Hi, I opened new JIRA http://issues.apache.org/jira/browse/HARMONY-1586 and attach my contribution to keep things clearer, could you just open a fresh JIRA, attach your contribition, and then link back to 1531? It makes it much easier to track who has given what... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][jit] Internal testing framework for Jitrino.OPT compiler
done Mikhail Fursov wrote: Ivan, Thank you for the fix. I checked the diff and it looks OK. Actually, with this patch you remove the extra state from CFG - the special behaviour of CFG without exit/entry nodes. And I think that this is right. Now it's time to ask commiters to apply the patch. On 10/3/06, Ivan Kollegov [EMAIL PROTECTED] wrote: Hi Mikhail, I created fix for this bag and posted my diff to https://issues.apache.org/jira/browse/HARMONY-1665 I added 2 ifs for entry and exit nodes, to verify if the node is not null. If the node is null, then return. Can you check my fix? On 9/27/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Ivan, I've checked all of the tests - this is very good beginning! I see 2 directions to advance: 1) Integrate Jitrino tests into common harmony test system. So we can ask people to use our test suite. 2) Start to test not only CFG but more complex IR examples. I mean to test IR with instructions using optimizations. I want to get item 1 as TODO for myself. Could you take item 2 and write several IR templates with instructions and use these templates in tests? getNodeCountTest2 - this is a real bug. This bug does not affect any of JIT algorithms today, but anyway it must be fixed. Could you create and post the fix into JIRA? If you have questions I can help you with the fix. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] fix junit.jar download
fixed - thanks
Salikh Zakirov wrote:
Alexey Varlamov wrote:
Can't we just take junit.jar from classlib's depends (as we do with XALAN)?
I agree, that would be a better solution.
It just didn't occur to me that we already have it in classlib's depends.
So, the below change seems to be sufficient.
--- build/make/setup.xml
+++ build/make/setup.xml
@@ -148,6 +148,8 @@ Version: $Revision: 1.5.2.33 $
target name=copy.nessessary.jars
+copy file=${external.dep.CLASSLIB}/depends/jars/junit_3.8.2/junit.jar todir=tmp /
+
propertyregex property=build.XALAN.path input=${if.XALAN.exist}
regexp=(.*)/${XALAN.check.file} select=\1 /
copy file=${build.XALAN.path}/xalan.jar todir=tmp /
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] Recognizing lock objects
There are a number of places in the class library code where we create
an object solely to use as a synchronized block 'lock'.
For example, in RandomAccessFile we define a
private Object repositionLock = new Object();
then in a number of methods
public int read()..
..
synchronized(repositionLock) {
...
}
you get the idea.
Using an instance of Object makes it hard to see (in profiling tools)
which lock objects are 'hot', or how often a particular lock object is used.
I'd like to replace the generic Object instance with a private type just
for the purpose, like this:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
The usage would be the same, but it will then be easier to see if
RandomAccessFile$RepositionLock becomes a choke point.
Any objections or improvements to this proposed 'pattern' and putting it
into various places throughout the class library?
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[vote] HARMONY-1609 - bulk contribution of Applet, ImageIO and Print modules
BCC and ACQs in place. [ ] +1 Yes, accept the contribution [ ] -1 No, don't. reason : As usual, 3 days or until all committers vote, or there is an objection/request for continuance - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] [testing] How to file JIRA issues for impl JUnit tests?
Hello, It's clear how to file issues for public API - write a test with differend behaviour on RI and Harmony. It's not clear how to write tests or report problems when JUnit impl test fail. I see org.apache.harmony.security.tests.asn1.der.SequenceTest failing at svn = r452457, (Oct 3 2006), Windows/ia32/msvc 1310, debug build Other people report failures , too : http://www.harmonytest.org/testapp.do?method=showresultid=74663 -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Recognizing lock objects
Tim Ellison wrote:
There are a number of places in the class library code where we create
an object solely to use as a synchronized block 'lock'.
For example, in RandomAccessFile we define a
private Object repositionLock = new Object();
then in a number of methods
public int read()..
..
synchronized(repositionLock) {
...
}
you get the idea.
Using an instance of Object makes it hard to see (in profiling tools)
which lock objects are 'hot', or how often a particular lock object is used.
I'd like to replace the generic Object instance with a private type just
for the purpose, like this:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
Why RepositionLock? (curious about origin of the name)
The usage would be the same, but it will then be easier to see if
RandomAccessFile$RepositionLock becomes a choke point.
Any objections or improvements to this proposed 'pattern' and putting it
into various places throughout the class library?
I like it. But, any benefit to having a general class
o.a.h.whatever.LockObject rather than class private?
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1609 - bulk contribution of Applet, ImageIO and Print modules
+1 On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: BCC and ACQs in place. [ ] +1 Yes, accept the contribution [ ] -1 No, don't. reason : As usual, 3 days or until all committers vote, or there is an objection/request for continuance - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][tools] The java class file disassembler contribution announcement.
Hi all, I have developed a tool to disassemble the java class files. Its behavior is similar to the javap tool from J2SE 1.5.0. I would like it to be included in the Harmony tools project. The contribution can be found there: http://issues.apache.org/jira/browse/HARMONY-1680 The contribution archive contains the source files, building script and several text files. One of the text files is README, which explains in detail how the tool can be built and how you can use it as a standalone application. All the code is pure Java. Please don't hesitate to contact me for more details. Thanks. -- Dmitry M. Kononov 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: [classlib] Recognizing lock objects
Tim,
I suspect there may be some JVM internal lock design issues involved in what
you are suggesting. In specific, I vaguely remember a paper written by
David Bacon that describes lock optimization heuristics based on the
observation that most of the time, the object being locked is an instance of
a synchronized class.
Maybe it makes sense to build a microbenchmark of what you are suggesting
and run it on several different JVMs? Maybe it makes sense to prototype
Java locking code in a way that VM fat/thin locks like best??
I suspect that your initial goal is classlib performance only. I'd like to
see if we can expand this to JVM-wide system performance. Otherwise we run
the risk of re-optimizing the whole stack and re-opening the classlib lock
design at a later date. :(
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
There are a number of places in the class library code where we create
an object solely to use as a synchronized block 'lock'.
For example, in RandomAccessFile we define a
private Object repositionLock = new Object();
then in a number of methods
public int read()..
..
synchronized(repositionLock) {
...
}
you get the idea.
Using an instance of Object makes it hard to see (in profiling tools)
which lock objects are 'hot', or how often a particular lock object is
used.
I'd like to replace the generic Object instance with a private type just
for the purpose, like this:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
The usage would be the same, but it will then be easier to see if
RandomAccessFile$RepositionLock becomes a choke point.
Any objections or improvements to this proposed 'pattern' and putting it
into various places throughout the class library?
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
Re: [classlib] Recognizing lock objects
I don't think the goal is performance, but just being able to monitor
what sync blocks are hot via watching the sync objects.
geir
Weldon Washburn wrote:
Tim,
I suspect there may be some JVM internal lock design issues involved in
what
you are suggesting. In specific, I vaguely remember a paper written by
David Bacon that describes lock optimization heuristics based on the
observation that most of the time, the object being locked is an
instance of
a synchronized class.
Maybe it makes sense to build a microbenchmark of what you are suggesting
and run it on several different JVMs? Maybe it makes sense to prototype
Java locking code in a way that VM fat/thin locks like best??
I suspect that your initial goal is classlib performance only. I'd like to
see if we can expand this to JVM-wide system performance. Otherwise we run
the risk of re-optimizing the whole stack and re-opening the classlib lock
design at a later date. :(
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
There are a number of places in the class library code where we create
an object solely to use as a synchronized block 'lock'.
For example, in RandomAccessFile we define a
private Object repositionLock = new Object();
then in a number of methods
public int read()..
..
synchronized(repositionLock) {
...
}
you get the idea.
Using an instance of Object makes it hard to see (in profiling tools)
which lock objects are 'hot', or how often a particular lock object is
used.
I'd like to replace the generic Object instance with a private type just
for the purpose, like this:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
The usage would be the same, but it will then be easier to see if
RandomAccessFile$RepositionLock becomes a choke point.
Any objections or improvements to this proposed 'pattern' and putting it
into various places throughout the class library?
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Recognizing lock objects
Geir Magnusson Jr. wrote:
I don't think the goal is performance, but just being able to monitor
what sync blocks are hot via watching the sync objects.
What I meant to say was that it's not the performance of the lock
objects themselves, but the overall performance of the code that uses
it, hence looking for a better way to identify hot lock objects.
And therefore, I now grok why we can't have a global one. :)
geir
Weldon Washburn wrote:
Tim,
I suspect there may be some JVM internal lock design issues involved
in what
you are suggesting. In specific, I vaguely remember a paper written by
David Bacon that describes lock optimization heuristics based on the
observation that most of the time, the object being locked is an
instance of
a synchronized class.
Maybe it makes sense to build a microbenchmark of what you are suggesting
and run it on several different JVMs? Maybe it makes sense to prototype
Java locking code in a way that VM fat/thin locks like best??
I suspect that your initial goal is classlib performance only. I'd
like to
see if we can expand this to JVM-wide system performance. Otherwise
we run
the risk of re-optimizing the whole stack and re-opening the classlib
lock
design at a later date. :(
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
There are a number of places in the class library code where we create
an object solely to use as a synchronized block 'lock'.
For example, in RandomAccessFile we define a
private Object repositionLock = new Object();
then in a number of methods
public int read()..
..
synchronized(repositionLock) {
...
}
you get the idea.
Using an instance of Object makes it hard to see (in profiling tools)
which lock objects are 'hot', or how often a particular lock object is
used.
I'd like to replace the generic Object instance with a private type just
for the purpose, like this:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
The usage would be the same, but it will then be easier to see if
RandomAccessFile$RepositionLock becomes a choke point.
Any objections or improvements to this proposed 'pattern' and putting it
into various places throughout the class library?
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Recognizing lock objects
Yep, you've got it.
Regards,
Tim
Geir Magnusson Jr. wrote:
Geir Magnusson Jr. wrote:
I don't think the goal is performance, but just being able to monitor
what sync blocks are hot via watching the sync objects.
What I meant to say was that it's not the performance of the lock
objects themselves, but the overall performance of the code that uses
it, hence looking for a better way to identify hot lock objects.
And therefore, I now grok why we can't have a global one. :)
geir
Weldon Washburn wrote:
Tim,
I suspect there may be some JVM internal lock design issues involved
in what
you are suggesting. In specific, I vaguely remember a paper written by
David Bacon that describes lock optimization heuristics based on the
observation that most of the time, the object being locked is an
instance of
a synchronized class.
Maybe it makes sense to build a microbenchmark of what you are
suggesting
and run it on several different JVMs? Maybe it makes sense to prototype
Java locking code in a way that VM fat/thin locks like best??
I suspect that your initial goal is classlib performance only. I'd
like to
see if we can expand this to JVM-wide system performance. Otherwise
we run
the risk of re-optimizing the whole stack and re-opening the classlib
lock
design at a later date. :(
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
There are a number of places in the class library code where we create
an object solely to use as a synchronized block 'lock'.
For example, in RandomAccessFile we define a
private Object repositionLock = new Object();
then in a number of methods
public int read()..
..
synchronized(repositionLock) {
...
}
you get the idea.
Using an instance of Object makes it hard to see (in profiling tools)
which lock objects are 'hot', or how often a particular lock object is
used.
I'd like to replace the generic Object instance with a private type
just
for the purpose, like this:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
The usage would be the same, but it will then be easier to see if
RandomAccessFile$RepositionLock becomes a choke point.
Any objections or improvements to this proposed 'pattern' and
putting it
into various places throughout the class library?
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [classlib] [testing] How to file JIRA issues for impl JUnit tests?
Submit a JIRA with the failure and expected result (or am I missing something?) Regards, Tim Anton Luht wrote: Hello, It's clear how to file issues for public API - write a test with differend behaviour on RI and Harmony. It's not clear how to write tests or report problems when JUnit impl test fail. I see org.apache.harmony.security.tests.asn1.der.SequenceTest failing at svn = r452457, (Oct 3 2006), Windows/ia32/msvc 1310, debug build Other people report failures , too : http://www.harmonytest.org/testapp.do?method=showresultid=74663 -- 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: [general] creation of jdktools
+1 for creating a jdktools directory. The dependency on the classlib launcher should be relatively light if we go with a simple tools launcher that rewrites the tool invocation into a generic launcher invocation. You may recall the idea was discussed a while ago. So, for example, jdk/bin/javac -source 1.5 -J-Xmx200M FooBar is rewritten to jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M org.apache.harmony.tools.javac.Main -source 1.5 FooBar and so on. Regards, Tim Geir Magnusson Jr. wrote: Geir Magnusson Jr. wrote: Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd like to organize these and add them to the next snapshot. My bad - the javap isn't being voted on yet. I was thinking of the jdwp vote... sorry So I propose adding a new top-level directory called jdktools (and rename tools to project_tools) and create a build target that - with a dependency on classlib for the launcher - creates the 'stuff' needed to fill into the JDK. Any comments? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [drlvm] apr_dso_load error (path address out of bounds)
I thought that perhaps a gdb backtrace may be helpful.
Note: I also tried to go into dll_jit.cpp:62 and hard code the name of the
dll_filename which is passed to apr_dso_load. And still when I step into
apr_dso_load that second argument path=0x102 Address 0x102 out of bounds.
Perhaps the stack is getting messed up somehow.
Any ideas?
(gdb) bt
#0 apr_dso_load (res_handle=0x102, path=0x102 Address 0x102 out of
bounds, pool=0x808fc78) at dso.c:139
#1 0xb6d99b61 in Dll_JIT (this=0x80a9650,
dll_filename=0x80a9774
/scratch/anavabi/Harmony/enhanced/drlvm/build/deploy/jre/bin/default//libji
trino.so)
at
/scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/jit/dll_jit.cpp:63
#2 0xb6e4ff4e in vm_load_jit (
file_name=0x80a9774
/scratch/anavabi/Harmony/enhanced/drlvm/build/deploy/jre/bin/default//libji
trino.so,
handle=0xbfa9e51c) at
/scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/init/vm_main.cpp:629
#3 0xb69afa9e in DrlEMImpl::buildChains (this=0x80a9480,
[EMAIL PROTECTED])
at /scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/DrlEMImpl.cpp:437
#4 0xb69af256 in DrlEMImpl::init (this=0x80a9480) at
/scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/DrlEMImpl.cpp:363
#5 0xb69ad239 in DrlEMFactory::createAndInitEMInstance ()
at /scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/DrlEMImpl.cpp:52
#6 0xb69c7a72 in CreateInstance (p_instance=0xb7022f88, pool=0x808dc70)
at /scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/em_intf.cpp:132
#7 0xb6d95fae in CmCreateInstance (p_instance=0xb7022f88, name=0xb6f7eac4
em)
at
/scratch/anavabi/Harmony/enhanced/drlvm/vm/vmstart/src/compmgr/component_man
ager_impl.cpp:584
#8 0xb6e4dd37 in process_properties_dlls (p_env=0xb7022de0)
at
/scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/init/vm_main.cpp:148
#9 0xb6e4f0f6 in create_vm (p_env=0xb7022de0, vm_arguments=0xbfa9e8c0)
at
/scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/init/vm_main.cpp:356
#10 0xb6dc6826 in JNI_CreateJavaVM (p_vm=0xbfa9e8b0, p_env=0xbfa9e8b4,
vm_args=0xbfa9e8c0)
at
/scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/jni/jni.cpp:1270
#11 0x0804962c in invocation ()
#12 0x08048fd0 in gpProtectedMain ()
#13 0x0804ac4c in signalProtectedMain ()
#14 0xb7fb5e00 in hysig_protect () from
/scratch/anavabi/Harmony/enhanced/drlvm/build/deploy/jre/bin/libhyprt.so
#15 0x0804ad0c in main ()
-Original Message-
From: Armand Navabi [mailto:[EMAIL PROTECTED]
Sent: Monday, October 02, 2006 2:03 PM
To: harmony-dev@incubator.apache.org
Subject: [drlvm] apr_dso_load error (path address out of bounds)
I am still having trouble getting hellworld to run. Currently the problem
is that for some reason in dll_jit.cpp on line 62, where the call is made to
apr_dso_load, the second parameter which is the path to the dll becomes
address out of bounds in the apr_dso_load procedure.
Egor suggested that perhaps APR configured itself incorrectly on my system.
Alexey suggested I try to run the APR test. I ran the APR tests and all
tests passed (in /build/lnx_ia32_gcc_debug/semis/extra/apr/src/test).
Below is what happens in gdb. Also below that I have pasted what happens at
the end of the output when I run ./java -Xthread -Xtrace helloworld.
Another thing that is suspicious is that when I run ./java it works fine,
but if I run ./java -Xthread -Xtrace it does not run fine (it hangs inside
GetObjectClass). I have also pasted the end of the trace for this.
Let me know if there is any other debugging information I can provide.
(gdb) r helloworld
Starting program:
/scratch/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java
helloworld
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 16947)]
[New Thread 32769 (LWP 16950)]
[New Thread 16386 (LWP 16951)]
Breakpoint 2 at 0xb6e28ca5: file
/scratch/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/vm_main.cpp
, line 628.
Pending breakpoint vm_main.cpp:628 resolved
[Switching to Thread 16384 (LWP 16947)]
Breakpoint 2, vm_load_jit (file_name=0x80aa83c
/scratch/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default/
/libjitrino.so, handle=0xbff4ff4c)
at
/scratch/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/vm_main.cpp
:628
628 Dll_JIT* jit = new Dll_JIT(file_name);
Current language: auto; currently c++
(gdb) s
Dll_JIT (this=0x80aa708, dll_filename=0x80aa83c
/scratch/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default/
/libjitrino.so)
at
/scratch/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmcore/src/jit/dll_jit.cpp:
56
56 {
(gdb) n
59 memset((void *) jit_flags, 0, sizeof(JIT_Flags));
(gdb) n
60 apr_pool_create(pool, 0);
(gdb) n
62 if ((stat = apr_dso_load(handle, dll_filename, pool)) !=
APR_SUCCESS)
(gdb) p dll_filename
$1 = 0x80aa83c
/scratch/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default/
/libjitrino.so
(gdb) s
apr_dso_load
RE: [drlvm] apr_dso_load error (path address out of bounds)
Sorry about the last email, but there is something I think I should mention. I recently checked out a clean copy and rebuilt from scratch. I did not notice BUT since then, helloworld does actually run!! It just hangs after it runs. Now the behavior is very similar to when I run ./java -showversion (i.e. prints out version information and then hangs). I plan to look into this. But when I run gdb, I still see: apr_dso_load (res_handle=0x102, path=0x102 Address 0x102 out of bounds, pool=0x808fc78) at dso.c:139 139 os_handle = dlopen(path, flags); Despite this, it seems to still run fine after that point (i.e. Hello World executes after all the libraries are loaded, even though every single load seems to fail because of the address not found problem). Anyway, I'm running hello world now, and so I'm happy. Thanks, Armand -Original Message- From: Armand Navabi [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 3:22 PM To: harmony-dev@incubator.apache.org Subject: RE: [drlvm] apr_dso_load error (path address out of bounds) I thought that perhaps a gdb backtrace may be helpful. Note: I also tried to go into dll_jit.cpp:62 and hard code the name of the dll_filename which is passed to apr_dso_load. And still when I step into apr_dso_load that second argument path=0x102 Address 0x102 out of bounds. Perhaps the stack is getting messed up somehow. Any ideas? (gdb) bt #0 apr_dso_load (res_handle=0x102, path=0x102 Address 0x102 out of bounds, pool=0x808fc78) at dso.c:139 #1 0xb6d99b61 in Dll_JIT (this=0x80a9650, dll_filename=0x80a9774 /scratch/anavabi/Harmony/enhanced/drlvm/build/deploy/jre/bin/default//libji trino.so) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/jit/dll_jit.cpp:63 #2 0xb6e4ff4e in vm_load_jit ( file_name=0x80a9774 /scratch/anavabi/Harmony/enhanced/drlvm/build/deploy/jre/bin/default//libji trino.so, handle=0xbfa9e51c) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/init/vm_main.cpp:629 #3 0xb69afa9e in DrlEMImpl::buildChains (this=0x80a9480, [EMAIL PROTECTED]) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/DrlEMImpl.cpp:437 #4 0xb69af256 in DrlEMImpl::init (this=0x80a9480) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/DrlEMImpl.cpp:363 #5 0xb69ad239 in DrlEMFactory::createAndInitEMInstance () at /scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/DrlEMImpl.cpp:52 #6 0xb69c7a72 in CreateInstance (p_instance=0xb7022f88, pool=0x808dc70) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/em_intf.cpp:132 #7 0xb6d95fae in CmCreateInstance (p_instance=0xb7022f88, name=0xb6f7eac4 em) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/vmstart/src/compmgr/component_man ager_impl.cpp:584 #8 0xb6e4dd37 in process_properties_dlls (p_env=0xb7022de0) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/init/vm_main.cpp:148 #9 0xb6e4f0f6 in create_vm (p_env=0xb7022de0, vm_arguments=0xbfa9e8c0) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/init/vm_main.cpp:356 #10 0xb6dc6826 in JNI_CreateJavaVM (p_vm=0xbfa9e8b0, p_env=0xbfa9e8b4, vm_args=0xbfa9e8c0) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/jni/jni.cpp:1270 #11 0x0804962c in invocation () #12 0x08048fd0 in gpProtectedMain () #13 0x0804ac4c in signalProtectedMain () #14 0xb7fb5e00 in hysig_protect () from /scratch/anavabi/Harmony/enhanced/drlvm/build/deploy/jre/bin/libhyprt.so #15 0x0804ad0c in main () -Original Message- From: Armand Navabi [mailto:[EMAIL PROTECTED] Sent: Monday, October 02, 2006 2:03 PM To: harmony-dev@incubator.apache.org Subject: [drlvm] apr_dso_load error (path address out of bounds) I am still having trouble getting hellworld to run. Currently the problem is that for some reason in dll_jit.cpp on line 62, where the call is made to apr_dso_load, the second parameter which is the path to the dll becomes address out of bounds in the apr_dso_load procedure. Egor suggested that perhaps APR configured itself incorrectly on my system. Alexey suggested I try to run the APR test. I ran the APR tests and all tests passed (in /build/lnx_ia32_gcc_debug/semis/extra/apr/src/test). Below is what happens in gdb. Also below that I have pasted what happens at the end of the output when I run ./java -Xthread -Xtrace helloworld. Another thing that is suspicious is that when I run ./java it works fine, but if I run ./java -Xthread -Xtrace it does not run fine (it hangs inside GetObjectClass). I have also pasted the end of the trace for this. Let me know if there is any other debugging information I can provide. (gdb) r helloworld Starting program: /scratch/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 16947)] [New Thread 32769 (LWP 16950)] [New Thread 16386 (LWP 16951)] Breakpoint 2 at 0xb6e28ca5: file /scratch/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/vm_main.cpp ,
Re: [general] creation of jdktools
+1 from me too. I'd like idea of having separate directory for all tools going to JDK and including them into federal build. Ivan. On 10/4/06, Tim Ellison [EMAIL PROTECTED] wrote: +1 for creating a jdktools directory. The dependency on the classlib launcher should be relatively light if we go with a simple tools launcher that rewrites the tool invocation into a generic launcher invocation. You may recall the idea was discussed a while ago. So, for example, jdk/bin/javac -source 1.5 -J-Xmx200M FooBar is rewritten to jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M org.apache.harmony.tools.javac.Main -source 1.5 FooBar and so on. Regards, Tim Geir Magnusson Jr. wrote: Geir Magnusson Jr. wrote: Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd like to organize these and add them to the next snapshot. My bad - the javap isn't being voted on yet. I was thinking of the jdwp vote... sorry So I propose adding a new top-level directory called jdktools (and rename tools to project_tools) and create a build target that - with a dependency on classlib for the launcher - creates the 'stuff' needed to fill into the JDK. Any comments? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to put the tools.... (was Re: [vote] HARMONY-1410 : JDWP agent for DRLVM)
Initially I considered putting JDWP agent to classlib as part of JPDA module, so its build is adjusted to the classlib build structure. But I agree that putting it to tools directory (or to jdktools as discussed in separate thread) should be better solution. JDWP agent is not an implementation of Java classes like classlib modules, it provides debug service for JRE and thus logically it is closer to tools, though it is not a true tool like javac, javap, rmic, etc., it's rather service. I suggest creating JPDA module in tools (or jdktools) directory and putting there the whole JDWP contribution that includes implementation of JDWP agent, TCP/IP socket transport, and JDWP unit tests. Creating JPDA module in tools for JDWP agent gives the following advantages: --- this follows logical structure of JPDA architecture that includes JDI, JDWP, JVMTI/DI/PI levels --- initially it will include JDWP implementation as a minimal support for debug service in Harmony JRE --- one day we can add here JDI implementation (main JPDA component currently provided by Eclipse JDT debugger) that is necessary in JDK for enabling other Java debuggers --- we can also add here implementation of profiling agent similar to what is included in other JDKs --- we can add here any other JPDA based tools and services which provide extended functionality --- tests for all JPDA components can share JPDA testing framework currently provided with JDWP tests that facilitates running two JVM instances (debugger/debuggee or profiler/profilee) I think you can put JDWP contribution to tools/jpda as is, it is proven to be built separately. AFAIK, currently there are no rules and runtime structure for building tools, each tool is built separately. I can then provide a patch for build.xml just to facilitate separate build according to the new location of JPDA module. But I think we need a discussion of how to include building tools into common build and what should be supported by their build scripts. Anyway, I volunteered for providing any support for quick integration of JDWP agent into Harmony sources and resolving all problems. Finally, I'd like to add several notes according to putting JDWP agent to tools: --- Unlike to other tools whose binaries usually go to JDK binaries directory, JDWP agent binary usually goes to JRE binaries directory. This enables debugging application running on JRE even if you have no JDK available, especially if you are debugging application remotely. --- I'd like to see JDWP unit tests included into regular tests runs, they often reveal problems with JVMTI and JNI support when JVM implementation is changed. I'm not sure that unit tests are provided with other tools and included into tests run, and this can be a separate topic for discussion. Thanks. Ivan On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Keeping the discussion out of the vote thread. Both this and javah aren't going into classlib anyway. I was going to suggest we put them into /tools, bring the javac and keytool over, and I volunteer to do it. Then add that to the federated build, and get into the jdk. geir On Sep 28, 2006, at 8:07 AM, Ivan Popov wrote: Yes, build script for JDWP agent should be aligned with the current classlib build structure. It should be easy, because it is generally oriented to the classlib structure and requires just a few changes. I can provide patch for this. I tried to build JDWP agent as a separate classlib component and it was built successfully with some known problems mentioned in README. Thanks. Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] creation of jdktools
yep, that's the plan. And once we have that, we can simplify the launcher as well... Tim Ellison wrote: +1 for creating a jdktools directory. The dependency on the classlib launcher should be relatively light if we go with a simple tools launcher that rewrites the tool invocation into a generic launcher invocation. You may recall the idea was discussed a while ago. So, for example, jdk/bin/javac -source 1.5 -J-Xmx200M FooBar is rewritten to jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M org.apache.harmony.tools.javac.Main -source 1.5 FooBar and so on. Regards, Tim Geir Magnusson Jr. wrote: Geir Magnusson Jr. wrote: Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd like to organize these and add them to the next snapshot. My bad - the javap isn't being voted on yet. I was thinking of the jdwp vote... sorry So I propose adding a new top-level directory called jdktools (and rename tools to project_tools) and create a build target that - with a dependency on classlib for the launcher - creates the 'stuff' needed to fill into the JDK. Any comments? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to put the tools.... (was Re: [vote] HARMONY-1410 : JDWP agent for DRLVM)
Ivan Popov wrote: --- I'd like to see JDWP unit tests included into regular tests runs, they often reveal problems with JVMTI and JNI support when JVM implementation is changed. I'm not sure that unit tests are provided with other tools and included into tests run, and this can be a separate topic for discussion. Yah, I've been noting that in JVMTI commit messages - we need a suite of JVMTI tests, and I guess we can use the agent for it? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wonka, Mika, and Apache
Sounds interesting. Does this still include the hardware portability layer? Any synergies with APR? Does it include the AWT code? --- Noel -Original Message- From: Chris Gray [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 27, 2006 5:09 To: general@incubator.apache.org Cc: harmony-dev@incubator.apache.org Subject: Wonka, Mika, and Apache Hello guys, To introduce myself: I'm one of the original developers of the Wonka embedded VM, and my company sells both support for Wonka and our own derivative which we call Mika. Recently we made Mika available under the same BSD-style licence as Wonka. My question is whether Apache would be interested in adopting Wonka/Mika as a project, either within Harmony or as an embedded counterpart thereto. Currently ownership of the code is divided between Punch Telematix, who acquired the assets of my former employer Acunia, and my own company. Punch have no interest in the VM beyond the fact that it is an essential component of a product (the CarCube) which they inherited from Acunia. I believe they would have no objection to granting rights to the AF, beyond the sheer effort of doing so. They can probably be persuaded, but first I'd like to know if there is sufficient interest within the AF. Best regards, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
On 10/3/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 10/3/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Andrey, Just to be clear I agree with you it is more convenient if jthread_create takes JNIEnv instead of JavaVM. It reflects that current thread has been attached already. Do you think it makes sense to get rid of JNIEnv and use jthread_get_JNI_env in that case? The jthread_* layer is designed like if it were a regular JNI application which is meant to be called from the Java code, hence every function on that layer receives JNIenv. We can probably get rid of the JNEnv parameter for jthread_* functions, assuming that TM can always extract JNIenv for the current thread with jthread_get_JNI_env(). My only concern would be the performance - once the JNIenv is already known for the native part of the kernel classes impl, it must be cheaper to pass JNIEnv to TM as an extra parameter rather than extract it from the TLS again. Other than that, I see no strong advantages in keeping JNIEnv parameter. Regarding jthread_attach. I still didn't get your point Clarify it please if you think jhread_attach should be modified. Sorry for being not clear: I think for jthread_attach, we have two options: 1) Make JNIEnv input parameter - it must be new JNIEnv that VM pre-allocates for the new Java thread. jthread_attach would just associate it with the current thread. 2) Obtain JNIEnv via vm_attach() callback. In this case, if vm_attach() callback implementation needs to know for which JavaVM new JNIenv has to be allocated, then we'll need to add JavaVM as input parameter for jthread_attach(). I think both options should be fine, (1) would probably keep TM interface a bit lighter, though (2) may look more closer to the JNI invocation API idea. So I think adding JavaVM specifically for jthread_attach may make sense given the explanation you provided earlier. The concern I would have regarding the proposed jthread_attach implementation is a call to vm_create_jthread() - this call introduces an extra dependency of TM on vmcore that I'd prefer to be avoided. In the original version, jthread_attach() was taking jthread argument of the already prepared j.l.Thread. I understand your concern. Unfortunately I don't see what we can do here. Let me explain. In the beginning you have an unattached native thread. To be able to call java code (which is required for constructing j.l.Thread instance) the thread should be attached first. To be specific it should be attached to VM by calling vm_attach which will return a valid JNIEnv It is valid to use JNI from that moment. Obtained JNIEnv can be used to execute java code and create j.l.Thread instance. Since we do vm_attach in jthread_attach we need to do vm_create_jthread inside jthread_atach as well. Of course it can be an alternative to do vm_attach and vm_create_jthread outside of TM right before jthread_attach. Sure it will reduce one dependence between VM and TM. But it seems like artificial action for me just because of dependency Why do you think it is artificial? I would rather prefer not to throw vm_attach event from the jthread_attach() call at all than to add extra dependency. The idea of jthread layer is a Java face to hythread, it is meant to know either a little or nothing about the rest of VM. It may be logical to throw vm_attach call from the newly created thread, because there is no other way to let know VM the new thread is created. VM attach is a different case - VM already knows about new Java thread at the time of the AttachCurrentThread call. Do you think it makes sense to replace a single jthread parameter with a variety of stuff (like thread group, name)? It seems the only purpose of at these args is to be passed back to VM for vm_jthread_create(). I would suggest to change this and try doing either of: 1) Make signature of jthread_attach with 3 args, JavaVM, jthread and the daemon. Why do you want to pass daemon to TM but thread's name and group. Just because current TM doesn't need such information? What if it is required to get thread name later? Say by introducing I imagine you need a daemon attribute since the TM is still managing the thread daemonality. TM is not managing thread name and group - they are all kept on the Java level, hence passing them may be excessive. jthread_get_name... What will you do in that case? Let me guess you will call j.l.Thread.getName. Right. Ok! In that case I see no problems to call j.l.Thread.isDaemon. Do you agree? So it doesn't As I suggested earlier, the best way to handle daemonality would probably be in pure Java - in j.l.Thread (or j.l.VMThreadManager) or whatever. You already lifted it up to the jthread level, but what if we can go a little bit higher... seems to be a good design to pass only part of the information to jthread_atach. Lets look at the signature of
Re: [r451637] - Code cleanup - ... - Remove unnecessary comments
If this is an event that should be logged, as the TODO indicated, then
why not just print out the stack trace and be done with it? If this
exception happens so often that you'd like it removed, then why would
we want to log a warning message, which I would presume would print to
the console just as frequently.
As for TODOs, in general I find TODOs never get done, especially
trivial ones like this particular case.
-Nathan
On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Nathan,
I've seen you dropped many TODOs in - Code cleanup - series of commits;
I'd like to know what reasoning was behind this? I think it's a bit
early to erase TODOs without appropriate consideration...
In particular, could you please undo the following change, it produces
garbage messages during AUTH testing:
modules/auth/src/main/java/common/org/apache/harmony/auth/login/DefaultConfigurationParser.java
===
@@ -216,12 +206,12 @@ public class DefaultConfigurationParser
try {
val = PolicyUtils.expand(st.sval, system);
} catch (Exception e) {
- //TODO: warning log
- }
+ e.printStackTrace();
+ }
}
--
WBR,
Alexey
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [r451637] - Code cleanup - ... - Remove unnecessary comments
On 10/4/06, Nathan Beyer wrote:
If this is an event that should be logged, as the TODO indicated, then
why not just print out the stack trace and be done with it? If this
exception happens so often that you'd like it removed, then why would
we want to log a warning message, which I would presume would print to
the console just as frequently.
As for TODOs, in general I find TODOs never get done, especially
trivial ones like this particular case.
I don't agree. TODOs are good hint for making improvements and I'd keep them
in source files.
Thanks,
Stepan.
-Nathan
On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Nathan,
I've seen you dropped many TODOs in - Code cleanup - series of
commits;
I'd like to know what reasoning was behind this? I think it's a bit
early to erase TODOs without appropriate consideration...
In particular, could you please undo the following change, it produces
garbage messages during AUTH testing:
modules/auth/src/main/java/common/org/apache/harmony/auth/login/DefaultConfigurationParser.java
===
@@ -216,12 +206,12 @@ public class DefaultConfigurationParser
try {
val = PolicyUtils.expand(st.sval, system);
} catch (Exception e) {
- //TODO: warning log
- }
+ e.printStackTrace();
+ }
}
--
WBR,
Alexey
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [testing] How to file JIRA issues for impl JUnit tests?
On 10/3/06, Anton Luht wrote: Hello, It's clear how to file issues for public API - write a test with differend behaviour on RI and Harmony. It's not clear how to write tests or report problems when JUnit impl test fail. Hi Anton, At minimum you can just file a JIRA describing a failure and what to do to reproduce it. Or you can try to analyze the failure. In this particular case the test passes on IBM VME and fails on DRL VM. So what the difference is? I'd try to minimize test case to demonstrate the difference and add it to JIRA. Also I'd look to the spec. to understand what the expected result is. Thanks, Stepan. I see org.apache.harmony.security.tests.asn1.der.SequenceTest failing at svn = r452457, (Oct 3 2006), Windows/ia32/msvc 1310, debug build Other people report failures , too : http://www.harmonytest.org/testapp.do?method=showresultid=74663 -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Stepan Mishura 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][jit] possible ABCD bug
On Oct 3, 2006, at 12:29 AM, Egor Pasko wrote: On the 0x1F7 day of Apache Harmony Naveen Neelakantam wrote: Hello Egor, I finally got a chance to read through your code. It is well designed, and correct (as far as I can tell). I especially like the way that the upper bounds solver works as the lower bounds solver simply by flipping a flag (and both operate on the same inequality graph). Very nice! Too many good words for me, cannot handle it)) Thnx :-) 2) Also in updateMemDistanceWithPredecessors, I added an optimization. Essentially, we can take advantage of ProveResult being a lattice (i.e. is monotonic) to prevent some recursive proofs. oh, the optimization is fine, but seems that it would make a suspicious 'Reduced' instead of 'True' sometimes, which still looks like OK for our purposes. It won't give us a big performance gain due to the sparse nature of the inequality graph.. Though, optimizing prematurely makes a lot of fun, so I like it :) I would suggest to move the 'if' statement outside the loop because it is a loop invariant. Elinimanting this 'break' would be a better style. The if statement is not loop invariant because the value of res changes each loop iteration. Am I missing something? As for the break, I can definitely rewrite the loop to get rid of it. One more to say on the patch: +//meetBest(Reduced, x) = Reduced should be: +//meetBest(Reduced, x) = Reduced (just a comment, but still...) so, could you, please, refresh the patch with my suggestions implemented? Will do, once we come to agreement above. Once again, your code is very good. It is also nice that it matches the algorithm outlined in the ABCD paper wherever possible. heh:) did you notice that line 9 of the algorithm? (Figure 5 in the paper). I replaced '' by '', and only after that it worked (classic_abcd_solver.cpp:645). I suppose, it's a bug in the paper. Could you, please, double check this? I did not notice it before, but I agree that the bug is in the paper. Is there something else I can do to help? Yeah, now it's my step. We would do our best if I publish my HIR-Igraph conversion scratches (they don't work yet). Unfortunately, I am so busy with ClassLoaderTest which fails after some seemingly correct optimizations in 'memopt'.. I'll open the sources in a couple of days. Can you wait so long? No worries. I am also working on other things, but would like to try and move this forward whenever possible. What I did: * Created a new optimization pass classic_abcd * moved the Pi insertion logic to a separate Class (and file insertpi.cpp) to reuse it in classic_abcd * to use an Opnd in Inequality Graph like an IOpnd, I made an IOpndProxy : public IOpnd containing an original operand and tweaking here and there to make them have unique ids :) * Started creating Inequality graph (not all info reused, some bugs, crashes, etc.) I would be happy if you look at that code, and finish it up to an initial version while I am stuck with those critical bugz. I can certainly take a look and try to finish it up. Do you have some other ideas how we can collaborate better at this point? I'm happy, so not really. :-) Naveen - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][tools] package name for Keytool tests
Hi, I'm going to add a test for Keytool but I don't know how to name the package for tests: org.apache.harmony.tests.tools.keytool like it is done for javac or org.apache.harmony.tools.keytool.tests like it was decided for classlib? -- Thanks, Anton - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][jit] possible ABCD bug
On the 0x1F8 day of Apache Harmony Naveen Neelakantam wrote: 2) Also in updateMemDistanceWithPredecessors, I added an optimization. Essentially, we can take advantage of ProveResult being a lattice (i.e. is monotonic) to prevent some recursive proofs. oh, the optimization is fine, but seems that it would make a suspicious 'Reduced' instead of 'True' sometimes, which still looks like OK for our purposes. It won't give us a big performance gain due to the sparse nature of the inequality graph.. Though, optimizing prematurely makes a lot of fun, so I like it :) I would suggest to move the 'if' statement outside the loop because it is a loop invariant. Elinimanting this 'break' would be a better style. The if statement is not loop invariant because the value of res changes each loop iteration. Am I missing something? As for the break, I can definitely rewrite the loop to get rid of it. Wait a minute, I need to check if my hair became blond. Now break looks fine. Sorry:) One more to say on the patch: +//meetBest(Reduced, x) = Reduced should be: +//meetBest(Reduced, x) = Reduced (just a comment, but still...) so, could you, please, refresh the patch with my suggestions implemented? Will do, once we come to agreement above. we have it now Once again, your code is very good. It is also nice that it matches the algorithm outlined in the ABCD paper wherever possible. heh:) did you notice that line 9 of the algorithm? (Figure 5 in the paper). I replaced '' by '', and only after that it worked (classic_abcd_solver.cpp:645). I suppose, it's a bug in the paper. Could you, please, double check this? I did not notice it before, but I agree that the bug is in the paper. I love this game :) Is there something else I can do to help? Yeah, now it's my step. We would do our best if I publish my HIR-Igraph conversion scratches (they don't work yet). Unfortunately, I am so busy with ClassLoaderTest which fails after some seemingly correct optimizations in 'memopt'.. I'll open the sources in a couple of days. Can you wait so long? No worries. I am also working on other things, but would like to try and move this forward whenever possible. OK, I'll submit the code this week. Maybe, even tomorrow. (I have some progress on ClassLoaderTest) -- 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]
