Re: [testing] new subcomponent of Harmony?
Mark, Does it make sense to add the test coverage script into the step 3), as the tools in Harmony-564? Mark Hindess wrote: On 8 June 2006 at 8:01, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Interesting. I wasn't thinking of having unit or implementation tests in here, as those still should be near the subcomponent, be it VM, classlib, etc, but larger 'end-to-end' functional tests ? I don't know if that makes sense... I was originally hoping that Mark would tell us what he has running over at IBM, and let us start from there.. .:) (Sorry, I have been distracted looking at jchevm, the classlibadapter, and trying to grok the drlvm build system.) We have two machines running continuum, one linux and one windows, with a wrapper project in a local svn repository that pulls in classlib using svn:externals. It contains an ant script that does: 1) Call the classlib ant file to build with a reference JDK. 2) Call the classlib ant file to build with IBM VME, classlib and Eclipse (this was disabled due to jsr14 issues but could be enabled again now I think). 3) Call the classlib ant file to Run the tests 4) Publish the results and update an index.html file. The linux machine also has a few more steps between 3 and 4: 3a) Run JAPI tools 3b) Generate class list for the newly-built JRE and then produce a report of the class coverage with respect to some reference applications - the tools for this (slightly edited) are in HARMONY-565 I'd be happy to share this wrapper though it'll need a little tidying up first. 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] -- 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] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
Great! Is it possible to see uncovered classes/methods/lines? Thanks, Mikhail P.S. I think java.awt does not currently belong to beans module, though who knows what the future may bring us :) 2006/6/13, Vladimir Ivanov [EMAIL PROTECTED]: Latest Harmony API source coverage by Harmony API unit tests results I stored at wiki page http://wiki.apache.org/harmony/Coverage_information I'm going to refresh it bi-weekly (seems, it is enough for coverage). I think we have got a agreement on the test naming convention[1], but for sure, there have been many (legacy) test cases before this agreement, and I think the volunteer is highly welcome to provide patch for them. [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html If nobody objects I'm going to look through the unit tests to correct package names according to the agreement (where needed). Thanks, Vladimir On 6/8/06, Paulex Yang [EMAIL PROTECTED] wrote: Vladimir, Vladimir Ivanov wrote: Thanks Paulex! I did the same, but could not send results due to spam filter J Observations: 1. Coverage results look pretty much similar. 2. Exclude list looks pretty much similar too, but, looks like it depends on the way of data collection (I didn't run ant task and the list is a little bit different). Great. In any case, I think, when we run harmony on another VM exclude list will have to be updated. May be we can start publishing the coverage information on wiki pages and provide some updates time to time (I can do it)? +1, and of course, you can only if no one in the mailing list objects and you'll have my welcome, and I think it will be even greater if these reports can be generated regularly like what JAPI is doing:) One note: I noticed that different unit tests have very different package names Now the directory with all built tests copied to one place looks like: I think we have got a agreement on the test naming convention[1], but for sure, there have been many (legacy) test cases before this agreement, and I think the volunteer is highly welcome to provide patch for them. [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html C:\coverage\tests\testls GZIPOutClose2.txtapi config javax tests GZIPOutFinish.txtapi.injected dazzle orgxml GZIPOutWrite.txt binarygifprefs Inet6Address.golden.ser bundles impl serialization JDK2-3gabba.zip com impl.injected test.txt I think, it would be good if tests had unified package names. Why? – so far, just common sense, just to have an order in test suite Organization (if consider all unit tests as solid test suite). Thanks, Vladimir For example, my exclude list for java.io is: -java.io.BufferedInputStream , -java.io.BufferedOutputStream, -java.io.File , -java.io.FileChannelFactory, -java.io.FileDescriptor, -java.io.FileInputStream, -java.io.FileOutputStream, -java.io.FilterInputStream , -java.io.FilterOutputStream, - java.io.InputStream, -java.io.OutputStream, -java.io.ObjectStreamField, -java.io.PrintStream On 6/6/06, Paulex Yang [EMAIL PROTECTED] wrote: I've attach the scripts and excluded class lists to JIRA, please refer to https://issues.apache.org/jira/browse/HARMONY-564 . Enjoy it:). Mark Hindess wrote: On 2 June 2006 at 10:37, Paulex Yang [EMAIL PROTECTED] wrote: Mark, I'm glad that there is someone else has interest on emma, I've tried it before. AFAIK, emma works by instrumentation, but sometimes for classes in bootclasspath, the instrumentation cannot work, there are two cases: 1. Some instrumented classes cannot be loaded by VM. 2. Some classes cannot be instrumented I have tried to look more inside to find some way to work around but I haven't got enough time yet. Specifically for nio-channel module, I had a list for these two cases (I believe the data is a little outdated and should be reevaluated) case 1. BaseByteBuffer.class Buffer.class BufferFactory.class ByteBuffer.class CharArrayBuffer.class CharBuffer.class HeapByteBuffer.class ReadWriteCharArrayBuffer.class ReadWriteHeapByteBuffer.class FileChannel.class AbstractInterruptibleChannel.class FileChannelImpl.class WriteOnlyFileChannel.class LockManager.class LockManager$1.class ReadOnlyFileChannel.class case 2: ByteChannel.class Channel.class GatheringByteChannel.class InterruptibleChannel.class WritableByteChannel.class And I have got some ant script and more excluded list for emma, if anyone has interests, I can upload it to JIRA. Yes! -Mark. Mark Hindess wrote: Anyone tried using emma (emma.sf.net) to look at test coverage
Re: [announce] New Apache Harmony Committer : Mark Hindess
Belated congratulations Mark ! -- George Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Mark Hindess. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and some amazing ability in creating build systems :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r413531 - /incubator/harmony/enhanced/classlib/trunk/modules/beans/src/main/java/java/beans/FeatureDescriptor.java
Nathan Beyer wrote: -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] snip They are not quite equivalent, since the code above enumerates over the actual 'values' keySet. If code calling attributeNames() removes a value they are removing it from the FeatureDescriptor's private HashMap variable, which is probably not what we want. Creating a new collection (Vector) of the values protects the code from that. The method returns an Enumeration though and there's no method for removing items from an Enumeration. Oops, you are right (I was thinking of an Iterator), but the keySet can be modified by setValue(String,Object) so copying the keys provides some stability if callers are setting values while enumerating. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using mx4j for javax.management
I created a JIRA about this issue, see: https://issues.apache.org/jira/browse/HARMONY-560 There is a patch attached if anyone wants to test it. The license is at: http://mx4j.sourceforge.net/docs/ch01s06.html Any thoughts or comments about whether this is a reasonable thing to do? 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] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
The detailed info available at http://viv.byethost15.com/ (this address also pointed on wiki-page). Do you need additional information ? Thanks, Vladimir On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Great! Is it possible to see uncovered classes/methods/lines? Thanks, Mikhail P.S. I think java.awt does not currently belong to beans module, though who knows what the future may bring us :) 2006/6/13, Vladimir Ivanov [EMAIL PROTECTED]: Latest Harmony API source coverage by Harmony API unit tests results I stored at wiki page http://wiki.apache.org/harmony/Coverage_information I'm going to refresh it bi-weekly (seems, it is enough for coverage). I think we have got a agreement on the test naming convention[1], but for sure, there have been many (legacy) test cases before this agreement, and I think the volunteer is highly welcome to provide patch for them. [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html If nobody objects I'm going to look through the unit tests to correct package names according to the agreement (where needed). Thanks, Vladimir On 6/8/06, Paulex Yang [EMAIL PROTECTED] wrote: Vladimir, Vladimir Ivanov wrote: Thanks Paulex! I did the same, but could not send results due to spam filter J Observations: 1. Coverage results look pretty much similar. 2. Exclude list looks pretty much similar too, but, looks like it depends on the way of data collection (I didn't run ant task and the list is a little bit different). Great. In any case, I think, when we run harmony on another VM exclude list will have to be updated. May be we can start publishing the coverage information on wiki pages and provide some updates time to time (I can do it)? +1, and of course, you can only if no one in the mailing list objects and you'll have my welcome, and I think it will be even greater if these reports can be generated regularly like what JAPI is doing:) One note: I noticed that different unit tests have very different package names Now the directory with all built tests copied to one place looks like: I think we have got a agreement on the test naming convention[1], but for sure, there have been many (legacy) test cases before this agreement, and I think the volunteer is highly welcome to provide patch for them. [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html C:\coverage\tests\testls GZIPOutClose2.txtapi config javax tests GZIPOutFinish.txtapi.injected dazzle orgxml GZIPOutWrite.txt binarygifprefs Inet6Address.golden.ser bundles impl serialization JDK2-3gabba.zip com impl.injected test.txt I think, it would be good if tests had unified package names. Why? – so far, just common sense, just to have an order in test suite Organization (if consider all unit tests as solid test suite). Thanks, Vladimir For example, my exclude list for java.io is: -java.io.BufferedInputStream , -java.io.BufferedOutputStream, -java.io.File , -java.io.FileChannelFactory, -java.io.FileDescriptor, -java.io.FileInputStream, -java.io.FileOutputStream, -java.io.FilterInputStream , -java.io.FilterOutputStream, - java.io.InputStream, -java.io.OutputStream, -java.io.ObjectStreamField, -java.io.PrintStream On 6/6/06, Paulex Yang [EMAIL PROTECTED] wrote: I've attach the scripts and excluded class lists to JIRA, please refer to https://issues.apache.org/jira/browse/HARMONY-564 . Enjoy it:). Mark Hindess wrote: On 2 June 2006 at 10:37, Paulex Yang [EMAIL PROTECTED] wrote: Mark, I'm glad that there is someone else has interest on emma, I've tried it before. AFAIK, emma works by instrumentation, but sometimes for classes in bootclasspath, the instrumentation cannot work, there are two cases: 1. Some instrumented classes cannot be loaded by VM. 2. Some classes cannot be instrumented I have tried to look more inside to find some way to work around but I haven't got enough time yet. Specifically for nio-channel module, I had a list for these two cases (I believe the data is a little outdated and should be reevaluated) case 1. BaseByteBuffer.class Buffer.class BufferFactory.class ByteBuffer.class CharArrayBuffer.class CharBuffer.class HeapByteBuffer.class ReadWriteCharArrayBuffer.class ReadWriteHeapByteBuffer.class FileChannel.class AbstractInterruptibleChannel.class FileChannelImpl.class WriteOnlyFileChannel.class LockManager.class LockManager$1.class ReadOnlyFileChannel.class case 2: ByteChannel.class
Re: [DRLVM] one more gc
Weldon, Thank you, for your interest. The main idea of the implementation is just education of myself. I wanted to start with train algorithm to better understand its pros and cons. I didn't supposed to stick with that algorithm. Moreover, when just starting the implementation I noticed some potential performance issues. This made me reevaluate the idea and move further. Of cause, it is possible to take working implementation or jump into the best solution, but thus I will make no decision my self and will not know whole picture of possible solutions. Btw, I have found small performance improvement to GCv4 which can be easily added to it. Well, I'm going to do this development just for education and to extend my own horizon. It can be done here or privately. Either variant is acceptable for me. -- Ivan On 6/13/06, Weldon Washburn [EMAIL PROTECTED] wrote: Ivan, Please note that two guys who worked for me on ORP (http://orp.sourceforge.net/ ) spent 2-3 years building and tuning the train algorithm. We could never get the performance to acceptable level. Ultimately we ditched the train algorithm and built GCV4 in less than 3 months. GCV4 was never finished. I suspect other VM builders also experimented with the train algorithm and abandoned it. As far as I know, there are no production or research MRTEs containing the train algorithm. Also note there is already a complete implementation of the train algorithm in Apache compatible licensed open source. Look for orp-1.0.10.tgz on http://sourceforge.net/projects/orp ). The train algorithm is contained in the directory gc_v2. Since the GC/VM interface has not evolved much in the transition from ORP to DRLVM, it should be an easy port. This port would be interesting for two reasons: a) A teaching tool to show why/where the train algorithm fails. Tony Printezis and Richard Jones wrote an excellent paper that used GCspy to graphically demonstrate where the train algorithm falls down. Look for, GCspy: An Adaptable Heap Visualization Framework by Tony Printezis and Richard Jones, (http://www.cs.kent.ac.uk/pubs/2002/1426/index.html ). Also look for, (http://research.sun.com/projects/gcspy/printezis-garthwaite-ismm2002.pdf ), Visualizing the Train Garbage Collector. It might be interesting to hook up GCV2 and GCspy to harmonydrlvm and reproduce this paper. This would calibrate GCspy for future harmonydrlvm work. b) GC_V2 really stressed the write barrier subsystem. (GCV2 does a substantial amount of object copying.) If GC_V2 can be ported quickly, it might be a good stepping stone to getting MMTk going. On 6/9/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: While some works going on to properly integrate DRLVM in harmony build system... I would like to start development of new garbage collector. I know about Weldon's work related to MMTk. I am not sure that it is the right way. Instead of doing GC based on java, I would concentrate on the one written in C. I think that the VM written in C (or C++ ) should have GC written the same way. I have some experience in garbage collectors (stop-the-world ones for now) and want to extend my knowledge in this area. That is one of the reasons I want to make the GC, but do not port the existing one. I hope I will eventually produce something which is better then existing implementations or at least a few new ideas. I would like to start implementing something similar to Train algorithm, then possibly modify it in direction to Garbage First collector. I want to create something with high performance and low pauses. At the beginning it will not even compile. I do not expect this to be interesting to anyone for some time, but as Geir always suggests I going to do this in public to avoid surprises. All required VM functionality (for GC written in C) is already in place. DRLVM's interfaces for GC is ok for me and should be quite portable. Write barriers implementation is already in place, suitable for C-based Gc: (Harmony-504 (me), Harmony-581 (Ming Wu)). As I don't have commiter account, I going to create one JIRA and start to fill it with patches. In the patches I will create directory enhanced/drlvm/trunk/vm/gcx and will start to fill it with stubs and implementation. I am going to do it mostly at spare time. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
Cool! Sorry, I've missed it One more thing I've missed: what is the exclude list you've finally ended with? Thanks, Mikhail 2006/6/13, Vladimir Ivanov [EMAIL PROTECTED]: The detailed info available at http://viv.byethost15.com/ (this address also pointed on wiki-page). Do you need additional information ? Thanks, Vladimir On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Great! Is it possible to see uncovered classes/methods/lines? Thanks, Mikhail P.S. I think java.awt does not currently belong to beans module, though who knows what the future may bring us :) 2006/6/13, Vladimir Ivanov [EMAIL PROTECTED]: Latest Harmony API source coverage by Harmony API unit tests results I stored at wiki page http://wiki.apache.org/harmony/Coverage_information I'm going to refresh it bi-weekly (seems, it is enough for coverage). I think we have got a agreement on the test naming convention[1], but for sure, there have been many (legacy) test cases before this agreement, and I think the volunteer is highly welcome to provide patch for them. [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html If nobody objects I'm going to look through the unit tests to correct package names according to the agreement (where needed). Thanks, Vladimir On 6/8/06, Paulex Yang [EMAIL PROTECTED] wrote: Vladimir, Vladimir Ivanov wrote: Thanks Paulex! I did the same, but could not send results due to spam filter J Observations: 1. Coverage results look pretty much similar. 2. Exclude list looks pretty much similar too, but, looks like it depends on the way of data collection (I didn't run ant task and the list is a little bit different). Great. In any case, I think, when we run harmony on another VM exclude list will have to be updated. May be we can start publishing the coverage information on wiki pages and provide some updates time to time (I can do it)? +1, and of course, you can only if no one in the mailing list objects and you'll have my welcome, and I think it will be even greater if these reports can be generated regularly like what JAPI is doing:) One note: I noticed that different unit tests have very different package names Now the directory with all built tests copied to one place looks like: I think we have got a agreement on the test naming convention[1], but for sure, there have been many (legacy) test cases before this agreement, and I think the volunteer is highly welcome to provide patch for them. [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html C:\coverage\tests\testls GZIPOutClose2.txtapi config javax tests GZIPOutFinish.txtapi.injected dazzle orgxml GZIPOutWrite.txt binarygifprefs Inet6Address.golden.ser bundles impl serialization JDK2-3gabba.zip com impl.injected test.txt I think, it would be good if tests had unified package names. Why? – so far, just common sense, just to have an order in test suite Organization (if consider all unit tests as solid test suite). Thanks, Vladimir For example, my exclude list for java.io is: -java.io.BufferedInputStream , -java.io.BufferedOutputStream, -java.io.File , -java.io.FileChannelFactory, -java.io.FileDescriptor, -java.io.FileInputStream, -java.io.FileOutputStream, -java.io.FilterInputStream , -java.io.FilterOutputStream, - java.io.InputStream, -java.io.OutputStream, -java.io.ObjectStreamField, -java.io.PrintStream On 6/6/06, Paulex Yang [EMAIL PROTECTED] wrote: I've attach the scripts and excluded class lists to JIRA, please refer to https://issues.apache.org/jira/browse/HARMONY-564 . Enjoy it:). Mark Hindess wrote: On 2 June 2006 at 10:37, Paulex Yang [EMAIL PROTECTED] wrote: Mark, I'm glad that there is someone else has interest on emma, I've tried it before. AFAIK, emma works by instrumentation, but sometimes for classes in bootclasspath, the instrumentation cannot work, there are two cases: 1. Some instrumented classes cannot be loaded by VM. 2. Some classes cannot be instrumented I have tried to look more inside to find some way to work around but I haven't got enough time yet. Specifically for nio-channel module, I had a list for these two cases (I believe the data is a little outdated and should be reevaluated) case 1. BaseByteBuffer.class Buffer.class BufferFactory.class ByteBuffer.class CharArrayBuffer.class
[classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
There is some enhancement on JNI spec in JDK 1.4[1], and three methods are related to java.nio.ByteBuffer. * |NewDirectByteBuffer| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer * |GetDirectBufferAddress| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress * |GetDirectBufferCapacity| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity Because these methods are actually classlib dependent and JNI implementation must know some details of ByteBuffer implementation, current IBM VME hasn't them implemented, and seems DRLVM doesn't implemented thoroughly(please correct me if I made mistake here, seems DRLVM tries to get some non-api method/field of ByteBuffer, and if fails, it return NULL or -1 as JNI spec says). And I have no idea how Sable/JCHEVM/BootJVM deals with this issue yet.(anyone kindly let me know?) I propose to provide the implementation in NIO component, and I raise Harmony-578 for it. The idea is: export these three methods in NIO module as hynio.dll(.so), which is loaded by Harmony launcher, and add these methods to VMI in some way, so that the VM vendor(i.e., JNI implementation vendor) can add these methods to JNI function table. Other choices I can imagine now include: 1. Add related direct buffers class to kernel class, so that the VM vendor can implement it as well as the JNI methods. IMO this is not good choice because buffers are actually VM independent, it's not reasonable to let VM vendor to implement these classes. 2. Provides some utility methods in o.a.h.nio, add these methods to VMI, so that VM vendor can get inside knowledge on the direct buffers by these utilities. This option is acceptable, but it also needs to modify VMI, and the modification is based on some Harmony specific contract, while my proposal above is based on public JNI spec, so this one is not preferred. Any ideas and comments are highly welcome. [1]http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html -- 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][vm] Prerequisites for java.util.concurrent
Nathan Beyer wrote: snip Does this mean we can stub out the luni-kernel System and just get the VMs to implement it in their kernel classes using this method? That's what I was thinking, and we can implement it in the luni-kernel / classpathadapter as a reference for VMs if we so choose. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
One more thing I've missed: what is the exclude list you've finally ended with? I'm going to publish it ASAP. P.S. I think java.awt does not currently belong to beans module, though who knows what the future may bring us :) In fact, coverage information is gathered for each jar, that, to some extend corresponds to modules content. Some awt classes are in beans.jar, that is why they appeared in coverage statistics for beans module. Thanks, Vladimir On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Cool! Sorry, I've missed it One more thing I've missed: what is the exclude list you've finally ended with? Thanks, Mikhail 2006/6/13, Vladimir Ivanov [EMAIL PROTECTED]: The detailed info available at http://viv.byethost15.com/ (this address also pointed on wiki-page). Do you need additional information ? Thanks, Vladimir On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Great! Is it possible to see uncovered classes/methods/lines? Thanks, Mikhail P.S. I think java.awt does not currently belong to beans module, though who knows what the future may bring us :) 2006/6/13, Vladimir Ivanov [EMAIL PROTECTED]: Latest Harmony API source coverage by Harmony API unit tests results I stored at wiki page http://wiki.apache.org/harmony/Coverage_information I'm going to refresh it bi-weekly (seems, it is enough for coverage). I think we have got a agreement on the test naming convention[1], but for sure, there have been many (legacy) test cases before this agreement, and I think the volunteer is highly welcome to provide patch for them. [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html If nobody objects I'm going to look through the unit tests to correct package names according to the agreement (where needed). Thanks, Vladimir On 6/8/06, Paulex Yang [EMAIL PROTECTED] wrote: Vladimir, Vladimir Ivanov wrote: Thanks Paulex! I did the same, but could not send results due to spam filter J Observations: 1. Coverage results look pretty much similar. 2. Exclude list looks pretty much similar too, but, looks like it depends on the way of data collection (I didn't run ant task and the list is a little bit different). Great. In any case, I think, when we run harmony on another VM exclude list will have to be updated. May be we can start publishing the coverage information on wiki pages and provide some updates time to time (I can do it)? +1, and of course, you can only if no one in the mailing list objects and you'll have my welcome, and I think it will be even greater if these reports can be generated regularly like what JAPI is doing:) One note: I noticed that different unit tests have very different package names Now the directory with all built tests copied to one place looks like: I think we have got a agreement on the test naming convention[1], but for sure, there have been many (legacy) test cases before this agreement, and I think the volunteer is highly welcome to provide patch for them. [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html C:\coverage\tests\testls GZIPOutClose2.txtapi config javax tests GZIPOutFinish.txtapi.injected dazzle orgxml GZIPOutWrite.txt binarygifprefs Inet6Address.golden.ser bundles impl serialization JDK2-3gabba.zip com impl.injected test.txt I think, it would be good if tests had unified package names. Why? – so far, just common sense, just to have an order in test suite Organization (if consider all unit tests as solid test suite). Thanks, Vladimir For example, my exclude list for java.io is: -java.io.BufferedInputStream , -java.io.BufferedOutputStream, -java.io.File , -java.io.FileChannelFactory , -java.io.FileDescriptor, -java.io.FileInputStream, -java.io.FileOutputStream, -java.io.FilterInputStream , -java.io.FilterOutputStream, - java.io.InputStream, -java.io.OutputStream, -java.io.ObjectStreamField, - java.io.PrintStream On 6/6/06, Paulex Yang [EMAIL PROTECTED] wrote: I've attach the scripts and excluded class lists to JIRA, please refer to https://issues.apache.org/jira/browse/HARMONY-564 . Enjoy it:). Mark Hindess wrote: On 2 June 2006 at 10:37, Paulex Yang [EMAIL PROTECTED] wrote: Mark, I'm glad that there is someone else has interest on emma, I've tried it
Re: [classlib][vm] Prerequisites for java.util.concurrent
Ah, I'm sorry, I think it's me misunderstand you. Nathan Beyer wrote: Sorry if I was confusing, the PriorityQueue is just a dependency of the j.u.c. There are a few classes that us it internally, including the PriorityBlockingQueue. -Original Message- From: Paulex Yang [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 2:18 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent Nathan, I'm working on the j.u.PriorityQueue (harmony-574), but I didn't find anything related to atomic or lock on this class? The spec on this class said: *Note that this implementation is not synchronized.* Multiple threads should not access a PriorityQueue instance concurrently if any of the threads modifies the list structurally. Instead, use the thread-safe |PriorityBlockingQueue| cid:part1.06010603.05020808@gmail.com class. So I guess you meant j.u.c.PriorityBlockingQueue here? which indeed requires some operations to be atomic, such as clear(), etc. Please correct me if I missed something here. Paulex. Nathan Beyer wrote: -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Nathan Beyer wrote: I've been working with the java.util.concurrent code to see what we'd need to have in place to get this code to be a part of Harmony. System.nanoTime() - A number of the classes rely on the new nanoTime method. I'm assuming this would just be marked as a native method like currentTimeMillis in luni-kernel, which would leave it up to the VMs implement. I can easily stub out the Java code. Anyone interested in getting our VMs to implement this method? I'm guessing that if IBM donates an updated VME for 1.5 usage, this would also be provided.maybe? It's in the Harmony port library as: U_64 VMCALL hytime_hires_clock (struct HyPortLibrary *portLibrary) [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc /vm_doc/html/hytime_8c.html?view=co Annotations - There are a few places where the @SuppressWarnings annotation is used. Building the annotations themselves is trivial, but we'll actually need to be using Java 5 class files to properly compile annotation class files. These can be commented out until the 5 class file support is enabled. Sounds like all Harmony-oriented VMs are happy for us to move to the 1.5 compiler, even if getting the runtime annotation info may not be there yet. Cool. I think the sooner we move forward, the better...at least more fun. Anyway, I think we're probably stretching the capabilities of the 1.5 source to 1.4 bytecodes functionality as far as it can go. PriorityQueue - There's at least one dependency on this class. I think someone is already working on this one though. VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a VM-specific API for atomic gets and sets. This API will need to be defined and then implemented by the various VMs. Many of the lock APIs also make use of this API. Do these have to be VM-specific? To be honest, I'm not sure. It may be possible to write this code in a VM-agnostic way, but someone who's a bit more familiar with the underlying concepts and the native code should a peek at it. (Any VM folks have a thought?) The only reason I'm guessing it's VM-specific at the moment is just a hunch, since the atomic guarantees and lock support ties into the memory models guarantees, which is maintained by the VM, it seemed apropos. Arrays.copyOf() - Several classes utilize a set of Arrays.copyOf() methods, which are new in Java SE 6 [1]. We'd either have to rework these implementations to use System.arraycopy or just implement the new methods. AbstractMap.SimpleEntryK,V - The ConcurrentHashMap uses this class as a base class for Map.Entry objects. This is a new public class, which is also part of Java SE 6 [2]. Either this code can be reworked to just implement the Map.Entry interface, or the SimpleEntry class can be built out, which should be trivial. Strange that there are 6.0 dependencies. Is there a j.u.concurrent maintenance stream we can track rather than the dev stream? Regards, Tim Thoughts, comments, questions? [1] http://java.sun.com/javase/6/docs/api/java/util/Arrays.html [2] http://java.sun.com/javase/6/docs/api/java/util/AbstractMap.SimpleEntry.ht ml -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [jira] Commented: (HARMONY-592) java.lang.Enum does not deserialize correctly
Richard Liang (JIRA) wrote: Hello Tim, The patch still cannot pass the provided test case. :-) So Please apply my patch. According to Java Spec 1.5, Enum constants are serialized differently than ordinary serializable or externalizable objects. To deserialize an enum constant, ObjectInputStream reads the constant name from the stream; the deserialized constant is then obtained by calling the java.lang.Enum.valueOf method, passing the constant's enum type along with the received constant name as arguments. ... all enum types have a fixed serialVersionUID of 0L. Where abouts did you find that text? I'm looking at the javadoc. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] StringBuilder vs StringBuffer
Nathan, I've attached suggested fix to the JIRA issue. Seems that now we can even beat the Reference Implementation on the microbenchmark ;) No new test failures introduced, I assume this is enough to ensure patch correctness. 2006/6/10, Nathan Beyer [EMAIL PROTECTED]: Go for it. Just work out your changes, create a patch and attach it to the issue you opened. In terms of passivity, one of the key implementation aspects to consider is that serialization works correctly for both classes afterwards. -Nathan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
I've update the web site by information about auth, crypto and rmi modules. The exclude list also was added. I'm not sure that all tests were run correctly so I'm going to verify test runs. Thanks, Vladimir On 6/13/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: One more thing I've missed: what is the exclude list you've finally ended with? I'm going to publish it ASAP. P.S. I think java.awt does not currently belong to beans module, though who knows what the future may bring us :) In fact, coverage information is gathered for each jar, that, to some extend corresponds to modules content. Some awt classes are in beans.jar, that is why they appeared in coverage statistics for beans module. Thanks, Vladimir On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Cool! Sorry, I've missed it One more thing I've missed: what is the exclude list you've finally ended with? Thanks, Mikhail 2006/6/13, Vladimir Ivanov [EMAIL PROTECTED]: The detailed info available at http://viv.byethost15.com/ (this address also pointed on wiki-page). Do you need additional information ? Thanks, Vladimir On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Great! Is it possible to see uncovered classes/methods/lines? Thanks, Mikhail P.S. I think java.awt does not currently belong to beans module, though who knows what the future may bring us :) 2006/6/13, Vladimir Ivanov [EMAIL PROTECTED]: Latest Harmony API source coverage by Harmony API unit tests results I stored at wiki page http://wiki.apache.org/harmony/Coverage_information I'm going to refresh it bi-weekly (seems, it is enough for coverage). I think we have got a agreement on the test naming convention[1], but for sure, there have been many (legacy) test cases before this agreement, and I think the volunteer is highly welcome to provide patch for them. [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html If nobody objects I'm going to look through the unit tests to correct package names according to the agreement (where needed). Thanks, Vladimir On 6/8/06, Paulex Yang [EMAIL PROTECTED] wrote: Vladimir, Vladimir Ivanov wrote: Thanks Paulex! I did the same, but could not send results due to spam filter J Observations: 1. Coverage results look pretty much similar. 2. Exclude list looks pretty much similar too, but, looks like it depends on the way of data collection (I didn't run ant task and the list is a little bit different). Great. In any case, I think, when we run harmony on another VM exclude list will have to be updated. May be we can start publishing the coverage information on wiki pages and provide some updates time to time (I can do it)? +1, and of course, you can only if no one in the mailing list objects and you'll have my welcome, and I think it will be even greater if these reports can be generated regularly like what JAPI is doing:) One note: I noticed that different unit tests have very different package names Now the directory with all built tests copied to one place looks like: I think we have got a agreement on the test naming convention[1], but for sure, there have been many (legacy) test cases before this agreement, and I think the volunteer is highly welcome to provide patch for them. [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html C:\coverage\tests\testls GZIPOutClose2.txtapi config javax tests GZIPOutFinish.txtapi.injected dazzle orgxml GZIPOutWrite.txt binarygifprefs Inet6Address.golden.ser bundles impl serialization JDK2-3gabba.zip com impl.injected test.txt I think, it would be good if tests had unified package names. Why? – so far, just common sense, just to have an order in test suite Organization (if consider all unit tests as solid test suite). Thanks, Vladimir For example, my exclude list for java.io is: -java.io.BufferedInputStream , -java.io.BufferedOutputStream, -java.io.File , -java.io.FileChannelFactory , -java.io.FileDescriptor, -java.io.FileInputStream, -java.io.FileOutputStream, -java.io.FilterInputStream , -java.io.FilterOutputStream, - java.io.InputStream, -java.io.OutputStream, -java.io.ObjectStreamField, -
Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Paulex Yang wrote: There is some enhancement on JNI spec in JDK 1.4[1], and three methods are related to java.nio.ByteBuffer. * |NewDirectByteBuffer| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer * |GetDirectBufferAddress| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress * |GetDirectBufferCapacity| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity Because these methods are actually classlib dependent and JNI implementation must know some details of ByteBuffer implementation, current IBM VME hasn't them implemented, and seems DRLVM doesn't implemented thoroughly(please correct me if I made mistake here, seems DRLVM tries to get some non-api method/field of ByteBuffer, and if fails, it return NULL or -1 as JNI spec says). And I have no idea how Sable/JCHEVM/BootJVM deals with this issue yet.(anyone kindly let me know?) FYI, here is how this is handled in Classpath-based VMs like JCHEVM. The direct buffer classes derive from a common superclass containing the well known fields data and capacity. The latter is an int, while the former is of type gnu.classpath.Pointer32 (or Pointer64), which is just a container that stores a native pointer in an int/long. The native pointer points to the native buffer. These two fields are accessed by GetDirectBufferAddress() and GetDirectBufferCapacity(). There is also a constructor available for the JNI code to call, taking: gnu.classpath.Pointer32/64, and int (capacity). This is used for NewDirectByteBuffer(). The resulting JNI code is fairly simple. You can see it on line 2580 of https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jchevm/libjc/jni_native.c -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using mx4j for javax.management
That's been the plan :) I've had some conversations with Simone about this a while ago - I'd really like to see the code come here since I think he seens an end of life for MX4J as an indep project w/ jmx in Java SE. I'll see if I can rekindle that convo here... geir Mark Hindess wrote: I created a JIRA about this issue, see: https://issues.apache.org/jira/browse/HARMONY-560 There is a patch attached if anyone wants to test it. The license is at: http://mx4j.sourceforge.net/docs/ch01s06.html Any thoughts or comments about whether this is a reasonable thing to do? Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HARMONY-592) java.lang.Enum does not deserialize correctly
Tim Ellison wrote: Richard Liang (JIRA) wrote: Hello Tim, The patch still cannot pass the provided test case. :-) So Please apply my patch. According to Java Spec 1.5, Enum constants are serialized differently than ordinary serializable or externalizable objects. To deserialize an enum constant, ObjectInputStream reads the constant name from the stream; the deserialized constant is then obtained by calling the java.lang.Enum.valueOf method, passing the constant's enum type along with the received constant name as arguments. ... all enum types have a fixed serialVersionUID of 0L. Where abouts did you find that text? I'm looking at the javadoc. Hello Tim, Please find it at http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/serial-arch.html#6469 Thanks a lot. Regards, Tim -- Richard Liang China Software Development Lab, IBM
[classlib] Modularising the native code - it begins!
Hi all, As you have probably noticed, I recently raised HARMONY-596 (which Mark has already kindly applied) to make .lib and .a files generate straight into the deploy/lib directory. I think that now we are in a position to finally modularise the classlib native code. I've volunteered to do this, and plan to move the code down into the modules in the layout described in [1], since I believe there were no objections. I will probably warm up with some of the easier modules - prefs/text/auth - before moving onto archive and luni. Ill raise a separate JIRA for each set of moves, and let you all know how I progress and if there are any problems/questions I have. I also plan to create a doc for the website describing the location of the native code, and summarising how platform specific and shared code is laid out within each native component. Please let me know if there are any issues with this - otherwise I will continue to work on it and submit patches. Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools] HARMONY-598 (Keytool - added keystore loading, keytool-specific exception type, misc.)
Hi Anton
Sorry I'm not a guru in keytools but why catch exceptions and resend them?
+try {
+// try to load the keystore
+keyStore.load(fis, storePass);
+} catch (NoSuchAlgorithmException e) {
+throw new NoSuchAlgorithmException(
+Failed to find the algorithm to check the
keystore integrity,
+e);
+} catch (CertificateException e) {
+throw new CertificateException(
+Failed to load a certificate from the keystore. , e);
+} catch (IOException e) {
+throw (IOException) new IOException(Failed to load the
keystore. )
+.initCause(e);
+}
+return keyStore;
+}
Thanks,
Mikhail
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Modularising the native code - it begins!
Oliver Deakin wrote: Hi all, As you have probably noticed, I recently raised HARMONY-596 (which Mark has already kindly applied) to make .lib and .a files generate straight into the deploy/lib directory. I think that now we are in a position to finally modularise the classlib native code. I've volunteered to do this, and plan to move the code down into the modules in the layout described in [1], since I believe there were no objections. Other than my outstanding objections to how HDK is being conflated with the deploy directory, none :) I know I owe you some responses from last week, and that stuff shouldn't stand in the way of what you want to do here. I will probably warm up with some of the easier modules - prefs/text/auth - before moving onto archive and luni. Ill raise a separate JIRA for each set of moves, and let you all know how I progress and if there are any problems/questions I have. I assume this is gradual - that you can do one module first, it can go into SVN, and all still is fine? I also plan to create a doc for the website describing the location of the native code, and summarising how platform specific and shared code is laid out within each native component. Ooh! Ah! THanks! geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] one more gc
Hi Ivan, On 6/13/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Btw, I have found small performance improvement to GCv4 which can be easily added to it. Could you please post more details about this possible perf enhancement to V4? ... Well, I'm going to do this development just for education and to extend my own horizon. It can be done here or privately. Either variant is acceptable for me. Since this is more of an experiment, ( educational as you point out ) and it is a little unclear immediately what is the value it adds to the DRLVM GC infrastructure, would it make sense for you to make some progress offline and bring back your findings to this list before doing incremental JIRA code postings? What do you think? Thanks, Rana -- Ivan On 6/13/06, Weldon Washburn [EMAIL PROTECTED] wrote: Ivan, Please note that two guys who worked for me on ORP (http://orp.sourceforge.net/ ) spent 2-3 years building and tuning the train algorithm. We could never get the performance to acceptable level. Ultimately we ditched the train algorithm and built GCV4 in less than 3 months. GCV4 was never finished. I suspect other VM builders also experimented with the train algorithm and abandoned it. As far as I know, there are no production or research MRTEs containing the train algorithm. Also note there is already a complete implementation of the train algorithm in Apache compatible licensed open source. Look for orp-1.0.10.tgz on http://sourceforge.net/projects/orp ). The train algorithm is contained in the directory gc_v2. Since the GC/VM interface has not evolved much in the transition from ORP to DRLVM, it should be an easy port. This port would be interesting for two reasons: a) A teaching tool to show why/where the train algorithm fails. Tony Printezis and Richard Jones wrote an excellent paper that used GCspy to graphically demonstrate where the train algorithm falls down. Look for, GCspy: An Adaptable Heap Visualization Framework by Tony Printezis and Richard Jones, ( http://www.cs.kent.ac.uk/pubs/2002/1426/index.html ). Also look for, (http://research.sun.com/projects/gcspy/printezis-garthwaite-ismm2002.pdf ), Visualizing the Train Garbage Collector. It might be interesting to hook up GCV2 and GCspy to harmonydrlvm and reproduce this paper. This would calibrate GCspy for future harmonydrlvm work. b) GC_V2 really stressed the write barrier subsystem. (GCV2 does a substantial amount of object copying.) If GC_V2 can be ported quickly, it might be a good stepping stone to getting MMTk going. On 6/9/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: While some works going on to properly integrate DRLVM in harmony build system... I would like to start development of new garbage collector. I know about Weldon's work related to MMTk. I am not sure that it is the right way. Instead of doing GC based on java, I would concentrate on the one written in C. I think that the VM written in C (or C++ ) should have GC written the same way. I have some experience in garbage collectors (stop-the-world ones for now) and want to extend my knowledge in this area. That is one of the reasons I want to make the GC, but do not port the existing one. I hope I will eventually produce something which is better then existing implementations or at least a few new ideas. I would like to start implementing something similar to Train algorithm, then possibly modify it in direction to Garbage First collector. I want to create something with high performance and low pauses. At the beginning it will not even compile. I do not expect this to be interesting to anyone for some time, but as Geir always suggests I going to do this in public to avoid surprises. All required VM functionality (for GC written in C) is already in place. DRLVM's interfaces for GC is ok for me and should be quite portable. Write barriers implementation is already in place, suitable for C-based Gc: (Harmony-504 (me), Harmony-581 (Ming Wu)). As I don't have commiter account, I going to create one JIRA and start to fill it with patches. In the patches I will create directory enhanced/drlvm/trunk/vm/gcx and will start to fill it with stubs and implementation. I am going to do it mostly at spare time. - 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] one more gc
Ivan, Even if the vtable gc data layout change is small and code specific, it will be interesting to see the change proposal here first, specially if you are considering submitting it. Sounds quite promising. 1.5% is not small. Some details of which workload saw the 1.5% collection delta would also help. Thanks much, Rana On 6/13/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 6/13/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Hi Ivan, On 6/13/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Btw, I have found small performance improvement to GCv4 which can be easily added to it. Could you please post more details about this possible perf enhancement to V4? ... It is just very specific code. The layout of gc data in VTable can be changed a bit. It gives about 1.5% speed up of garbage collection and may also have insignificant performance improvement on allocation. Well, I'm going to do this development just for education and to extend my own horizon. It can be done here or privately. Either variant is acceptable for me. Since this is more of an experiment, ( educational as you point out ) and it is a little unclear immediately what is the value it adds to the DRLVM GC infrastructure, would it make sense for you to make some progress offline and bring back your findings to this list before doing incremental JIRA code postings? What do you think? Yes, it makes sense. I want to do a few experiments and the postings will at one hand will slow-down me, at the other hand it is of no use for others. -- Regards, Ivan Thanks, Rana -- Ivan On 6/13/06, Weldon Washburn [EMAIL PROTECTED] wrote: Ivan, Please note that two guys who worked for me on ORP (http://orp.sourceforge.net/ ) spent 2-3 years building and tuning the train algorithm. We could never get the performance to acceptable level. Ultimately we ditched the train algorithm and built GCV4 in less than 3 months. GCV4 was never finished. I suspect other VM builders also experimented with the train algorithm and abandoned it. As far as I know, there are no production or research MRTEs containing the train algorithm. Also note there is already a complete implementation of the train algorithm in Apache compatible licensed open source. Look for orp-1.0.10.tgz on http://sourceforge.net/projects/orp ). The train algorithm is contained in the directory gc_v2. Since the GC/VM interface has not evolved much in the transition from ORP to DRLVM, it should be an easy port. This port would be interesting for two reasons: a) A teaching tool to show why/where the train algorithm fails. Tony Printezis and Richard Jones wrote an excellent paper that used GCspy to graphically demonstrate where the train algorithm falls down. Look for, GCspy: An Adaptable Heap Visualization Framework by Tony Printezis and Richard Jones, ( http://www.cs.kent.ac.uk/pubs/2002/1426/index.html ). Also look for, ( http://research.sun.com/projects/gcspy/printezis-garthwaite-ismm2002.pdf ), Visualizing the Train Garbage Collector. It might be interesting to hook up GCV2 and GCspy to harmonydrlvm and reproduce this paper. This would calibrate GCspy for future harmonydrlvm work. b) GC_V2 really stressed the write barrier subsystem. (GCV2 does a substantial amount of object copying.) If GC_V2 can be ported quickly, it might be a good stepping stone to getting MMTk going. On 6/9/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: While some works going on to properly integrate DRLVM in harmony build system... I would like to start development of new garbage collector. I know about Weldon's work related to MMTk. I am not sure that it is the right way. Instead of doing GC based on java, I would concentrate on the one written in C. I think that the VM written in C (or C++ ) should have GC written the same way. I have some experience in garbage collectors (stop-the-world ones for now) and want to extend my knowledge in this area. That is one of the reasons I want to make the GC, but do not port the existing one. I hope I will eventually produce something which is better then existing implementations or at least a few new ideas. I would like to start implementing something similar to Train algorithm, then possibly modify it in direction to Garbage First collector. I want to create something with high performance and low pauses. At the beginning it will not even compile. I do not expect this to be interesting to anyone for some time, but as Geir always suggests I going to do this in public to avoid surprises. All required VM functionality (for GC written in C) is already in place. DRLVM's interfaces for GC is ok for me and should be quite portable. Write barriers implementation is already in place, suitable for C-based Gc:
RE: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
Is there any possibility of adding this to an Ant script that can optionally be run with the build scripts? I'd like to make this easier for everyone to run while developing. Has anyone tried any other coverage tools? Like TPTP for Eclipse, Clover or Corbetura (sp)? -Nathan -Original Message- From: Vladimir Ivanov [mailto:[EMAIL PROTECTED] Latest Harmony API source coverage by Harmony API unit tests results I stored at wiki page http://wiki.apache.org/harmony/Coverage_information I'm going to refresh it bi-weekly (seems, it is enough for coverage). I think we have got a agreement on the test naming convention[1], but for sure, there have been many (legacy) test cases before this agreement, and I think the volunteer is highly welcome to provide patch for them. [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing .html If nobody objects I'm going to look through the unit tests to correct package names according to the agreement (where needed). Thanks, Vladimir On 6/8/06, Paulex Yang [EMAIL PROTECTED] wrote: Vladimir, Vladimir Ivanov wrote: Thanks Paulex! I did the same, but could not send results due to spam filter J Observations: 1. Coverage results look pretty much similar. 2. Exclude list looks pretty much similar too, but, looks like it depends on the way of data collection (I didn't run ant task and the list is a little bit different). Great. In any case, I think, when we run harmony on another VM exclude list will have to be updated. May be we can start publishing the coverage information on wiki pages and provide some updates time to time (I can do it)? +1, and of course, you can only if no one in the mailing list objects and you'll have my welcome, and I think it will be even greater if these reports can be generated regularly like what JAPI is doing:) One note: I noticed that different unit tests have very different package names Now the directory with all built tests copied to one place looks like: I think we have got a agreement on the test naming convention[1], but for sure, there have been many (legacy) test cases before this agreement, and I think the volunteer is highly welcome to provide patch for them. [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing. html C:\coverage\tests\testls GZIPOutClose2.txtapi config javax tests GZIPOutFinish.txtapi.injected dazzle org xml GZIPOutWrite.txt binarygifprefs Inet6Address.golden.ser bundles impl serialization JDK2-3gabba.zip com impl.injected test.txt I think, it would be good if tests had unified package names. Why? - so far, just common sense, just to have an order in test suite Organization (if consider all unit tests as solid test suite). Thanks, Vladimir For example, my exclude list for java.io is: -java.io.BufferedInputStream , -java.io.BufferedOutputStream, -java.io.File , -java.io.FileChannelFactory, -java.io.FileDescriptor, -java.io.FileInputStream, -java.io.FileOutputStream, -java.io.FilterInputStream , -java.io.FilterOutputStream, - java.io.InputStream, -java.io.OutputStream, -java.io.ObjectStreamField, -java.io.PrintStream On 6/6/06, Paulex Yang [EMAIL PROTECTED] wrote: I've attach the scripts and excluded class lists to JIRA, please refer to https://issues.apache.org/jira/browse/HARMONY-564 . Enjoy it:). Mark Hindess wrote: On 2 June 2006 at 10:37, Paulex Yang [EMAIL PROTECTED] wrote: Mark, I'm glad that there is someone else has interest on emma, I've tried it before. AFAIK, emma works by instrumentation, but sometimes for classes in bootclasspath, the instrumentation cannot work, there are two cases: 1. Some instrumented classes cannot be loaded by VM. 2. Some classes cannot be instrumented I have tried to look more inside to find some way to work around but I haven't got enough time yet. Specifically for nio-channel module, I had a list for these two cases (I believe the data is a little outdated and should be reevaluated) case 1. BaseByteBuffer.class Buffer.class BufferFactory.class ByteBuffer.class CharArrayBuffer.class CharBuffer.class HeapByteBuffer.class ReadWriteCharArrayBuffer.class ReadWriteHeapByteBuffer.class FileChannel.class AbstractInterruptibleChannel.class FileChannelImpl.class WriteOnlyFileChannel.class LockManager.class LockManager$1.class ReadOnlyFileChannel.class case 2: ByteChannel.class Channel.class GatheringByteChannel.class
Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
On 6/13/06, Paulex Yang [EMAIL PROTECTED] wrote: There is some enhancement on JNI spec in JDK 1.4[1], and three methods are related to java.nio.ByteBuffer. * |NewDirectByteBuffer| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer * |GetDirectBufferAddress| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress * |GetDirectBufferCapacity| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity Because these methods are actually classlib dependent and JNI implementation must know some details of ByteBuffer implementation, current IBM VME hasn't them implemented, and seems DRLVM doesn't implemented thoroughly(please correct me if I made mistake here, seems DRLVM tries to get some non-api method/field of ByteBuffer, and if fails, it return NULL or -1 as JNI spec says). And I have no idea how Sable/JCHEVM/BootJVM deals with this issue yet.(anyone kindly let me know?) I propose to provide the implementation in NIO component, and I raise Harmony-578 for it. The idea is: export these three methods in NIO module as hynio.dll(.so), which is loaded by Harmony launcher, and add these methods to VMI in some way, so that the VM vendor(i.e., JNI implementation vendor) can add these methods to JNI function table. Other choices I can imagine now include: 1. Add related direct buffers class to kernel class, so that the VM vendor can implement it as well as the JNI methods. IMO this is not good choice because buffers are actually VM independent, it's not reasonable to let VM vendor to implement these classes. It seems that JCHEVM follows this way. It depends on classes from classpath library. 2. Provides some utility methods in o.a.h.nio, add these methods to VMI, so that VM vendor can get inside knowledge on the direct buffers by these utilities. This option is acceptable, but it also needs to modify VMI, and the modification is based on some Harmony specific contract, while my proposal above is based on public JNI spec, so this one is not preferred. It seems that DRLVM follows this way, except it assumes the utility methods are located in java.nio.ByteBuffer, not o.a.h.nio. Any ideas and comments are highly welcome. [1]http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html -- 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] -- Andrew Zhang China Software Development Lab, IBM
Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Paulex Yang wrote: There is some enhancement on JNI spec in JDK 1.4[1], and three methods are related to java.nio.ByteBuffer. * |NewDirectByteBuffer| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer * |GetDirectBufferAddress| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress * |GetDirectBufferCapacity| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity Because these methods are actually classlib dependent and JNI implementation must know some details of ByteBuffer implementation, current IBM VME hasn't them implemented, and seems DRLVM doesn't implemented thoroughly(please correct me if I made mistake here, seems DRLVM tries to get some non-api method/field of ByteBuffer, and if fails, it return NULL or -1 as JNI spec says). And I have no idea how Sable/JCHEVM/BootJVM deals with this issue yet.(anyone kindly let me know?) I propose to provide the implementation in NIO component, and I raise Harmony-578 for it. The idea is: export these three methods in NIO module as hynio.dll(.so), which is loaded by Harmony launcher, and add these methods to VMI in some way, so that the VM vendor(i.e., JNI implementation vendor) can add these methods to JNI function table. Other choices I can imagine now include: 1. Add related direct buffers class to kernel class, so that the VM vendor can implement it as well as the JNI methods. IMO this is not good choice because buffers are actually VM independent, it's not reasonable to let VM vendor to implement these classes. By reading the spec, it seems RI prefer this way, take direct-buffer as kernel class ,like class String(Though maybe it is hard to tell kernel and normal classes in RI's implementation, they're always together there :) ). And in Harmony, there's an interface named DirectBuffer (o.a.h.nio.internal), abstract class Buffer(java.nio) and an implementation class ReadWriteDirectByteBuffer (java.nio),which contains fields and methods for JNI methods. So an easy way may be: take these as kernel classes, and get Address from DirectBuffer.getBaseAddress(), get Capacity from Buffer.capacity, and new a ReadWriteDirectByteBuffer as basic direct buffer in three JNI methods. 2. Provides some utility methods in o.a.h.nio, add these methods to VMI, so that VM vendor can get inside knowledge on the direct buffers by these utilities. This option is acceptable, but it also needs to modify VMI, and the modification is based on some Harmony specific contract, while my proposal above is based on public JNI spec, so this one is not preferred. Any ideas and comments are highly welcome. [1]http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html -- Best Regards! Jimmy, Jing Lv 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][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Archie Cobbs wrote: Paulex Yang wrote: There is some enhancement on JNI spec in JDK 1.4[1], and three methods are related to java.nio.ByteBuffer. * |NewDirectByteBuffer| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer * |GetDirectBufferAddress| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress * |GetDirectBufferCapacity| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity Because these methods are actually classlib dependent and JNI implementation must know some details of ByteBuffer implementation, current IBM VME hasn't them implemented, and seems DRLVM doesn't implemented thoroughly(please correct me if I made mistake here, seems DRLVM tries to get some non-api method/field of ByteBuffer, and if fails, it return NULL or -1 as JNI spec says). And I have no idea how Sable/JCHEVM/BootJVM deals with this issue yet.(anyone kindly let me know?) FYI, here is how this is handled in Classpath-based VMs like JCHEVM. The direct buffer classes derive from a common superclass containing the well known fields data and capacity. The latter is an int, while the former is of type gnu.classpath.Pointer32 (or Pointer64), which is just a container that stores a native pointer in an int/long. The native pointer points to the native buffer. These two fields are accessed by GetDirectBufferAddress() and GetDirectBufferCapacity(). There is also a constructor available for the JNI code to call, taking: gnu.classpath.Pointer32/64, and int (capacity). This is used for NewDirectByteBuffer(). The resulting JNI code is fairly simple. You can see it on line 2580 of https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jchevm/libjc/jni_native.c Thank you, Archie, very clear explanation! Actually Harmony classlib can be used in similar way, in Harmony's classlib, there is a interface named as DirectBuffer, which is implemented by all direct buffers(including MappedByteBuffer), and it provides method to get a native address wrapper named as PlatformAddress, which should be similar with Pointer32/64 in classpath I believe. About the NewDirectByteBuffer, Harmony classlib can work in similar way, create a PlatformAddress, and invoke ReadWriteDirectBuffer's constructor. But after all, the implementation details(class name, fields/methods, etc) are different, so the idea is to provide the three JNI methods' implementation in NIO module, and add them into VMI, so that VM vendor can choose to add them into the JNI function table. I think this will make it easier to integrate Harmony classlib and multi VMs. Comments? ideas? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Jimmy, Jing Lv wrote: Paulex Yang wrote: There is some enhancement on JNI spec in JDK 1.4[1], and three methods are related to java.nio.ByteBuffer. * |NewDirectByteBuffer| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer * |GetDirectBufferAddress| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress * |GetDirectBufferCapacity| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity Because these methods are actually classlib dependent and JNI implementation must know some details of ByteBuffer implementation, current IBM VME hasn't them implemented, and seems DRLVM doesn't implemented thoroughly(please correct me if I made mistake here, seems DRLVM tries to get some non-api method/field of ByteBuffer, and if fails, it return NULL or -1 as JNI spec says). And I have no idea how Sable/JCHEVM/BootJVM deals with this issue yet.(anyone kindly let me know?) I propose to provide the implementation in NIO component, and I raise Harmony-578 for it. The idea is: export these three methods in NIO module as hynio.dll(.so), which is loaded by Harmony launcher, and add these methods to VMI in some way, so that the VM vendor(i.e., JNI implementation vendor) can add these methods to JNI function table. Other choices I can imagine now include: 1. Add related direct buffers class to kernel class, so that the VM vendor can implement it as well as the JNI methods. IMO this is not good choice because buffers are actually VM independent, it's not reasonable to let VM vendor to implement these classes. By reading the spec, it seems RI prefer this way, take direct-buffer as kernel class ,like class String(Though maybe it is hard to tell kernel and normal classes in RI's implementation, they're always together there :) ). And in Harmony, there's an interface named DirectBuffer (o.a.h.nio.internal), abstract class Buffer(java.nio) and an implementation class ReadWriteDirectByteBuffer (java.nio),which contains fields and methods for JNI methods. So an easy way may be: take these as kernel classes, and get Address from DirectBuffer.getBaseAddress(), get Capacity from Buffer.capacity, and new a ReadWriteDirectByteBuffer as basic direct buffer in three JNI methods. I think the kernel class means the classes which heavily depends on VM implementation, but the buffer is another story, it is the JNI actually depends on Classlib implementation, so instead of put buffers into kernel, I prefer to pull the three JNI methods out of VM into classlib. 2. Provides some utility methods in o.a.h.nio, add these methods to VMI, so that VM vendor can get inside knowledge on the direct buffers by these utilities. This option is acceptable, but it also needs to modify VMI, and the modification is based on some Harmony specific contract, while my proposal above is based on public JNI spec, so this one is not preferred. Any ideas and comments are highly welcome. [1]http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html -- 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][vm] Prerequisites for java.util.concurrent
I stubbed out the method in luni-kernel (as well as two other methods that were missing). I looked at DRLVM and it already has nanoTime implementation, but it's not using the method you mentioned. I took a peek at the JCHEVM/classlibadaptar, but I couldn't quite discern the various artifacts. -Nathan -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 6:34 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent Nathan Beyer wrote: snip Does this mean we can stub out the luni-kernel System and just get the VMs to implement it in their kernel classes using this method? That's what I was thinking, and we can implement it in the luni-kernel / classpathadapter as a reference for VMs if we so choose. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with builth path!
Tim Ellison wrote: Richard Liang wrote: I launch Eclipse 3.2 RC7 with options -Xms256M -Xmx256M -vm D:\jdk\RI\jdk1.5.0_06\bin\javaw -Dpde.allowCycles=true -Dpde.jreProfile=none, But LUNI still cannot add luni-kernel-stubs.jar to its Plug-in Dependencies. So I have to add luni-kernel-stubs.jar to build path explicitly. Could you please tell me what's wrong with my settings? Thanks a lot. Looks like you are missing a -vmargs option to tell eclipse.exe to pass the -D args to the VM. So try (ignore my mail client's wrapping): eclipse -vm D:\jdk\RI\jdk1.5.0_06\bin\javaw -vmargs -Xms256M -Xmx256M -Dpde.allowCycles=true -Dpde.jreProfile=none Great! It works very well. Thanks a lot, Tim. :-) Regards, Tim -- Richard Liang China Software Development Lab, IBM
