Re: [drlvm] Cleaning insides of Class.h header
2006/9/10, Pavel Pervov [EMAIL PROTECTED]: Weldon, one of good examples is static_method_block member variable of struct Class. Its size if calculated, memory is allocated for it, but it is never used throughout the code. Roughly 3K classes loaded in simple Eclipse usage scenario (open Eclipse, create hello, world application, run it, exit Eclipse), which means 3K useless memory allocations are made during this simple run. Heap is fragmented and Visual C runtime has locking on each memory allocation. Regards, Pavel. Pavel, I believe the first step should be re-structuring of this ubiquitous and huge (~1800 lines!) header to several more dedicated ones, and regrouping of other related headers, like class_interface.h and classloader.h. Then we can go with reduction of possible duplicates in interfaces, and optimizing structures layouts and memory usage. What do you think? -- Regards, Alexey On 9/7/06, Weldon Washburn [EMAIL PROTECTED] wrote: Pavel, In general I like the idea of cleaning up this code. Maybe the best thing to do is post some patches so that we have examples to discuss. Weldon On 9/5/06, Pavel Pervov [EMAIL PROTECTED] wrote: It's been long time this discussion stopped. This may mean three things: - first, everyone agrees this should be done and I'm ok to provide consecutive patches; - second, noone clearly understand the purpose of what is suggested to do; if this is the case, do not hesitate to ask (again?); - third, noone is really interested in making source code of DRLVM more readable and more understandable, and I should drop this activity. Meanwhile, I'd like to open jira and start posting patches there. Regards, Pavel. On 7/25/06, Pavel Pervov [EMAIL PROTECTED] wrote: Geir, well, it is the argument at least for me to start thinking in this direction and initiate this discussion. And there are places in VM core code where only definition of members of a class is required, but whole Class.h is included anyway. This is also about localizing potential development in separate functional groups to reduce recompilation when working intensively with these files. Hope, I answered, what you were asking about. :) Regards, Pavel. On 7/24/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Pavel Pervov wrote: On 7/24/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/7/24, Pavel Pervov [EMAIL PROTECTED]: First thing I would like to do is to split the file into a group of files, each of which would contain only one entity (and some closely related entities, if any). This would produce the following headers: 1) Class.h – constant pool and class 2) vtable.h – vtable 3) class_member.h – field and method entities descriptors, exception handler descriptor 4) cci.h – code chunk entity (part of compiled method code) Will these header files be useful separately? Yes, sure, they will be. This is one of the arguments for doing so. To whom? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm]A subject to profiling instrumenting
ok, I think your proposal is good. the bug about profile the aaload is still exist :-( I decide to solve it later.And now i want to implement the profile by sampling. Assign a counter to each BB, if the counter is larger than the threshold, then the original native code of the BB will be replaced by a new native code, which is instrumented with profiling. How do you think my idea? An additional INC, and Branch instruction will be added to each BB. Will it be better than no sampling to profile? I am not sure. 2006/9/8, Mikhail Fursov [EMAIL PROTECTED]: Hi Qiong, I got your files from JIRA and started to learn your changes. I will be ready to test it on Monday. Also I have a proposal: let's choose SVN revision number as the base and post only diffs to this revision to JIRA. How do you think, will it work? Doing this we will minimize the size of the patches? On 9/7/06, zouqiong [EMAIL PROTECTED] wrote: This is the JIRA number. https://issues.apache.org/jira/browse/HARMONY-1406 I upload the vm code, it`s not so large, 3.8 Megabytes. And the code still have bugs when profile the AALOAD. But I am not sure the GETFIELD and GETSTATIC are totally right. :( If you want to profile the AALOAD, please look at the _TEST_ macro in gen_aload() method. And the GETFIELD and GETSTATIC is opened automatically. Now I have the following schedule: 1.First implement the instrument which helps to profile the access patterns 2.Second using sampling to implement the instrument. 2006/9/7, Mikhail Fursov [EMAIL PROTECTED]: On 9/6/06, zouqiong [EMAIL PROTECTED] wrote: Ok, I will put my diffs to the JIRA later. And I have solved the issue I asked two days ago. Ok, I will wait the JIRA number from you. It needs liblwdis.so supporting. Check JIRA 1402 for it. http://issues.apache.org/jira/browse/HARMONY-1402 -- Mikhail Fursov -- Best Regards, Qiong,Zou -- Mikhail Fursov -- Best Regards, Qiong,Zou
Re: [jira] Updated: (HARMONY-1392) Different properties are used to run awt and swing tests
Just to explain, if I build and test with 'with.awt.swing=true' then I don't see any problems with hangs or tests stealing keyboard/mouse events and effectively killing my window manager. The same is *not* true if I set with.awt.swing.tests. I should have called the second variable something else, but that is the reason I used a different variable for the problematic tests. -Mark. On 6 September 2006 at 17:23, Alexey Petrenko [EMAIL PROTECTED] wrote: Both solutions are possible. 2006/9/6, Mikhail Loenko [EMAIL PROTECTED]: Is there a reason to have two different options for classes and for tests? Why not have -Dwith.awt.swing for both? Thanks, Mikhail 2006/9/6, Alexey Petrenko (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1392?page=all ] Alexey Petrenko updated HARMONY-1392: - Attachment: HARMONY-1392.diff Different properties are used to run awt and swing tests Key: HARMONY-1392 URL: http://issues.apache.org/jira/browse/HARMONY-1392 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Petrenko Attachments: HARMONY-1392.diff We need to set different properties to run awt and swing tests. And thi s is wrong. I suggest set with.awt.swing.tests property as for awt. I'll prepare the patch shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: h ttp://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][luni] Upgrade java.lang.Math java.lang.StrictMath
Hi All: There are some newly added methods of class java.lang.Math/java.lang.StrictMath in JDK 1.5(compared with JDK 1.4), but not implemented in Harmony. They are * *method* java.lang.Math.expm1(double): missing in harmony * *method* java.lang.Math.hypot(double, double): missing in harmony * *method* java.lang.Math.log1p(double): missing in harmony * *method* java.lang.Math.signum(double): missing in harmony * *method* java.lang.Math.signum(float): missing in harmony * *method* java.lang.Math.ulp(double): missing in harmony * *method* java.lang.Math.ulp(float): missing in harmony * *method* java.lang.StrictMath.expm1(double): missing in harmony * *method* java.lang.StrictMath.hypot(double, double): missing in harmony * *method* java.lang.StrictMath.log10(double): missing in harmony * *method* java.lang.StrictMath.log1p(double): missing in harmony * *method* java.lang.StrictMath.signum(double): missing in harmony * *method* java.lang.StrictMath.signum(float): missing in harmony * *method* java.lang.StrictMath.ulp(double): missing in harmony * *method* java.lang.StrictMath.ulp(float): missing in harmony I'd like to implement them if no one objects. Best regards -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] Compiler parameterization and using ECJ
On 10 September 2006 at 18:25, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Nathan Beyer wrote: -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Nathan Beyer wrote: I've done some tweaking to the build scripts around compiler usage and wanted to run it by the list for comments, etc. Thanks Nathan. [SNIP] The other big reason to do this is to attempt to use the Eclipse (ECJ) compiler for the build. I've tested using the ECJ by setting the new property and the build and tests work as normal, but I haven't found a way to use the ECJ without manually placing the ECJ JAR in the ANT_HOME\lib folder. As such, I've left the compiler property at 'modern' for now. Ugh. I thought it was working before w/o having to put it in ant/lib, although i don't remember the reason why we took it away. I don't think it was ever working with the Eclipse compiler before, was it? I think so. I think that Mark undid it. Yes. I undid it when we were using the jsr14 hack which didn't work on with ecj - at the time I think it might now. I think we should move forward to use the ecj since it has a cleaner classpath when doing compiles which helps us spot bugs earlier. I'll take a look at making sure the linux build machine is able to build with ecj today. (The windows build machine is broken - I need to move stuff around since it is falling over the windows path length issues.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][i18n] Messages code comments
+1 to condense them into getString(String, Ojbect) by autoboxing. And the getString(String,Object,Object) method can work with primitive arguments also. On 9/11/06, Nathan Beyer [EMAIL PROTECTED] wrote: Is there any reason that there are three overloaded getString(String, XXX) methods that take variations of Object? Can't we just condense this into one method? public static String getString(String key, Object. args) In fact, this signature allows for the getString(String) method to be removed as well, since a vararg argument can be omitted altogether. Additionally, I would change the format method to use a vararg as well. Also, I'd argue that there's little value in having the overloaded methods that take an 'int' and a 'char'. I'd suggest just letting autoboxing handle this in conjunction with the varargs. Where is the code generator for these classes located? -Nathan -- Tony Wu China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HARMONY-1408) [classlib][beans] implementation of ProxyPersistenceDelegate
Alexei Z, do you agree with what Alexey V. suggests?
Thanks,
Mikhail
2006/9/11, Alexey Varlamov (JIRA) [EMAIL PROTECTED]:
[
http://issues.apache.org/jira/browse/HARMONY-1408?page=comments#action_12433782
]
Alexey Varlamov commented on HARMONY-1408:
--
Just a minor notice:
this check:
+// process only if the class differs from Class itself
+if (!((Class) target).getName().equals(java.lang.Class))
{
better replace with:
+// process only if the class differs from Class itself
+if (target != Class.class) {
The latter expression is more correct (invulnerable to name spooffing in custom
classloader) and is much faster.
[classlib][beans] implementation of ProxyPersistenceDelegate
Key: HARMONY-1408
URL: http://issues.apache.org/jira/browse/HARMONY-1408
Project: Harmony
Issue Type: Improvement
Components: Classlib
Environment: ws2003
Reporter: Alexei Zakharov
Attachments: CustomizedPDTest4.patch
The attached patch contains implementation of persistence delegate for all
dynamic proxy objects that can be created by means of the java.lang.reflect.Proxy
class methods. In the process of development of this persistence delegate a few
bugs in Statement and DefaultPersistenceDelegatesFactory were also fixed. After
applying this patch all tests from
org.apache.harmony.beans.tests.java.beans.CustomizedPersistenceDelegateTest will
be enabled so we can remove this class from the exclude list.
Thanks, Alexei
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Upgrade java.lang.Math java.lang.StrictMath
Great news! go ahead :) On 9/11/06, Spark Shen [EMAIL PROTECTED] wrote: Hi All: There are some newly added methods of class java.lang.Math/java.lang.StrictMath in JDK 1.5(compared with JDK 1.4), but not implemented in Harmony. They are * *method* java.lang.Math.expm1(double): missing in harmony * *method* java.lang.Math.hypot(double, double): missing in harmony * *method* java.lang.Math.log1p(double): missing in harmony * *method* java.lang.Math.signum(double): missing in harmony * *method* java.lang.Math.signum(float): missing in harmony * *method* java.lang.Math.ulp(double): missing in harmony * *method* java.lang.Math.ulp(float): missing in harmony * *method* java.lang.StrictMath.expm1(double): missing in harmony * *method* java.lang.StrictMath.hypot(double, double): missing in harmony * *method* java.lang.StrictMath.log10(double): missing in harmony * *method* java.lang.StrictMath.log1p(double): missing in harmony * *method* java.lang.StrictMath.signum(double): missing in harmony * *method* java.lang.StrictMath.signum(float): missing in harmony * *method* java.lang.StrictMath.ulp(double): missing in harmony * *method* java.lang.StrictMath.ulp(float): missing in harmony I'd like to implement them if no one objects. Best regards -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tony Wu China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] putting kernel.jar in jre/bin/default
On 9/11/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/9/11, Geir Magnusson Jr. [EMAIL PROTECTED]: Evgueni Brevnov wrote: On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: There seems to be no easy solution, other than parse LD_LIBRARY_PATH or PATH... Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside in one directory? I was thinking about this for packaging - that way you can have : jre/ bin/ j9/ drlvm/ and setup a symlink if you wish. if we have kernel.jar in jre/lib/boot as we do now, it's must less convenient and probably error prone to switch back and forth. If yes then we can take vmcore.dll base path as a location of kerenel.jar. Sure - where will you get that? and what do you w/ .so's in unix? I've come to the conclusion that the only way will be to manually run the PATH (win) and LD_LIBRARY_PATH (linux) Geir, it seems you are right. I failed to find appropriate solution on Linux. Parsing LD_LIBRARY_PATH can be an option here. Or we can use deployment process to set up application specific environment variable. IIUC, j9 does this in astonishingly simple way - it just specifies -Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar in the vmdir/harmonyvm.properties file, and the launcher does the rest. Namely, it automatically reads that file, replaces %LAUNCHER_HOME% with actual location and feeds extra arguments to VM among user's ones. This solution looks sufficient for now, but it seems to be only partial: it does not work for pure Invocation API usecase. Besides, those hardcoded arguments to VM appear confusing in some cases - e.g. it is impossible to override kernel.jar via command-line. Also note hardcoded default vmdir. As for the .so locations, I'm not sure if there is portable solution (parsing LD_LIBRARY_PATH looks error-prone). Maybe better solution would be leave this to user - for setting JAVA_HOME or such... -- Alexey geir geir Geir Magnusson Jr. wrote: I'll figure this out myself if I don't get a quick answer, but I think we should put the DRLVM kernel classes jar(s) in the same directory as the rest of the DRLVM artifacts so that it's easy to switch between VMs using the launcher. (J9 does this). How does DRLVM decide where to look? (I'm re-doing the DRLVM build to finish integrating the launcher properly, and figure that a nice thing to add is a DRLVM-snapshot that just drops into classlib/deploy/jdk/jre/bin the same way J9 does for developers geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [jira] Commented: (HARMONY-1408) [classlib][beans] implementation of ProxyPersistenceDelegate
Mikhail,
Alexei Z, do you agree with what Alexey V. suggests?
Yes, I've sent the reply to JIRA already, please see below.
Thanks,
Alexei
-- Forwarded message --
From: Alexei Zakharov (JIRA) [EMAIL PROTECTED]
Date: 11.09.2006 13:35
Subject: [jira] Commented: (HARMONY-1408) [classlib][beans]
implementation of ProxyPersistenceDelegate
To: [EMAIL PROTECTED]
[
http://issues.apache.org/jira/browse/HARMONY-1408?page=comments#action_12433809
]
Alexei Zakharov commented on HARMONY-1408:
--
Ok, I agree. In fact I cannot imagine the situation when we've got two
different Class'es loaded by different classloaders. At least there
are no comments in java beans spec on how we should handle such
situations. I think we may also replace
} else if (methodName.equals(newInstance) //$NON-NLS-1$
target instanceof Class
- ((Class) target).getName().equals(
-java.lang.reflect.Array)) { //$NON-NLS-1$
+target == Array.class)) {
Class? componentType = (Class) arguments[0];
earlier in the same method.
Thank you Alexei.
[classlib][beans] implementation of ProxyPersistenceDelegate
Key: HARMONY-1408
URL: http://issues.apache.org/jira/browse/HARMONY-1408
Project: Harmony
Issue Type: Improvement
Components: Classlib
Environment: ws2003
Reporter: Alexei Zakharov
Assigned To: Mikhail Loenko
Attachments: CustomizedPDTest4.patch
The attached patch contains implementation of persistence delegate for all
dynamic proxy objects that can be created by means of the
java.lang.reflect.Proxy class methods. In the process of development of this
persistence delegate a few bugs in Statement and
DefaultPersistenceDelegatesFactory were also fixed. After applying this patch
all tests from
org.apache.harmony.beans.tests.java.beans.CustomizedPersistenceDelegateTest
will be enabled so we can remove this class from the exclude list.
Thanks, Alexei
--
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
--
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] putting kernel.jar in jre/bin/default
2006/9/11, Evgueni Brevnov [EMAIL PROTECTED]:
On 9/11/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/9/11, Geir Magnusson Jr. [EMAIL PROTECTED]:
Evgueni Brevnov wrote:
On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
There seems to be no easy solution, other than parse LD_LIBRARY_PATH or
PATH...
Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside
in one directory?
I was thinking about this for packaging - that way you can have :
jre/
bin/
j9/
drlvm/
and setup a symlink if you wish.
if we have kernel.jar in jre/lib/boot as we do now, it's must less
convenient and probably error prone to switch back and forth.
If yes then we can take vmcore.dll base path as a
location of kerenel.jar.
Sure - where will you get that? and what do you w/ .so's in unix? I've
come to the conclusion that the only way will be to manually run the
PATH (win) and LD_LIBRARY_PATH (linux)
Geir, it seems you are right. I failed to find appropriate solution on
Linux. Parsing LD_LIBRARY_PATH can be an option here. Or we can use
deployment process to set up application specific environment
variable.
Well, with a bit of googling I've managed to obtain the following snippet [1]:
if (dladdr( addr, info ) != 0)
{
strncpy( path, info.dli_fname, PATH_MAX );
*(strrchr( path, '/' )) = '\0';
}
The dladdr() function shall query the dynamic linker for information
about the shared object containing the address addr. [2]
Moreover, google reports about dladdr in a variety of manuals,
including BSD, SGI, MacOS, Solaris etc, I've listed some of the links
below.
So this looks like a silver bullet for us :)
[1] http://lists.trolltech.com/qt-interest/2003-11/msg00380.html
[2]
http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/baselib-dladdr-3.html
[3]
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/dladdr.3.html
[4] http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr4c?a=view
IIUC, j9 does this in astonishingly simple way - it just specifies
-Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar in the
vmdir/harmonyvm.properties file, and the launcher does the rest.
Namely, it automatically reads that file, replaces %LAUNCHER_HOME%
with actual location and feeds extra arguments to VM among user's
ones.
This solution looks sufficient for now, but it seems to be only
partial: it does not work for pure Invocation API usecase. Besides,
those hardcoded arguments to VM appear confusing in some cases - e.g.
it is impossible to override kernel.jar via command-line. Also note
hardcoded default vmdir.
As for the .so locations, I'm not sure if there is portable solution
(parsing LD_LIBRARY_PATH looks error-prone). Maybe better solution
would be leave this to user - for setting JAVA_HOME or such...
--
Alexey
geir
geir
Geir Magnusson Jr. wrote:
I'll figure this out myself if I don't get a quick answer, but I think
we should put the DRLVM kernel classes jar(s) in the same directory as
the rest of the DRLVM artifacts so that it's easy to switch between VMs
using the launcher. (J9 does this).
How does DRLVM decide where to look?
(I'm re-doing the DRLVM build to finish integrating the launcher
properly, and figure that a nice thing to add is a DRLVM-snapshot that
just drops into classlib/deploy/jdk/jre/bin the same way J9 does for
developers
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Re: [drlvm] putting kernel.jar in jre/bin/default
Alexey Varlamov wrote: 2006/9/11, Geir Magnusson Jr. [EMAIL PROTECTED]: Evgueni Brevnov wrote: On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: There seems to be no easy solution, other than parse LD_LIBRARY_PATH or PATH... Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside in one directory? I was thinking about this for packaging - that way you can have : jre/ bin/ j9/ drlvm/ and setup a symlink if you wish. if we have kernel.jar in jre/lib/boot as we do now, it's must less convenient and probably error prone to switch back and forth. If yes then we can take vmcore.dll base path as a location of kerenel.jar. Sure - where will you get that? and what do you w/ .so's in unix? I've come to the conclusion that the only way will be to manually run the PATH (win) and LD_LIBRARY_PATH (linux) IIUC, j9 does this in astonishingly simple way - it just specifies -Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar in the vmdir/harmonyvm.properties file, and the launcher does the rest. Namely, it automatically reads that file, replaces %LAUNCHER_HOME% with actual location and feeds extra arguments to VM among user's ones. This solution looks sufficient for now, but it seems to be only partial: it does not work for pure Invocation API usecase.Besides,those hardcoded arguments to VM appear confusing in some cases - e.g. it is impossible to override kernel.jar via command-line. Is it necessary to override the kernel.jar via command-line? The kernel class is provided by VM, so it is natural to locate it by VM specific property file. Also note hardcoded default vmdir. Agree, default should be replaced by some variables(%vmdir% or so), so it is easier to move VME to another directory. As for the .so locations, I'm not sure if there is portable solution (parsing LD_LIBRARY_PATH looks error-prone). Maybe better solution would be leave this to user - for setting JAVA_HOME or such... -- Alexey -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Upgrade java.lang.Math java.lang.StrictMath
Tony Wu 写道: Great news! go ahead :) On 9/11/06, Spark Shen [EMAIL PROTECTED] wrote: Hi All: There are some newly added methods of class java.lang.Math/java.lang.StrictMath in JDK 1.5(compared with JDK 1.4), but not implemented in Harmony. They are * *method* java.lang.Math.expm1(double): missing in harmony * *method* java.lang.Math.hypot(double, double): missing in harmony * *method* java.lang.Math.log1p(double): missing in harmony * *method* java.lang.Math.signum(double): missing in harmony * *method* java.lang.Math.signum(float): missing in harmony * *method* java.lang.Math.ulp(double): missing in harmony * *method* java.lang.Math.ulp(float): missing in harmony * *method* java.lang.StrictMath.expm1(double): missing in harmony * *method* java.lang.StrictMath.hypot(double, double): missing in harmony * *method* java.lang.StrictMath.log10(double): missing in harmony * *method* java.lang.StrictMath.log1p(double): missing in harmony * *method* java.lang.StrictMath.signum(double): missing in harmony * *method* java.lang.StrictMath.signum(float): missing in harmony * *method* java.lang.StrictMath.ulp(double): missing in harmony * *method* java.lang.StrictMath.ulp(float): missing in harmony I'd like to implement them if no one objects. Best regards -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Great! And I just notice that you have already put up HARMONY-1415, HARMONY-1399, HARMONY-1388 about these two classes. They look good. :-) -- Robert Hu China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] putting kernel.jar in jre/bin/default
Alexey Varlamov wrote: 2006/9/11, Geir Magnusson Jr. [EMAIL PROTECTED]: Evgueni Brevnov wrote: If yes then we can take vmcore.dll base path as a location of kerenel.jar. Sure - where will you get that? and what do you w/ .so's in unix? I've come to the conclusion that the only way will be to manually run the PATH (win) and LD_LIBRARY_PATH (linux) IIUC, j9 does this in astonishingly simple way - it just specifies -Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar in the vmdir/harmonyvm.properties file, and the launcher does the rest. Namely, it automatically reads that file, replaces %LAUNCHER_HOME% with actual location and feeds extra arguments to VM among user's ones. This solution looks sufficient for now, but it seems to be only partial: it does not work for pure Invocation API usecase. Besides, those hardcoded arguments to VM appear confusing in some cases - e.g. it is impossible to override kernel.jar via command-line. Also note hardcoded default vmdir. Ok, this makes sense. Yes, the default is a problem. However, if a little is good, more is better we could also add another env var like LAUNCHER_HOME like VM_DIR so -Xbootclasspath/p:%LAUNCHER_HOME%/%VM_DIR%/ so that we can at least put it in /j9 and /drlvm - the goal here is to be able to install both at the same time to make it easy to A/B test things. And yes, this is problematic as you noted... As for the .so locations, I'm not sure if there is portable solution (parsing LD_LIBRARY_PATH looks error-prone). Maybe better solution would be leave this to user - for setting JAVA_HOME or such... Yes, LD_LIBRARY_PATH is going to be error-prone, but it's how other resources are found - using apr_dso_load() on linux just defers to dlopen(), which uses LD_LIBRARY_PATH. geir -- Alexey geir geir Geir Magnusson Jr. wrote: I'll figure this out myself if I don't get a quick answer, but I think we should put the DRLVM kernel classes jar(s) in the same directory as the rest of the DRLVM artifacts so that it's easy to switch between VMs using the launcher. (J9 does this). How does DRLVM decide where to look? (I'm re-doing the DRLVM build to finish integrating the launcher properly, and figure that a nice thing to add is a DRLVM-snapshot that just drops into classlib/deploy/jdk/jre/bin the same way J9 does for developers geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] putting kernel.jar in jre/bin/default
2006/9/11, Paulex Yang [EMAIL PROTECTED]: Alexey Varlamov wrote: 2006/9/11, Geir Magnusson Jr. [EMAIL PROTECTED]: Evgueni Brevnov wrote: On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: There seems to be no easy solution, other than parse LD_LIBRARY_PATH or PATH... Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside in one directory? I was thinking about this for packaging - that way you can have : jre/ bin/ j9/ drlvm/ and setup a symlink if you wish. if we have kernel.jar in jre/lib/boot as we do now, it's must less convenient and probably error prone to switch back and forth. If yes then we can take vmcore.dll base path as a location of kerenel.jar. Sure - where will you get that? and what do you w/ .so's in unix? I've come to the conclusion that the only way will be to manually run the PATH (win) and LD_LIBRARY_PATH (linux) IIUC, j9 does this in astonishingly simple way - it just specifies -Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar in the vmdir/harmonyvm.properties file, and the launcher does the rest. Namely, it automatically reads that file, replaces %LAUNCHER_HOME% with actual location and feeds extra arguments to VM among user's ones. This solution looks sufficient for now, but it seems to be only partial: it does not work for pure Invocation API usecase.Besides,those hardcoded arguments to VM appear confusing in some cases - e.g. it is impossible to override kernel.jar via command-line. Is it necessary to override the kernel.jar via command-line? The kernel class is provided by VM, so it is natural to locate it by VM specific property file. The first example which came to mind, how could you instrument the kernel classes, say for coverage analysis by emma or custom profiling? I'm sure there are more usecases, but anyway this is generally adopted behaviour and not following it may be far more disappointing than exception message incompatibility which we care so much ;) Also note hardcoded default vmdir. Agree, default should be replaced by some variables(%vmdir% or so), so it is easier to move VME to another directory. OK, I will file a JIRA for this. -- Regards, 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][luni] Upgrade java.lang.Math java.lang.StrictMath
Robert Hu 写道: Tony Wu 写道: Great news! go ahead :) On 9/11/06, Spark Shen [EMAIL PROTECTED] wrote: Hi All: There are some newly added methods of class java.lang.Math/java.lang.StrictMath in JDK 1.5(compared with JDK 1.4), but not implemented in Harmony. They are * *method* java.lang.Math.expm1(double): missing in harmony * *method* java.lang.Math.hypot(double, double): missing in harmony * *method* java.lang.Math.log1p(double): missing in harmony * *method* java.lang.Math.signum(double): missing in harmony * *method* java.lang.Math.signum(float): missing in harmony * *method* java.lang.Math.ulp(double): missing in harmony * *method* java.lang.Math.ulp(float): missing in harmony * *method* java.lang.StrictMath.expm1(double): missing in harmony * *method* java.lang.StrictMath.hypot(double, double): missing in harmony * *method* java.lang.StrictMath.log10(double): missing in harmony * *method* java.lang.StrictMath.log1p(double): missing in harmony * *method* java.lang.StrictMath.signum(double): missing in harmony * *method* java.lang.StrictMath.signum(float): missing in harmony * *method* java.lang.StrictMath.ulp(double): missing in harmony * *method* java.lang.StrictMath.ulp(float): missing in harmony I'd like to implement them if no one objects. Best regards -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Great! And I just notice that you have already put up HARMONY-1415, HARMONY-1399, HARMONY-1388 about these two classes. They look good. :-) Ha Ha, nice watch, thank you. Best regards -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] putting kernel.jar in jre/bin/default
On 9/11/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/9/11, Evgueni Brevnov [EMAIL PROTECTED]:
On 9/11/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/9/11, Geir Magnusson Jr. [EMAIL PROTECTED]:
Evgueni Brevnov wrote:
On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
There seems to be no easy solution, other than parse LD_LIBRARY_PATH or
PATH...
Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside
in one directory?
I was thinking about this for packaging - that way you can have :
jre/
bin/
j9/
drlvm/
and setup a symlink if you wish.
if we have kernel.jar in jre/lib/boot as we do now, it's must less
convenient and probably error prone to switch back and forth.
If yes then we can take vmcore.dll base path as a
location of kerenel.jar.
Sure - where will you get that? and what do you w/ .so's in unix? I've
come to the conclusion that the only way will be to manually run the
PATH (win) and LD_LIBRARY_PATH (linux)
Geir, it seems you are right. I failed to find appropriate solution on
Linux. Parsing LD_LIBRARY_PATH can be an option here. Or we can use
deployment process to set up application specific environment
variable.
Well, with a bit of googling I've managed to obtain the following snippet [1]:
if (dladdr( addr, info ) != 0)
{
strncpy( path, info.dli_fname, PATH_MAX );
*(strrchr( path, '/' )) = '\0';
}
The dladdr() function shall query the dynamic linker for information
about the shared object containing the address addr. [2]
Moreover, google reports about dladdr in a variety of manuals,
including BSD, SGI, MacOS, Solaris etc, I've listed some of the links
below.
So this looks like a silver bullet for us :)
Great! It should work for us. With this approach it is possible not to
depend on LD_LIBRARY_PATH and PATH at all.
[1] http://lists.trolltech.com/qt-interest/2003-11/msg00380.html
[2]
http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/baselib-dladdr-3.html
[3]
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/dladdr.3.html
[4] http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr4c?a=view
IIUC, j9 does this in astonishingly simple way - it just specifies
-Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar in the
vmdir/harmonyvm.properties file, and the launcher does the rest.
Namely, it automatically reads that file, replaces %LAUNCHER_HOME%
with actual location and feeds extra arguments to VM among user's
ones.
This solution looks sufficient for now, but it seems to be only
partial: it does not work for pure Invocation API usecase. Besides,
those hardcoded arguments to VM appear confusing in some cases - e.g.
it is impossible to override kernel.jar via command-line. Also note
hardcoded default vmdir.
As for the .so locations, I'm not sure if there is portable solution
(parsing LD_LIBRARY_PATH looks error-prone). Maybe better solution
would be leave this to user - for setting JAVA_HOME or such...
--
Alexey
geir
geir
Geir Magnusson Jr. wrote:
I'll figure this out myself if I don't get a quick answer, but I
think
we should put the DRLVM kernel classes jar(s) in the same directory
as
the rest of the DRLVM artifacts so that it's easy to switch between
VMs
using the launcher. (J9 does this).
How does DRLVM decide where to look?
(I'm re-doing the DRLVM build to finish integrating the launcher
properly, and figure that a nice thing to add is a DRLVM-snapshot
that
just drops into classlib/deploy/jdk/jre/bin the same way J9 does for
developers
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail:
Re: [classlib][i18n] Messages code comments
Hello, Nathan! Thank you for taking a deep look at the i18n task!! I try to comment inline... On 9/11/06, Nathan Beyer [EMAIL PROTECTED] wrote: Is there any reason that there are three overloaded getString(String, XXX) methods that take variations of Object? Actually, source code for the Messages class was taken (it was discussed at the threads of internationalization issues) from the existing o.a.h.luni.util.Msg and o.a.h.luni.util.MsgHelp classes. I'm not the author of mentioned classses but I assume that three overloaded getString() methods were designed to increase performance of the common used messages calls. Can't we just condense this into one method? public static String getString(String key, Object. args) I worried for the performance, however, I ran several small tests with existing Messages implementation and with Java 5.0 variable arguments feature usage and didn't see the big difference in performance. Condensing all these methods in one seems to me a good idea. In fact, this signature allows for the getString(String) method to be removed as well, since a vararg argument can be omitted altogether. Additionally, I would change the format method to use a vararg as well. All enhancements are welcomed!! Also, I'd argue that there's little value in having the overloaded methods that take an 'int' and a 'char'. I'd suggest just letting autoboxing handle this in conjunction with the varargs. Where is the code generator for these classes located? Take a look at the HARMONY-1041issue, all sources for the i18n classes generator are available there. If you want to improve Messages class code - you just need to modify Messages template file. Regards, Ilya. -Nathan -- -- Ilya Okomin Intel Middleware Products Division
[classlib][awt] Can't start any AWT app after recent(9/9/06-11/9/06) changes in java.awt
Hi all! After checking out the latest classlib from SVN I get this NPE on any AWT app start: java.lang.NullPointerException at java.awt.ToolkitImpl.getSystemEventQueueImpl(ToolkitImpl.java:525) at java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:58) at java.awt.EventDispatchThread.run(EventDispatchThread.java:47) Tried both with DRLVM and IBM j9 on Windows. Anybody has the same problem? I'll try to investigate it, but maybe somebody has an idea of what's going on? Dmitry A. Durnev, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HARMONY-1392) Different properties are used to run awt and swing tests
Mark, I did not get your point... What is the problem with the same property for both awt and swing tests? I understand that we need to set dome property to run them since we got problems with building awt native libraries and do not want them while usual run. But why we need different properties for one task: run hidden tests? SY, Alexey 2006/9/11, Mark Hindess [EMAIL PROTECTED]: Just to explain, if I build and test with 'with.awt.swing=true' then I don't see any problems with hangs or tests stealing keyboard/mouse events and effectively killing my window manager. The same is *not* true if I set with.awt.swing.tests. I should have called the second variable something else, but that is the reason I used a different variable for the problematic tests. -Mark. On 6 September 2006 at 17:23, Alexey Petrenko [EMAIL PROTECTED] wrote: Both solutions are possible. 2006/9/6, Mikhail Loenko [EMAIL PROTECTED]: Is there a reason to have two different options for classes and for tests? Why not have -Dwith.awt.swing for both? Thanks, Mikhail 2006/9/6, Alexey Petrenko (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1392?page=all ] Alexey Petrenko updated HARMONY-1392: - Attachment: HARMONY-1392.diff Different properties are used to run awt and swing tests Key: HARMONY-1392 URL: http://issues.apache.org/jira/browse/HARMONY-1392 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Petrenko Attachments: HARMONY-1392.diff We need to set different properties to run awt and swing tests. And thi s is wrong. I suggest set with.awt.swing.tests property as for awt. I'll prepare the patch shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: h ttp://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: [classlib][TestNG] groups of Harmony test
Hi all, One more note (seems it already was said sorry if I repeat): the test without any marks should be run in all configurations (i.e. we have 'default' group but declaration of this group may be missed). I'd like to point your attention on the previous discussion about default groups : http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] I am still for using os.any since it is more self-descriptive and the build script will be simpler with os.any. It will be nice to hear more arguments for using defaults because it seems the arguments that were gathered in that old thread hasn't been taken into account by participants of this thread. Thanks, 2006/9/5, Vladimir Ivanov [EMAIL PROTECTED]: One more note (seems it already was said sorry if I repeat): the test without any marks should be run in all configurations (i.e. we have 'default' group but declaration of this group may be missed). thanks, Vladimir On 9/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: OK, let's return back to the usage model. If I understood it correctly, before the commit of any changes each developer run *all* tests (at least all which we have now) on all available to him platforms. In this context seems we don't need in any 'level' group (while 'stress' tests require reasonable time to pass). Seems, that platform group also can be deleted (at present time we have 10 platform-dependent tests and this amount should not increase dramatically so the platform-detection can be included to the each such test). Also cpu groups can be deleted (while we have not cpu-dependent test). At the end we need only state groups to support test exclusion on the 'one-element' level (while we have unresolved entries in the current exclude list). So, after small update of unit (aka integration, aka regression etc) tests and resolution of all entries in the exclude list we don't need any groups and pure JUnit covers all our needs :) On the other side, if we define some groups it will nice to define *all* reasonable groups at the begin of the process. thanks, Vladimir By the way, our regression tests are 'classic' regression tests that demonstrate some issues which were not resolved by initial code. But it provides less coverage than 'regression tests' + unit tests, of cause. On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote: If you've got fast and slow tests, then have a group for fast and slow tests. Then you can choose to just run the fast tests, and any automated build system can handle running the slow tests. IMHO, fast or slow may not be the key point. The question is whether we have any requirements to run only the regression tests. No, probably not the key point, but (a) groups don't have to be mutually exclusive (so you can decorate it with whatever groups you want) I agree. For example, os.win and os.linux are not mutually exclusive. Thanks a lot. and (b) it might be useful for an automated build system to run fast tests first, followed by slow (or non-fast) tests. That makes sense through we have not clear requirement currently. Mind you, I don't know what's going to happen with an automated test'n'build system; so it might not make sense to do it at this point. Really? ;-) We could also discuss whether it's feasible to move to TestNG. As you may know, there are already several threads about TestNG JUnit. Here I just review the open questions one by one so that we have sufficient preparation. [1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [2]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [3]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] Best regards, Richard Alex. -- 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: [jira] Updated: (HARMONY-1392) Different properties are used to run awt and swing tests
On 11 September 2006 at 16:29, Alexey Petrenko [EMAIL PROTECTED] wrote: Mark, I did not get your point... What is the problem with the same property for both awt and swing tests? I understand that we need to set dome property to run them since we got problems with building awt native libraries and do not want them while usual run. But why we need different properties for one task: run hidden tests? I mean that 'with.awt.swing.tests' as it is currently used should really be called 'run.tests.that.might.kill.your.xsession' - for me at least. Ideally I'd like to fix the dependency issues and the tests and have no extra variables. ;-) Part of the problem is that I don't really know which tests are interfering with my window manager... because when I run the tests I can no longer type anything and it doesn't seem to happen 100% of the time so my attempt to use a binary chop to find the problematic tests didn't work. I will try to narrow it down again but I was hoping someone who knew the code better might have an idea what might cause focus to be stolen by the tests. -Mark. SY, Alexey 2006/9/11, Mark Hindess [EMAIL PROTECTED]: Just to explain, if I build and test with 'with.awt.swing=true' then I don't see any problems with hangs or tests stealing keyboard/mouse events and effectively killing my window manager. The same is *not* true if I set with.awt.swing.tests. I should have called the second variable something else, but that is the reason I used a different variable for the problematic tests. -Mark. On 6 September 2006 at 17:23, Alexey Petrenko [EMAIL PROTECTED] wrote: Both solutions are possible. 2006/9/6, Mikhail Loenko [EMAIL PROTECTED]: Is there a reason to have two different options for classes and for tes ts? Why not have -Dwith.awt.swing for both? Thanks, Mikhail 2006/9/6, Alexey Petrenko (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1392?page=all ] Alexey Petrenko updated HARMONY-1392: - Attachment: HARMONY-1392.diff Different properties are used to run awt and swing tests Key: HARMONY-1392 URL: http://issues.apache.org/jira/browse/HARMONY-1 392 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Petrenko Attachments: HARMONY-1392.diff We need to set different properties to run awt and swing tests. And thi s is wrong. I suggest set with.awt.swing.tests property as for awt. I'll prepare the patch shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrator s: h ttp://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/ jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] Can't start any AWT app after recent(9/9/06-11/9/06) changes in java.awt
Same problem on linux. -Mark. On 11 September 2006 at 15:12, Dmitry Durnev [EMAIL PROTECTED] wrote: Hi all! After checking out the latest classlib from SVN I get this NPE on any AWT app start: java.lang.NullPointerException at java.awt.ToolkitImpl.getSystemEventQueueImpl(ToolkitImpl.java:525) at java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:5 8) at java.awt.EventDispatchThread.run(EventDispatchThread.java:47) Tried both with DRLVM and IBM j9 on Windows. Anybody has the same problem? I'll try to investigate it, but maybe somebody has an idea of what's going on ? Dmitry A. Durnev, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HARMONY-1392) Different properties are used to run awt and swing tests
I think that the focus could be stolen when the test opens new window. There is also number of tests which are test focus switching... 2006/9/11, Mark Hindess [EMAIL PROTECTED]: On 11 September 2006 at 16:29, Alexey Petrenko [EMAIL PROTECTED] wrote: Mark, I did not get your point... What is the problem with the same property for both awt and swing tests? I understand that we need to set dome property to run them since we got problems with building awt native libraries and do not want them while usual run. But why we need different properties for one task: run hidden tests? I mean that 'with.awt.swing.tests' as it is currently used should really be called 'run.tests.that.might.kill.your.xsession' - for me at least. Ideally I'd like to fix the dependency issues and the tests and have no extra variables. ;-) Part of the problem is that I don't really know which tests are interfering with my window manager... because when I run the tests I can no longer type anything and it doesn't seem to happen 100% of the time so my attempt to use a binary chop to find the problematic tests didn't work. I will try to narrow it down again but I was hoping someone who knew the code better might have an idea what might cause focus to be stolen by the tests. -Mark. SY, Alexey 2006/9/11, Mark Hindess [EMAIL PROTECTED]: Just to explain, if I build and test with 'with.awt.swing=true' then I don't see any problems with hangs or tests stealing keyboard/mouse events and effectively killing my window manager. The same is *not* true if I set with.awt.swing.tests. I should have called the second variable something else, but that is the reason I used a different variable for the problematic tests. -Mark. On 6 September 2006 at 17:23, Alexey Petrenko [EMAIL PROTECTED] wrote: Both solutions are possible. 2006/9/6, Mikhail Loenko [EMAIL PROTECTED]: Is there a reason to have two different options for classes and for tes ts? Why not have -Dwith.awt.swing for both? Thanks, Mikhail 2006/9/6, Alexey Petrenko (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1392?page=all ] Alexey Petrenko updated HARMONY-1392: - Attachment: HARMONY-1392.diff Different properties are used to run awt and swing tests Key: HARMONY-1392 URL: http://issues.apache.org/jira/browse/HARMONY-1 392 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Petrenko Attachments: HARMONY-1392.diff We need to set different properties to run awt and swing tests. And thi s is wrong. I suggest set with.awt.swing.tests property as for awt. I'll prepare the patch shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrator s: h ttp://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/ jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] Can't start any AWT app after recent(9/9/06-11/9/06) changes in java.awt
I've already found the cause of the problem. In short: creation of system EventQueue was commented out in Toolkit constructor because of the local variable is never read compiler warning :) Variable itself is indeed not used, but the constructor call has some important side effects... Will file a JIRA and offer a patch:) On 9/11/06, Dmitry Durnev [EMAIL PROTECTED] wrote: Hi all! After checking out the latest classlib from SVN I get this NPE on any AWT app start: java.lang.NullPointerException at java.awt.ToolkitImpl.getSystemEventQueueImpl(ToolkitImpl.java:525) at java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:58) at java.awt.EventDispatchThread.run(EventDispatchThread.java:47) Tried both with DRLVM and IBM j9 on Windows. Anybody has the same problem? I'll try to investigate it, but maybe somebody has an idea of what's going on? Dmitry A. Durnev, Intel Middleware Products Division -- Dmitry A. Durnev, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][awt] Can't start any AWT app after recent(9/9/06-11/9/06) changes in java.awt
If variable is not used later in the code probably it will be better just to call constructor? Without assigning the value to the variable... 2006/9/11, Dmitry Durnev [EMAIL PROTECTED]: I've already found the cause of the problem. In short: creation of system EventQueue was commented out in Toolkit constructor because of the local variable is never read compiler warning :) Variable itself is indeed not used, but the constructor call has some important side effects... Will file a JIRA and offer a patch:) On 9/11/06, Dmitry Durnev [EMAIL PROTECTED] wrote: Hi all! After checking out the latest classlib from SVN I get this NPE on any AWT app start: java.lang.NullPointerException at java.awt.ToolkitImpl.getSystemEventQueueImpl(ToolkitImpl.java:525) at java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:58) at java.awt.EventDispatchThread.run(EventDispatchThread.java:47) Tried both with DRLVM and IBM j9 on Windows. Anybody has the same problem? I'll try to investigate it, but maybe somebody has an idea of what's going on? Dmitry A. Durnev, Intel Middleware Products Division -- Dmitry A. Durnev, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] Can't start any AWT app after recent(9/9/06-11/9/06) changes in java.awt
Of course, I'll remove the confusing variable... On 9/11/06, Alexey Petrenko [EMAIL PROTECTED] wrote: If variable is not used later in the code probably it will be better just to call constructor? Without assigning the value to the variable... -- Dmitry A. Durnev, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: [classlib][TestNG] groups of Harmony test
On 9/11/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Hi all,
One more note (seems it already was said sorry if I repeat): the test
without any marks should be run in all configurations (i.e. we have
'default' group but declaration of this group may be missed).
I'd like to point your attention on the previous discussion about
default groups :
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
I am still for using os.any since it is more self-descriptive and
the build script will be simpler with os.any. It will be nice to
hear more arguments for using defaults because it seems the arguments
that were gathered in that old thread hasn't been taken into account
by participants of this thread.
I have not any strong objection about os.any. And actually I had
ever proposed to define the default group because we could not
include tests with annotation @Test which belong to no groups. Now it
isn't a problem as we already have a solution for them. To facilitate
writing test cases, we annotate the unit tests which are designed to
pass on all platforms (os + arch) with @Test.
If we use os.any and arch.any, then the default annotation would
be @Test(groups={os.any, arch.any})
Could any other give more comments? Thanks a lot.
Best regards,
Richard
Thanks,
2006/9/5, Vladimir Ivanov [EMAIL PROTECTED]:
One more note (seems it already was said sorry if I repeat): the test
without any marks should be run in all configurations (i.e. we have
'default' group but declaration of this group may be missed).
thanks, Vladimir
On 9/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
OK, let's return back to the usage model.
If I understood it correctly, before the commit of any changes each
developer run *all* tests (at least all which we have now) on all available
to him platforms. In this context seems we don't need in any 'level' group
(while 'stress' tests require reasonable time to pass).
Seems, that platform group also can be deleted (at present time we have
10 platform-dependent tests and this amount should not increase
dramatically so the platform-detection can be included to the each such
test).
Also cpu groups can be deleted (while we have not cpu-dependent test).
At the end we need only state groups to support test exclusion on the
'one-element' level (while we have unresolved entries in the current exclude
list).
So, after small update of unit (aka integration, aka regression etc) tests
and resolution of all entries in the exclude list we don't need any groups
and pure JUnit covers all our needs :)
On the other side, if we define some groups it will nice to define *all*
reasonable groups at the begin of the process.
thanks, Vladimir
By the way, our regression tests are 'classic' regression tests that
demonstrate some issues which were not resolved by initial code. But it
provides less coverage than 'regression tests' + unit tests, of cause.
On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote:
On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote:
If you've got fast and slow tests, then have a group for fast and
slow
tests. Then you can choose to just run the fast tests, and any
automated build system can handle running the slow tests.
IMHO, fast or slow may not be the key point. The question is
whether we
have any requirements to run only the regression tests.
No, probably not the key point, but (a) groups don't have to be
mutually exclusive (so you can decorate it with whatever groups you
want)
I agree. For example, os.win and os.linux are not mutually exclusive.
Thanks a lot.
and (b) it might be useful for an automated build system to run
fast tests first, followed by slow (or non-fast) tests.
That makes sense through we have not clear requirement currently.
Mind you, I don't know what's going to happen with an automated
test'n'build
system; so it might not make sense to do it at this point.
Really? ;-) We could also discuss whether it's feasible to move to
TestNG. As you may know, there are already several threads about
TestNG JUnit. Here I just review the open questions one by one so
that we have sufficient preparation.
[1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
[2]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
[3]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
Best regards,
Richard
Alex.
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use :
Re: [classlib] [ldap] reuse of security parser
Hi Daniel, Yes, the parser used by 'security' code put some restrictions on distinguished names (see [1]) and IMO it is a good idea to try to improve the parser to make it possible to reuse it by 'jndi' module. When we developed security code we also thought about creating a common 'engine' for parsing distinguished names that can be extended by 'security' and 'ldap' code. But because of time limit we put off developing such 'engine' for a while. It is great to hear that you work on completing 'ldap' public API and I think that it is time to return this. As I understood you the current parser suits for 'ldap' code and can be used as common 'engine' for both modules (only minor updates are required, like changing visibility attributes). Then I think the best way is to submit a patch to JIRA and discuss it. And if we'll find out later that more updates are required then IMO we should think about redesigning the parser code. Thoughts? Ideas? Thanks, Stepan. [1] http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/x500/X500Principal.html On 9/9/06, Daniel Gandara wrote: Hi all, as you know at the ITC we are working to complete javax.naming.ldap package v 1.5. We are currently implementing the 1.5 classes and I have one question regarding the reuse of an already donated code from other package (org.apache.harmony.security.x509). The specific issue is as follow: in order to implement the classes LdapName and Rdn -from javax.naming.ldap- we need a Distinguished Name parser that parses according to the bnf syntax specified in RFC2253 and RFC1779. We've found a DNParser class in the package org.apache.harmony.security.x509 we could re-use, but it checks for valid AttributeTypes by looking in a table of valid OIDs. What we need is a less restrictive parser that allows types that do not have a valid OID. We could easily implement this behavior extending from this class and rewriting the specific functionality; but we would have to change some methods and attributes visibility of DNParser and AttributeTypeAndValue from private to protected. The specific question is: should we made this change on the security package and submit it with our contribution? or should we ask for this change to be made by the ones who wrote the security package? I'll wait for feedback, Thanks, Daniel -- 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: [result] Re: [vote] HARMONY-1363 - DRLVM fixes and additions
On 9/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: +1 from Geir, Alexey V, Vladimir, Mikhail L, Mikhail F, Gregory I'd have preferred a third committer, +1 based on a a quick scan of the source code. I did an svn update about 12 hours ago. Then a patch -p1 -i BBC.patch. The build failed. Right now I am trying to revert to an old revision of drlvm/trunk that will take the patch. Sorry for responding so late. With all the traffic on harmony-dev, I somehow overlooked this email chain. but as it is a set of patches and enhancements to an existing codebase, and there was no opposition, I think we're ok. geir Geir Magnusson Jr. wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. I think that this an important patch so we can get better 1.5 support et al. Please vote to accept or reject this set of patches and fixes into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. 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] -- Weldon Washburn Intel Middleware Products Division
Re: Re: Re: [classlib][TestNG] groups of Harmony test
On 9/11/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/11/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Hi all,
One more note (seems it already was said sorry if I repeat): the test
without any marks should be run in all configurations (i.e. we have
'default' group but declaration of this group may be missed).
I'd like to point your attention on the previous discussion about
default groups :
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
I am still for using os.any since it is more self-descriptive and
the build script will be simpler with os.any. It will be nice to
hear more arguments for using defaults because it seems the arguments
that were gathered in that old thread hasn't been taken into account
by participants of this thread.
I have not any strong objection about os.any. And actually I had
ever proposed to define the default group because we could not
include tests with annotation @Test which belong to no groups. Now it
isn't a problem as we already have a solution for them. To facilitate
writing test cases, we annotate the unit tests which are designed to
pass on all platforms (os + arch) with @Test.
If we use os.any and arch.any, then the default annotation would
be @Test(groups={os.any, arch.any})
Could any other give more comments? Thanks a lot.
Either is ok. One is more descriptive while the other is more convenient.
If we have no problem to write test.xml with default group(@Test), then I
prefer this option a little. Thanks!
Best regards,
Richard
Thanks,
2006/9/5, Vladimir Ivanov [EMAIL PROTECTED]:
One more note (seems it already was said sorry if I repeat): the test
without any marks should be run in all configurations (i.e. we have
'default' group but declaration of this group may be missed).
thanks, Vladimir
On 9/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
OK, let's return back to the usage model.
If I understood it correctly, before the commit of any changes each
developer run *all* tests (at least all which we have now) on all
available
to him platforms. In this context seems we don't need in any 'level'
group
(while 'stress' tests require reasonable time to pass).
Seems, that platform group also can be deleted (at present time we
have
10 platform-dependent tests and this amount should not increase
dramatically so the platform-detection can be included to the each
such
test).
Also cpu groups can be deleted (while we have not cpu-dependent
test).
At the end we need only state groups to support test exclusion on
the
'one-element' level (while we have unresolved entries in the current
exclude
list).
So, after small update of unit (aka integration, aka regression etc)
tests
and resolution of all entries in the exclude list we don't need any
groups
and pure JUnit covers all our needs :)
On the other side, if we define some groups it will nice to define
*all*
reasonable groups at the begin of the process.
thanks, Vladimir
By the way, our regression tests are 'classic' regression tests that
demonstrate some issues which were not resolved by initial code. But
it
provides less coverage than 'regression tests' + unit tests, of
cause.
On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote:
On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote:
If you've got fast and slow tests, then have a group for
fast and
slow
tests. Then you can choose to just run the fast tests, and
any
automated build system can handle running the slow tests.
IMHO, fast or slow may not be the key point. The question is
whether we
have any requirements to run only the regression tests.
No, probably not the key point, but (a) groups don't have to be
mutually exclusive (so you can decorate it with whatever groups
you
want)
I agree. For example, os.win and os.linux are not mutually
exclusive.
Thanks a lot.
and (b) it might be useful for an automated build system to run
fast tests first, followed by slow (or non-fast) tests.
That makes sense through we have not clear requirement currently.
Mind you, I don't know what's going to happen with an automated
test'n'build
system; so it might not make sense to do it at this point.
Really? ;-) We could also discuss whether it's feasible to move to
TestNG. As you may know, there are already several threads about
TestNG JUnit. Here I just review the open questions one by one
so
that we have sufficient preparation.
[1]http://mail-
archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
[2]http://mail-
archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
Re: [drlvm] Cleaning insides of Class.h header
On 9/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/9/10, Pavel Pervov [EMAIL PROTECTED]: Weldon, one of good examples is static_method_block member variable of struct Class. Its size if calculated, memory is allocated for it, but it is never used throughout the code. Roughly 3K classes loaded in simple Eclipse usage scenario (open Eclipse, create hello, world application, run it, exit Eclipse), which means 3K useless memory allocations are made during this simple run. Heap is fragmented and Visual C runtime has locking on each memory allocation. Regards, Pavel. Pavel, I believe the first step should be re-structuring of this ubiquitous and huge (~1800 lines!) header to several more dedicated ones, and regrouping of other related headers, like class_interface.h and classloader.h. Then we can go with reduction of possible duplicates in interfaces, and optimizing structures layouts and memory usage. What do you think? This works also! In any case, please attempt to break the work into several stages. -- Regards, Alexey On 9/7/06, Weldon Washburn [EMAIL PROTECTED] wrote: Pavel, In general I like the idea of cleaning up this code. Maybe the best thing to do is post some patches so that we have examples to discuss. Weldon On 9/5/06, Pavel Pervov [EMAIL PROTECTED] wrote: It's been long time this discussion stopped. This may mean three things: - first, everyone agrees this should be done and I'm ok to provide consecutive patches; - second, noone clearly understand the purpose of what is suggested to do; if this is the case, do not hesitate to ask (again?); - third, noone is really interested in making source code of DRLVM more readable and more understandable, and I should drop this activity. Meanwhile, I'd like to open jira and start posting patches there. Regards, Pavel. On 7/25/06, Pavel Pervov [EMAIL PROTECTED] wrote: Geir, well, it is the argument at least for me to start thinking in this direction and initiate this discussion. And there are places in VM core code where only definition of members of a class is required, but whole Class.h is included anyway. This is also about localizing potential development in separate functional groups to reduce recompilation when working intensively with these files. Hope, I answered, what you were asking about. :) Regards, Pavel. On 7/24/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Pavel Pervov wrote: On 7/24/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/7/24, Pavel Pervov [EMAIL PROTECTED]: First thing I would like to do is to split the file into a group of files, each of which would contain only one entity (and some closely related entities, if any). This would produce the following headers: 1) Class.h – constant pool and class 2) vtable.h – vtable 3) class_member.h – field and method entities descriptors, exception handler descriptor 4) cci.h – code chunk entity (part of compiled method code) Will these header files be useful separately? Yes, sure, they will be. This is one of the arguments for doing so. To whom? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division
[DRLVM][GC] first batch of files for GCv5, a preliminary trace-forward copying collector
Hi, folks, to follow up the GCv5 proposal, I submitted the early files of a copying collector for GCv5. The idea is to develop GCv5 openly in Harmony, so that we can develop it togother. Any comments or improvements are welcome. The JIRA issue I created is HARMONY-1428 as the message below. It has no document associated, since it's too early and unstable for serious document efforts; but I think it is simple and concise enough for any people who are interested in GC development. Thanks, xiaofeng -- Forwarded message -- From: Xiao-Feng Li (JIRA) [EMAIL PROTECTED] Date: Sep 11, 2006 11:20 PM Subject: [jira] Created: (HARMONY-1428) [DRLVM] first batch of files for GCv5, a trace-forward copying collector To: [EMAIL PROTECTED] [DRLVM] first batch of files for GCv5, a trace-forward copying collector Key: HARMONY-1428 URL: http://issues.apache.org/jira/browse/HARMONY-1428 Project: Harmony Issue Type: Improvement Components: DRLVM Environment: These files were only tested on Windows with VS.NET 2003. Reporter: Xiao-Feng Li This archive has a couple of files implementing an early version of a trace-forward copying collector for GCv5. It's only a starter with very basic functionalities. It is a generational GC reqiures write barrier implemented in JIT. It was tested with JET, and ran SPECJBB2000 and SPECJVM98. The algorithm is depth-first tracing of From-space, and forwarding live objects to To-space (It can forward part of the From-space). The To-space has no real management except for the accomodation of forwarded objects and large objects. So the To-space is going to be replaced by a mark-compaction GC, and the large objects will be managed by a LOS GC. In order to minimize the changes to other components of DRLVM, the codes here comply with the original contract between GCv4 and other components. I also borrowed some routine code from GCv4 to avoid repetitive labor work. GCv5 is under active development, so please expect quick and big changes to this submitted code base. I will submit new codes from time to time when they are worth a submission. Any comments or codes are more than welcome. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][GC] first batch of files for GCv5, a preliminary trace-forward copying collector
On 9/11/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Hi, folks, to follow up the GCv5 proposal, I submitted the early files of a copying collector for GCv5. The idea is to develop GCv5 openly in Harmony, so that we can develop it togother. Any comments or improvements are welcome. The JIRA issue I created is HARMONY-1428 as the message below. It has no document associated, since it's too early and unstable for serious document efforts; but I think it is simple and concise enough for any people who are interested in GC development. Good. I will take a look. Thanks for the update. Thanks, xiaofeng -- Forwarded message -- From: Xiao-Feng Li (JIRA) [EMAIL PROTECTED] Date: Sep 11, 2006 11:20 PM Subject: [jira] Created: (HARMONY-1428) [DRLVM] first batch of files for GCv5, a trace-forward copying collector To: [EMAIL PROTECTED] [DRLVM] first batch of files for GCv5, a trace-forward copying collector Key: HARMONY-1428 URL: http://issues.apache.org/jira/browse/HARMONY-1428 Project: Harmony Issue Type: Improvement Components: DRLVM Environment: These files were only tested on Windows with VS.NET2003. Reporter: Xiao-Feng Li This archive has a couple of files implementing an early version of a trace-forward copying collector for GCv5. It's only a starter with very basic functionalities. It is a generational GC reqiures write barrier implemented in JIT. It was tested with JET, and ran SPECJBB2000 and SPECJVM98. The algorithm is depth-first tracing of From-space, and forwarding live objects to To-space (It can forward part of the From-space). The To-space has no real management except for the accomodation of forwarded objects and large objects. So the To-space is going to be replaced by a mark-compaction GC, and the large objects will be managed by a LOS GC. In order to minimize the changes to other components of DRLVM, the codes here comply with the original contract between GCv4 and other components. I also borrowed some routine code from GCv4 to avoid repetitive labor work. GCv5 is under active development, so please expect quick and big changes to this submitted code base. I will submit new codes from time to time when they are worth a submission. Any comments or codes are more than welcome. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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: [build] Compiler parameterization and using ECJ
Yeah, that's why I'm hoping someone who's more an Ant expert has a way of
changing the environment to dynamically add the ECJ JAR. We
I don't pretend to be an ant guru but I think the following solution
should work:
!-- set up ecj --
property name=ecj.jar
value=C:\valid path to ecj\ecj_3.2.jar/
property name=ecj.batch.class
value=org.eclipse.jdt.internal.compiler.batch.Main/
tempfile property=javac.batch suffix=.bat destdir=build/
condition property=javac.script.content
value=%JAVA_HOME%\bin\java -cp ${ecj.jar} ${ecj.batch.class} %*
os family=Windows/
/condition
condition property=javac.script.content
value=-- unix stuff goes here --
os family=unix/
/condition
!-- Compile! --
echo message=${javac.script.content} file=${javac.batch}/
javac destdir=${build.output}
... [blah blah blah] ...
fork=yes
executable=${javac.batch}
includeAntRuntime=no
Let's call it temporary batch file solution.
Regards,
2006/9/11, Nathan Beyer [EMAIL PROTECTED]:
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Nathan Beyer wrote:
I've done some tweaking to the build scripts around compiler usage and
wanted to run it by the list for comments, etc.
* I've removed the -showversion JVM argument from the module build
scripts that were using it when executing the tests. The launcher
behavior
changed a bit here, so this isn't working with the IBM VME yet. This can
be
added back later. Note: this wasn't consistently being used in all
scripts
prior to this change.
right - I don't think it's much of a loss to not have it, but we'll put
it back as soon as we can.
* Following the lead of other 'javac' properties configured in the
/make/properties.xml file, I've added a 'hy.javac.compiler' property
that is
used by the scripts to set the 'compiler' property on 'javac' tasks.
Currently, this is just set to 'modern' to maintain the previous
behavior.
Why didn't you make it hy.jc.cr? Seriously. Would it have killed you
to put in the armon?
Personally, I would prefer that, but in this case I was just trying to be
consistent. All of the other javac properties are prefixed with
hy.javac.XXX.
[SNIP]
The other big reason to do this is to attempt to use the Eclipse (ECJ)
compiler for the build. I've tested using the ECJ by setting the new
property and the build and tests work as normal, but I haven't found a
way
to use the ECJ without manually placing the ECJ JAR in the ANT_HOME\lib
folder. As such, I've left the compiler property at 'modern' for now.
Ugh. I thought it was working before w/o having to put it in ant/lib,
although i don't remember the reason why we took it away.
I don't think it was ever working with the Eclipse compiler before, was it?
I'd like to permanently set the compiler property to use the ECJ v3.2,
but
this will seemingly break the build if Ant isn't setup properly. Does
anyone have any objections to using ECJ as the standard compiler? Since
Harmony will use this as it's 'javac', I believe it would be proper for
Harmony to be built with the same compiler.
That's fine, but I think we should solve the problem of where ECJ should
be. Having to dork w/ ant itself seems wrong.
Yeah, that's why I'm hoping someone who's more an Ant expert has a way of
changing the environment to dynamically add the ECJ JAR. We use 'ant' tasks
from the top build script to call the dependant scripts, but I haven't found
any documentation or examples that change Ant's classpath this way.
Does anyone know of any means of dynamically setting up Ant with ECJ?
One
thought I had was an extension to 'fetch-depends' that copies ECJ to
ANT_HOME\lib for builders. I'm not sure if that would be considered
desirable behavior.
No - I don't think we should alter peoples working environments like that.
Can we make it automatic for now? if it detects ECJ it uses it,
otherwise uses Sun? (But then we still have the problem with the latest
Sun compiler, don't we...)
geir
-Nathan
--
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: [result] Re: [vote] HARMONY-1363 - DRLVM fixes and additions
Thanks - but don't commit it :) I'm working on that here on the plane... -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 -Original Message- From: Weldon Washburn [mailto:[EMAIL PROTECTED] Sent: Monday, September 11, 2006 10:37 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [result] Re: [vote] HARMONY-1363 - DRLVM fixes and additions On 9/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: +1 from Geir, Alexey V, Vladimir, Mikhail L, Mikhail F, Gregory I'd have preferred a third committer, +1 based on a a quick scan of the source code. I did an svn update about 12 hours ago. Then a patch -p1 -i BBC.patch. The build failed. Right now I am trying to revert to an old revision of drlvm/trunk that will take the patch. Sorry for responding so late. With all the traffic on harmony-dev, I somehow overlooked this email chain. but as it is a set of patches and enhancements to an existing codebase, and there was no opposition, I think we're ok. geir Geir Magnusson Jr. wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. I think that this an important patch so we can get better 1.5 support et al. Please vote to accept or reject this set of patches and fixes into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. 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] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][GC] first batch of files for GCv5, a preliminary trace-forward copying collector
Thanks Xiao Feng. Weldon, are you going to put it somewhere like drlvm/trunk/vm/gcv5 if there are no objections? Thanks, Rana
Re: [DRLVM][GC] first batch of files for GCv5, a preliminary trace-forward copying collector
On 9/11/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Thanks Xiao Feng. Weldon, are you going to put it somewhere like drlvm/trunk/vm/gcv5 if there are no objections? This is my thinking exactly. But before this happens, I need to call for a vote. Thanks, Rana -- Weldon Washburn Intel Middleware Products Division
[classlib] recent build fails on Windows
Could anybody please explain me why the classlib build fails on Windows platform as follows: ... [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -FIsehmap.h-D_X 86_=1 -DWIN32 -D_WIN32 -W3 -D_WIN95 -D_WIN32_WINDOWS=0x0400 /D_WIN32_DCOM -D_WI N32_IE=0x0500 -DWINVER=0x0400 -Ogityb1 -W3 -GF -Gs -MD -Zi -Zm400 -D_DLL -D_MT -DWIN32 -D_WIN32_WINNT=0x0400 -D_WINSOCKAPI_ -DWINVER=0x0400 /IC:\DrlSrc\classlib\trunk\deploy\include /IC:\DrlSrc\classlib\trunk\deploy\jdk\include /I. -FoWinDataTransfer.obj WinDataTransfer.cpp [exec] Microsoft (R) Program Maintenance Utility Version 7.10.3077 [exec] Copyright (C) Microsoft Corporation. All rights reserved. [exec] WinDataTransfer.cpp [exec] WinDataTransfer.cpp(22) : fatal error C1083: Cannot open include file: 'atlbase.h': No such file or directory [exec] NMAKE : fatal error U1077: 'cl' : return code '0x2' [exec] Stop. How can I resolve this issue? Thanks in advance, Vladimir.
Re: [classlib] recent build fails on Windows
It fails because you should add path to MS ALTMFC library to your INCLUDE and LIB variables. You can set this variables by vcvars32.bat from MSVC installation. SY, Alexey 2006/9/12, Vladimir Gorr [EMAIL PROTECTED]: Could anybody please explain me why the classlib build fails on Windows platform as follows: ... [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -FIsehmap.h-D_X 86_=1 -DWIN32 -D_WIN32 -W3 -D_WIN95 -D_WIN32_WINDOWS=0x0400 /D_WIN32_DCOM -D_WI N32_IE=0x0500 -DWINVER=0x0400 -Ogityb1 -W3 -GF -Gs -MD -Zi -Zm400 -D_DLL -D_MT -DWIN32 -D_WIN32_WINNT=0x0400 -D_WINSOCKAPI_ -DWINVER=0x0400 /IC:\DrlSrc\classlib\trunk\deploy\include /IC:\DrlSrc\classlib\trunk\deploy\jdk\include /I. -FoWinDataTransfer.obj WinDataTransfer.cpp [exec] Microsoft (R) Program Maintenance Utility Version 7.10.3077 [exec] Copyright (C) Microsoft Corporation. All rights reserved. [exec] WinDataTransfer.cpp [exec] WinDataTransfer.cpp(22) : fatal error C1083: Cannot open include file: 'atlbase.h': No such file or directory [exec] NMAKE : fatal error U1077: 'cl' : return code '0x2' [exec] Stop. How can I resolve this issue? Thanks in advance, Vladimir. -- 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] recent build fails on Windows
Thanks, Alexey, it helped. Vladimir. On 9/12/06, Alexey Petrenko [EMAIL PROTECTED] wrote: It fails because you should add path to MS ALTMFC library to your INCLUDE and LIB variables. You can set this variables by vcvars32.bat from MSVC installation. SY, Alexey 2006/9/12, Vladimir Gorr [EMAIL PROTECTED]: Could anybody please explain me why the classlib build fails on Windows platform as follows: ... [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo - FIsehmap.h-D_X 86_=1 -DWIN32 -D_WIN32 -W3 -D_WIN95 -D_WIN32_WINDOWS=0x0400 /D_WIN32_DCOM -D_WI N32_IE=0x0500 -DWINVER=0x0400 -Ogityb1 -W3 -GF -Gs -MD -Zi -Zm400 -D_DLL -D_MT -DWIN32 -D_WIN32_WINNT=0x0400 -D_WINSOCKAPI_ -DWINVER=0x0400 /IC:\DrlSrc\classlib\trunk\deploy\include /IC:\DrlSrc\classlib\trunk\deploy\jdk\include /I. -FoWinDataTransfer.obj WinDataTransfer.cpp [exec] Microsoft (R) Program Maintenance Utility Version 7.10.3077 [exec] Copyright (C) Microsoft Corporation. All rights reserved. [exec] WinDataTransfer.cpp [exec] WinDataTransfer.cpp(22) : fatal error C1083: Cannot open include file: 'atlbase.h': No such file or directory [exec] NMAKE : fatal error U1077: 'cl' : return code '0x2' [exec] Stop. How can I resolve this issue? Thanks in advance, Vladimir. -- 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]
