Re: [doc] new "Getting Started" guides
On 9/28/06, Geir Magnusson Jr. wrote: On Sep 27, 2006, at 10:53 PM, Stepan Mishura wrote: > t is great that you've created guides and put references to them at > top. So > now it is clear for newcomer what the next step is. And I'd like to > suggest > the following improvement for contributors guide: the page contains > only few > words about projects parts and it may create impression that > Harmony is a > one big/complex piece of software that has a lot of dependencies to > download. I think that it is important to say clearly in the > beginning of > the page that the project consists of many quite independent parts. > And the > newcomer has a choice to work with whole code base (a.k.a. > federated build) > or with a part of the project. So the top of the page should > contain two > references to federated build and to a description of the project's > components. I understand. Remember, this is targetted for newbies - people who don't know anything yet, and what it tries to do is find the fastest path to getting working code from a single checkout. Yes, I remember that and I wanted to share my view what the fastest way is. > > We have instructions for federated build. It looks OK for me. And the > description of components should give detailed picture of all > components not > just mention VM and Classlib. And the components' description > should points > to components' homepages. Good point. But what other components right now would you point to? A structure can be - Classlib . <= pointers to subcomponents - Tools . <= pointers to subcomponents -VM . <= pointers to subcomponents > > BTW, just random idea. I'd let each module to live by its own life > by having > its own homepage, releases, mailing list and JIRA component, like > we have > for ORB module (Apache Yoko project). Does this make sense? No. There no sense in releasing just a classlibrary or a virtual machine. Or a toolset. You need the whole pile. Sometimes it is hard to swallow a whole pile. J2SE implementation is a big pile. I don't see anything wrong here why not to suggest the newbie to try a piece of the pile. For example, what the problem with releasing 'keytool' or 'beans framework'? Why these parts should wait until we complete full toolset of classlib? I think we need to continue to focus on our primary goal, java SE. I've also been concerned about having "subprojects" that are too independent, creating sub-communities. I think that should be avoided at all cost. Sure, we each have our focus and specialization, but we're one project, one community. IMHO, we unintentionally pushed idea of independency components to project's backyard. I think this is not good. We have categories for JIRA - doesn't that work? Mail list is busy, but right now we seem to be doing ok in terms of segmenting by subject line, and quite frankly, I still think that the benefits of intermixing currently outweigh the costs. yes, we need a user list soon, and someday we'll split VM from classlib, but right now, there's such good collaboration... Yes, high mail traffic might be a problem it constantly grows. And subject's line definitely helps now but I'm not sure about future. Also some parts of the project are indeed independent. For example, it may be possible to take some framework from classlib, say logging framework, and try it with another JRE. And the framework should work. This is true independence. So it seems more natural for me to create a sub-project for the framework to let it be more attractive for users: has less bugs, is faster, follows the spec. and so on. Why not? Thanks, Stepan. As for homepages, we already have that - basic pages for each major component. 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] [launcher] Executable hangs
yes - add the bin directory and the default directory to your LD_LIBRARY_PATH - the launcher will decide that it doesn't need to do the execv() and will skip it... geir On Sep 28, 2006, at 2:31 AM, Armand Navabi wrote: I followed your suggestions below and made everything build in debug mode. Now I can put a break in main.c. Thanks. Also, now I also see debug information when I try to run helloworld. Perhaps this debugging information is useful. [EMAIL PROTECTED] /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ ./java helloworld An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 Signal_Number=000b Error_Value= Signal_Code=0001 Handler1=0804B410 Handler2=B7EEFE46 InaccessibleAddress=0004 EDI=080A87E0 ESI= EAX= EBX=B7F17FD4 ECX= EDX= EIP=B7F0AD94 ES=C010007B DS=007B ESP=BFE5194C EFlags=00210246 CS=0073 SS=007B EBP=BFE51A68 Module=/lib/ld-linux.so.2 Module_base_address=B7F02000 Aborted So now that I can put break points, I tried to follow the code in gdb to see where it was hanging. In gdb I get to line 1102 in main.c, which is the addDirsToPath method, "execv (exeName, argv)". I think that I remember this being discussed before. I believe gdb is unable to deal with this call to execv. So, I don't think this is what is making the VM hang, and now I am unable to follow the execution of "java helloworld" any further. Is there a way around this? Here is the gdb results: (gdb) b main.c:315 Breakpoint 1 at 0x8048e6f: file main.c, line 315. (gdb) r helloworld Starting program: /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 9192)] [New Thread 32769 (LWP 9195)] [New Thread 16386 (LWP 9196)] [Switching to Thread 16384 (LWP 9192)] Breakpoint 1, gpProtectedMain (args=0xbfc3df90) at main.c:315 315 rc = addDirsToPath(PORTLIB, 2, dirs, argv); (gdb) s addDirsToPath (portLibrary=0xbfc3dfb0, count=2, newPathToAdd=0xbfc3ddb8, argv=0xbfc3e3a4) at main.c:1015 1015 char *oldPath = NULL; (gdb) b 1102 Breakpoint 2 at 0x804a7aa: file main.c, line 1102. (gdb) c Continuing. Breakpoint 2, addDirsToPath (portLibrary=0xbfc3dfb0, count=2, newPathToAdd=0xbfc3ddb8, argv=0xbfc3e3a4) at main.c:1102 1102 execv (exeName, argv); Oops, some day I made everything build in debug mode locally. And forgot about it. Currently there is no option for that. TBD, obviously. I do it with the patch (linux only) like this: ... No problem. I'm glad it's helpful. I was beginning to worry that I was just getting annoying :). Thanks for the help, Armand Thank you for digging into it. That's really valuable. I hope we will fix the issue soon. Thanks, Armand Egor Pasko wrote: I solve this by breaking inside launcher after VM lib is loaded, then I break somewhere after libjitrino.so is loaded. Then I can break anywhere :) looks like this: break main.c:360 r dis break compile_jit_a_method c dis break whatever function you want You can make it a script via GDB's 'define' and put somewhere in ~/.gdbinit, two scripts are better: first for initial run, the second script does the same but reusing old breakpoint numbers: dis en 1 r dis en 2 c dis I should put that into the FAQ, obviously. And then when I run the program it never stops at the breakpoint, though I see the print I have inserted in the code. Secondly, and more importantly, if I try to do anything interesting, like run helloworld, gdb seems to lose a thread and then hang (says it Cannot find a thread. Invalid thread handle). I have to then stop it and go kill it. this one is probably a separate issue (not connected with "future shared library load"). Try my above suggestion, please. GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r helloworld Starting program: /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/ bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 11007)] [New Thread 32769 (LWP 11010)] [New Thread 16386 (LWP 11011)] Cannot find thread 32769: invalid thread handle (gdb) q The program is running. Exit anyway? (y or n) y [1]+ Stopped gdb ./java Thanks, Armand On the 0x1F0 day of Apache Harmony Armand Navabi wrote: When I try to run ./java helloworld, it just hangs and I have to kill the process. I investigated this a little bit, and I found that it hangs on the call to FindClass (in main.c line around line 1199). I am unable deb
Re: [drlvm] [launcher] Executable hangs
I followed your suggestions below and made everything build in debug mode. Now I can put a break in main.c. Thanks. Also, now I also see debug information when I try to run helloworld. Perhaps this debugging information is useful. [EMAIL PROTECTED] /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ ./java helloworld An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 Signal_Number=000b Error_Value= Signal_Code=0001 Handler1=0804B410 Handler2=B7EEFE46 InaccessibleAddress=0004 EDI=080A87E0 ESI= EAX= EBX=B7F17FD4 ECX= EDX= EIP=B7F0AD94 ES=C010007B DS=007B ESP=BFE5194C EFlags=00210246 CS=0073 SS=007B EBP=BFE51A68 Module=/lib/ld-linux.so.2 Module_base_address=B7F02000 Aborted So now that I can put break points, I tried to follow the code in gdb to see where it was hanging. In gdb I get to line 1102 in main.c, which is the addDirsToPath method, "execv (exeName, argv)". I think that I remember this being discussed before. I believe gdb is unable to deal with this call to execv. So, I don't think this is what is making the VM hang, and now I am unable to follow the execution of "java helloworld" any further. Is there a way around this? Here is the gdb results: (gdb) b main.c:315 Breakpoint 1 at 0x8048e6f: file main.c, line 315. (gdb) r helloworld Starting program: /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 9192)] [New Thread 32769 (LWP 9195)] [New Thread 16386 (LWP 9196)] [Switching to Thread 16384 (LWP 9192)] Breakpoint 1, gpProtectedMain (args=0xbfc3df90) at main.c:315 315 rc = addDirsToPath(PORTLIB, 2, dirs, argv); (gdb) s addDirsToPath (portLibrary=0xbfc3dfb0, count=2, newPathToAdd=0xbfc3ddb8, argv=0xbfc3e3a4) at main.c:1015 1015 char *oldPath = NULL; (gdb) b 1102 Breakpoint 2 at 0x804a7aa: file main.c, line 1102. (gdb) c Continuing. Breakpoint 2, addDirsToPath (portLibrary=0xbfc3dfb0, count=2, newPathToAdd=0xbfc3ddb8, argv=0xbfc3e3a4) at main.c:1102 1102 execv (exeName, argv); > Oops, some day I made everything build in debug mode locally. And > forgot about it. Currently there is no option for that. TBD, > obviously. I do it with the patch (linux only) like this: > ... > No problem. I'm glad it's helpful. I was beginning to worry that I was just getting annoying :). Thanks for the help, Armand > Thank you for digging into it. That's really valuable. I hope we will > fix the issue soon. > > >> Thanks, >> Armand >> >> Egor Pasko wrote: >> >>> I solve this by breaking inside launcher after VM lib is loaded, then >>> I break somewhere after libjitrino.so is loaded. Then I can break >>> anywhere :) >>> >>> looks like this: >>> break main.c:360 >>> r >>> dis >>> break compile_jit_a_method >>> c >>> dis >>> break whatever function you want >>> >>> You can make it a script via GDB's 'define' and put somewhere in >>> ~/.gdbinit, two scripts are better: first for initial run, the second >>> script does the same but reusing old breakpoint numbers: >>> dis >>> en 1 >>> r >>> dis >>> en 2 >>> c >>> dis >>> >>> I should put that into the FAQ, obviously. >>> >>> >>> And then when I run the program it never stops at the breakpoint, though I see the print I have inserted in the code. Secondly, and more importantly, if I try to do anything interesting, like run helloworld, gdb seems to lose a thread and then hang (says it Cannot find a thread. Invalid thread handle). I have to then stop it and go kill it. >>> this one is probably a separate issue (not connected with "future >>> shared library load"). Try my above suggestion, please. >>> >>> >>> GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r helloworld Starting program: /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 11007)] [New Thread 32769 (LWP 11010)] [New Thread 16386 (LWP 11011)] Cannot find thread 32769: invalid thread handle (gdb) q The program is running. Exit anyway? (y or n) y [1]+ Stopped gdb ./java Thanks, Armand On the 0x1F0 day of Apache Harmony Armand Navabi wrote: >> When I try to run ./java helloworld, it just hangs and I have to kill >> the proce
Re: [classlib][test]Deal with un-deleted temp files created in tests
Jimmy, Jing Lv 写道: Hi, Recently I find some temp files created in tests are not deleted. We may delete them, or put them in test/resource . 1)in module\archive: modules\archive\GZIPOutFinish.txt modules\archive\GZIPOutClose2.txt modules\archive\GZIPOutWrite.txt modules\archive\JDK2-3gabba.zip Take a close look into it, the first three files are created in GZIPOutputStreamTest. Seems the files were deleted in tearDown(), but very strangely the lines of deleting files was comment-out without any comment. Do anyone know why? If I delete these files, no error was occurred in test on winxp. And the last file was created ZipFileTest, which has a comment that "Note zfile is a user-defined zip file used by other tests and should not be deleted", it seems it must be put in resource directory. However,if I do delete it in tearDown(), no error was occurred while run archive test on winxp. 2)in luni: modules\luni\hyts_missingclass.ser This file is created in ObjectInputStreamTest. The test try to test serialization, however it did not follow our serialization-test framework. The fix is easy (change it to use the framework). 3)in jndi: a new directory "org\apache\harmony\jndi\tests\javax\naming\spi" with a file "jndiprovider.properties" and a sub directory "mock". This directory is created in NamingManagerTest, I guess it must be put in some place in test\resource ? Any suggestions/comments? And any more such files to deal? Thanks! Put them in places where are appropriate according to various guide lines. 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: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1 -Mark. On 28 September 2006 at 1:38, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > BCC and ACQs are in. > > What say ye? Would it be nice to debug using eclipse debugger in DRLVM? > > [ ] + 1 accept this contribution into the project > [ ] -1 don't accept (please give reason) > > Vote runs usual 3 days unless protest or early completion. > > geir > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] current tests - can we focus on getting everything to pass?
Right now, we have lots of tests that are skipped in smoke tests, and some that fail in kernel, and I believe that we're still failing the classlib test suite. We should drive this to goodness and health. How shall we start? :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][test]Deal with un-deleted temp files created in tests
Hi, Recently I find some temp files created in tests are not deleted. We may delete them, or put them in test/resource . 1)in module\archive: modules\archive\GZIPOutFinish.txt modules\archive\GZIPOutClose2.txt modules\archive\GZIPOutWrite.txt modules\archive\JDK2-3gabba.zip Take a close look into it, the first three files are created in GZIPOutputStreamTest. Seems the files were deleted in tearDown(), but very strangely the lines of deleting files was comment-out without any comment. Do anyone know why? If I delete these files, no error was occurred in test on winxp. And the last file was created ZipFileTest, which has a comment that "Note zfile is a user-defined zip file used by other tests and should not be deleted", it seems it must be put in resource directory. However,if I do delete it in tearDown(), no error was occurred while run archive test on winxp. 2)in luni: modules\luni\hyts_missingclass.ser This file is created in ObjectInputStreamTest. The test try to test serialization, however it did not follow our serialization-test framework. The fix is easy (change it to use the framework). 3)in jndi: a new directory "org\apache\harmony\jndi\tests\javax\naming\spi" with a file "jndiprovider.properties" and a sub directory "mock". This directory is created in NamingManagerTest, I guess it must be put in some place in test\resource ? Any suggestions/comments? And any more such files to deal? Thanks! -- 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: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1 from me On Sep 28, 2006, at 1:38 AM, Geir Magnusson Jr. wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] HARMONY-1410 : JDWP agent for DRLVM
BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
I've just repeated kernel.test run today several times on fresh build, and tests pass. It's a very stange crash. Execute JIT stack iterator in interpreter mode.. It's outlandishly. On 28/09/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: I do not observe this crash - I ran kernel tests yesterday and today several times, no crashes on interpreter on Linux IA32... 2006/9/28, Gregory Shimansky <[EMAIL PROTECTED]>: > On Wednesday 27 September 2006 16:35 Geir Magnusson Jr. wrote: > > :) > > > > Is there an easy fix, or do we rollback? > > Interpreter is meant for the development for the most part. I think it is not > critical if it doesn't work for a short time. It is not used by most of the > community anyway because they don't specify -Xint option to run the programs. > > I hope the patch submitter will respond with a fix soon enough. > > -- > Gregory Shimansky, Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Pavel Rebriy
Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
I do not observe this crash - I ran kernel tests yesterday and today several times, no crashes on interpreter on Linux IA32... 2006/9/28, Gregory Shimansky <[EMAIL PROTECTED]>: On Wednesday 27 September 2006 16:35 Geir Magnusson Jr. wrote: > :) > > Is there an easy fix, or do we rollback? Interpreter is meant for the development for the most part. I think it is not critical if it doesn't work for a short time. It is not used by most of the community anyway because they don't specify -Xint option to run the programs. I hope the patch submitter will respond with a fix soon enough. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Re: [VOTE] HARMONY-1217 : JNI-style C header file generator (aka 'javah')
On our way to tools... +1 from Nathan, Paulex, Alexey, Salikh, Oleg, geir, Ilya, Tim, Mark Stepan done... On Sep 24, 2006, at 10:43 PM, Geir Magnusson Jr. wrote: All is in order and in SVN for Harmony-1217 wrt BCC and ACQ. Please vote to accept or reject this contribution into the Apache Harmony project : [ ] + 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]
Re: [doc] new "Getting Started" guides
On Sep 27, 2006, at 10:53 PM, Stepan Mishura wrote: t is great that you've created guides and put references to them at top. So now it is clear for newcomer what the next step is. And I'd like to suggest the following improvement for contributors guide: the page contains only few words about projects parts and it may create impression that Harmony is a one big/complex piece of software that has a lot of dependencies to download. I think that it is important to say clearly in the beginning of the page that the project consists of many quite independent parts. And the newcomer has a choice to work with whole code base (a.k.a. federated build) or with a part of the project. So the top of the page should contain two references to federated build and to a description of the project's components. I understand. Remember, this is targetted for newbies - people who don't know anything yet, and what it tries to do is find the fastest path to getting working code from a single checkout. We have instructions for federated build. It looks OK for me. And the description of components should give detailed picture of all components not just mention VM and Classlib. And the components' description should points to components' homepages. Good point. But what other components right now would you point to? BTW, just random idea. I'd let each module to live by its own life by having its own homepage, releases, mailing list and JIRA component, like we have for ORB module (Apache Yoko project). Does this make sense? No. There no sense in releasing just a classlibrary or a virtual machine. Or a toolset. You need the whole pile. I think we need to continue to focus on our primary goal, java SE. I've also been concerned about having "subprojects" that are too independent, creating sub-communities. I think that should be avoided at all cost. Sure, we each have our focus and specialization, but we're one project, one community. We have categories for JIRA - doesn't that work? Mail list is busy, but right now we seem to be doing ok in terms of segmenting by subject line, and quite frankly, I still think that the benefits of intermixing currently outweigh the costs. yes, we need a user list soon, and someday we'll split VM from classlib, but right now, there's such good collaboration... As for homepages, we already have that - basic pages for each major component. geir 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM
On 9/28/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: On 9/26/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: > > On 9/27/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote: > > (3) > > One more lock is added - hythread_lib_lock. How is that differ from > > the hythread_global_lock that we already have? Each extra lock to the > > system may add more possibilities for deadlocks, as well as can > > negatively impact the scalability (unless some of the existing locks > > are split). > hythread_lib_lock acquires exactly the same lock as > hythread_global_lock. Probably I miss something but we need to be > compatible with IBM threading library now. This library has such > function. That's why I added it. Sounds right? Well, this sort of, kind of sounds right but not quite. Its a little more subtle than being compatible with IBM threading library. The first goal is to identify the parts of IBM threading library that are JVM independent. It makes sense for DRLVM to be compatible with the independent parts. This should be a nobrainer. The parts of IBM threading library that assume a specific JVM implementation will be a problem. We will need to find a solution that is endorsed by all the stakeholders (including J9 folks). The hythread_global_lock falls into this category. For starts, I would like to see a concise description from the portlib owners on what hythread_global_lock protects, which locks have to be held before grabbing this lock, are there any restrictions on what system calls can be made while holding this lock (like sleep or wait), etc. Weldon, I completely agree with what your are saying. It's common problem of current hythread that should be resolved some how. I just go inline with current implementation and added two missing functions. Missing these can lead to the same problems as with hythread_exit discussed in another thread "[drlvm] [launcher] Executable hangs". To get a better idea what's in the patch.diff, I printed it out. Its 120+ pages. Quite a big patch! Most of it looks like straight forward JNI interface glue. There are some tricky parts. I would like to know the design review process for these parts. Using grep, I found 20 locations where ...suspend_enable... and ...suspend_disable... have been added. And 25 locations where enable/disable have been removed. Failure in this logic can lead to incorrect reference pointer enumeration. These are probably the hardest bugs to find. Please tell us who has looked at this code in depth. Only me and you :-) Honetsly I think it happpens now Are there any known design flaws in it? I can think of two possible problems we may want to discuss. 1) Should native threads have "daemon" status or its completely java notion? This is TM related thing. 2) Should we attach thread to VM before attaching it to TM by calling jthread_atatch OR jthread_attach should callback VM to attach a thread to it? I didn't change original design of TM here .. it implements second choice. I also notice APIs called tmn_suspend_enable(), hythread_suspend_enable() -- are these simply different names for the same binary executible. Or different binaries that do the same thing?? No, this is not just different names. tm_suspend_enable asserts that thread is in disabled state before calling hythread_suspend_enable (in debug mode only). Thanks Evgueni -- > 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] HARMONY-1582 - invocation API for DRLVM
On Sep 27, 2006, at 4:04 PM, Weldon Washburn wrote: On 9/26/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: On 9/27/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote: > (3) > One more lock is added - hythread_lib_lock. How is that differ from > the hythread_global_lock that we already have? Each extra lock to the > system may add more possibilities for deadlocks, as well as can > negatively impact the scalability (unless some of the existing locks > are split). hythread_lib_lock acquires exactly the same lock as hythread_global_lock. Probably I miss something but we need to be compatible with IBM threading library now. This library has such function. That's why I added it. Sounds right? Well, this sort of, kind of sounds right but not quite. Its a little more subtle than being compatible with IBM threading library. The first goal is to identify the parts of IBM threading library that are JVM independent. It makes sense for DRLVM to be compatible with the independent parts. This should be a nobrainer. It's not IBM's threading library. It's Harmony's threading library. :) 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][classlib] thread library - let there be one!
On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote: +1 on the below. I am assuming Andrey and his team will do this work. (Andrey, when will you start?) We have to start first by pulling hythread out, but where? After thinking about it for 5 more seconds, putting it on the top level enhanced/ is IMO a bad idea. There's nothing worse than going to a project's SVN and finding tons of confusing things. Is there any downside to keeping it somewhere under /classlib/trunk and simply make it a module by itself? Hopefully we can clean up how drlvm handles the classlib portlib function table at the same time. Currently two versions of this table are created during startup. "Portlib function table - let there be one!" Seriously, this is incredibly difficult code to maintain. On 9/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Yes, exactly. Regards, Tim Andrey Chernyshev wrote: > On 9/26/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote: >> >> > Weldon, I agree with your comments and observations below. Let's take >> > baby steps to get fully unified. I'm sure we all want to keep things >> > working throughout. >> >> So what's the first stop? Move hythread as-is out of classlib to a >> peer in the tree? > > I can suggest the following steps: > - pull out hythread from classlib, make it a shared component > - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and > upper layer (hythead_xxx) > - migrate classlib code to the bottom layer (1) of hythread > - migrate DRLVM's thread manager to (1) from APR > Each step can be done without breaking the whole code stack. > As a result, we'll have a bottom part of hythread which will be shared > between the classlib and DRLVM. > > Some additional steps could be: > - pull the rest of the portlib out of the classlib, make it a shared > component as well > - migrate DRLVM to portlib > > Thanks, > Andrey. > > >> >> geir >> >> > >> > Regards, >> > Tim >> > >> > Weldon Washburn wrote: >> >> On 9/20/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> >>> >> >>> Artem Aliev wrote: >> Gier, >> >> The hythread is just most visible example. There are also signal >> handling problem. classlib hysig lib setup signal handlers and then >> drlvm overrides them by its owns. There are code duplication in >> classlib hyprt.dll drlvm port.lib: >> classlib/trunk/modules/luni/src/main/native/port vm/port/src >> >> These three pair of components contains significant part of the >> system dependent code for both VM and CLASSLIB. I think, all this >> code naturally defines portlib component that could be shared >> between >> classlib and VMs. So, as a first step, we could move all this >> code in >> to the one place, name portlib to have three directories classlib, >> drlvm, portlib. >> >>> >> >>> I think it is quite reasonable to call out the portlib and threadlib >> >>> separate (in the repository) to the VM and classlib. As you >> >>> point out, >> >>> then VM and classlib can share the code -- though it will not >> >>> become a >> >>> requirement for VMs that run the harmony code to be using those >> >>> libraries for their own implementation. >> >> >> >> >> >> Tim, >> >> One of the things to worry about is system-wide lock protocol. We >> >> will >> >> need >> >> to think through what locks portlib, threadlib and JVM are holding >> >> and if >> >> there are any deadlock possibilities. >> >> >> >> Another issue is the implementation of signal chaining. There >> >> seems to be >> >> code in hysignal.c that implement "-Xrs". I guess the idea is that a >> >> Harmony JVM would somehow not link this code and use its own >> >> implementation. The bottom line is that we probably need to >> >> carefully pick >> >> through what is currently in classlib threads/signals and rearrange >> >> stuff so >> >> that it reduces the confusion. We need to make this part of the >> >> system >> >> much >> >> easier to work on. >> >> >> >> Do you have recommendations on next steps? Does it make sense to >> >> start >> >> moving stuff into the directories described above. Or is more >> >> discussion >> >> needed. >> >> >> >> >> >> >> >>> As the second step, the pairs of libraries should be merged and the >> classlib and drlvm refactoried to have only 3 lib instead of 6. >> >>> >> >>> Yep, this would be part of the consolidation into new Harmony top- >> >>> level >> >>> components. It makes sense that we share the same impl in the >> >>> project. >> >>> >> The 3rd step is to replace most of the functions with APR ones and >> move the rest of the code to the APR. >> >>> >> >>> I think it is quite well documented on this list that this should >> >>> not be >> >>> a goal. >> >> >> >> >> >> I agree we don't need to move classlib to APR provided
Re: [general] jre and hdk snapshots posted to general snapshot site
On Sep 27, 2006, at 10:16 AM, Alexei Zakharov wrote: If we plan to use HDK for supporting developers who work on single module (that is a good idea IMHO) That was one of the originally stated motivations, yes. then we definitely need to supply jar with tests. We may also supply the build file with placeholders for user classes & tests dirs that will be prepended to classpath/bootclasspath. Something like that, yes. geir Regards, 2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>: On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > If I recall, the point of the test.jar was to have a pre-built jar of > tests in the HDK so that someone could setup the build-test infra > using the HDK so they could run tests on their platform w/o having to > build everything. Good idea. Yes, you are correct. This idea implemented in the jira 964. If that's so, then something would > have to be configured to have the classlib "test" target use that > jar. All I'm saying is that how we do this is important, as we don't > want to cause pain for classlib developers who use the HDK for > development support. Seems, we think about different use cases. In my case, user can download the HDK for own platform (if we have one) run tests and look on results (also, may be upload it to the harmony site). Also it can be used for application run to check 'enable' status. But if this user interested in Harmony development he should checkout ws and use built-in ant targets to build and test updated ws. How you plan to use HDK? It looks like initial miscommunication :) thanks, Vladimir > geir > > > > > Thanks, Vladimir > > > > > > > > > > > >> > Thanks, Vladimir > >> > > >> > geir > >> >> > >> >> > > >> >> > > >> >> > > >> >> > Thanks, Vladimir > >> >> > > >> >> > > >> >> > > >> >> > On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > >> >> >> > >> >> >> They are at the regular place > >> >> >> > >> >> >> http://people.apache.org/dist/incubator/harmony/snapshots > >> >> >> > >> >> >> I moved all the old classlib snapshots into /old and I'll > >> >> update the > >> >> >> website accordingly. I'll be automating this. Also, lets not > >> >> >> make much > >> >> >> noise about this for a little while so we can test to make sure > >> >> >> there's > >> >> >> no major errors. Things seem good. I have a list of more > >> >> things to > >> >> >> fix, but I realized today that I was obsessing over the > >> snapshot > >> >> >> contents - it's not a release, and it's "good enough". > >> >> >> > >> >> >> I'd like to ditch both /old and the remaining classlib > >> >> snapshots, as > >> >> >> > >> >> >> 1) they are snapshots - history doesn't matter > >> >> >> > >> >> >> 2) the classlib is now in the HDK, so we just need to adjust > >> the > >> >> >> docs to > >> >> >> match. > >> >> >> > >> >> >> I'll do the latter, but wanted to see if anyone has a problem > >> >> w/ me > >> >> >> removing /old and the last classlib snapshot. I'll do this > >> if I > >> >> >> don't > >> >> >> hear any protest, so either positively acknowledge this action > >> >> if you > >> >> >> support it, dont' do a thing if you support or dont' care, > >> or say > >> >> >> why we > >> >> >> shouldn't :) > >> >> >> > >> >> >> geir > >> >> >> > >> >> >> > >> >> > >> - > >> >> >> Terms of use : http://incubator.apache.org/harmony/ mailing.html > >> >> >> To unsubscribe, e-mail: harmony-dev- > >> >> [EMAIL PROTECTED] > >> >> >> For additional commands, e-mail: harmony-dev- > >> >> >> [EMAIL PROTECTED] > >> >> >> > >> >> >> > >> >> > >> >> > >> >> > >> - > >> >> Terms of use : http://incubator.apache.org/harmony/ mailing.html > >> >> To unsubscribe, e-mail: harmony-dev- > >> [EMAIL PROTECTED] > >> >> For additional commands, e-mail: harmony-dev- > >> >> [EMAIL PROTECTED] > >> >> > >> >> > >> > >> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] > >> For additional commands, e-mail: harmony-dev- > >> [EMAIL PROTECTED] > >> > >> > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] > For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] > > -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/maili
Re: [testing] HARMONY-995: adding new target to builds for automatic testing
On Sep 27, 2006, at 10:12 AM, Vladimir Ivanov wrote: On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: How will you be able to grab that information from the logs, so I can see histories and such? I'm not going to go manually scanning logs. I want a web page that shows me the history. This is what the CI system does right now. Why would we want to reverse that? I want to be able to graph the times to look for aberrations I guess you can write log-scanning code, but that seems to be longer than the 19 extra lines that would be in the script for cruise control... OK. At least now I see a difference. You think about web-interface primary but I about notification interface. No. i think about the data. The fact that I use a web interface to look at that data is irrelevant. As to notification, we can program the thing to do any behavior you want. There's no need to require a 1:1 mapping of notification behavior to build target in classlib. In both cases to define the reason of failure you should scanning logs but to see the 'current state' web interface more convenient. At nearest time I will experiment with both systems to define the best one and share results. thanks, Vladimir geir > > thanks, Vladimir > > Maybe I'm misunderstanding your motivation? >> >> Having that target in classlib is fine. But I can't see why we'd >> ever want to use it in the context that we are discussing it >> >> geir >> >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] >> For additional commands, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> >> - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run
You should guess where... On Sep 27, 2006, at 9:51 AM, Denis Kishenko wrote: I should guess 2006/9/27, Geir Magnusson Jr. <[EMAIL PROTECTED]>: I have a tattoo. geir On Sep 27, 2006, at 8:52 AM, Denis Kishenko wrote: > do you wear such one =) > > 2006/9/27, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> you can wear it too if you want. either share with Vladimir, or make >> your own copy :) >> >> On Sep 27, 2006, at 8:39 AM, Denis Kishenko wrote: >> >> > Vladimir, my congratulations! >> > >> > 2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>: >> >> Thanks :) >> >> >> >> On 9/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> >> > >> >> > Here's a badge for you to cut out and wear >> >> > >> >> > +-+ >> >> > | Harmony | >> >> > | Champion! | >> >> > +-+ >> >> > >> >> > Keep up the good work! >> >> > >> >> > Regards, >> >> > Tim >> >> > >> >> > Vladimir Ivanov wrote: >> >> > > It is my 200 issue in Harmony. Seems, I'm the champion :) >> >> > > >> >> > > -- Forwarded message -- >> >> > > From: Vladimir Ivanov (JIRA) <[EMAIL PROTECTED]> >> >> > > Date: Sep 25, 2006 7:50 PM >> >> > > Subject: [jira] Created: (HARMONY-1569) [drlvm][testing] >> >> JAVA_HOME >> >> > veriable >> >> > > should be set to tested runtime before test run >> >> > > To: [EMAIL PROTECTED] >> >> > > >> >> > > [drlvm][testing] JAVA_HOME veriable should be set to tested >> >> runtime >> >> > before >> >> > > test run >> >> > > >> >> > >> >> >> - >> >> -- >> >> > > >> >> > > >> >> > >Key: HARMONY-1569 >> >> > >URL: http://issues.apache.org/jira/browse/ >> >> HARMONY-1569 >> >> > >Project: Harmony >> >> > > Issue Type: Improvement >> >> > > Components: DRLVM >> >> > > Reporter: Vladimir Ivanov >> >> > > >> >> > > >> >> > > Now, the system JAVA_HOME variable is used. The value should >> >> point to >> >> > > tested >> >> > > runtime. >> >> > > >> >> > > -- >> >> > > 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 >> >> > > >> >> > >> >> > -- >> >> > >> >> > Tim Ellison ([EMAIL PROTECTED]) >> >> > IBM Java technology centre, UK. >> >> > >> >> > >> >> >> - >> >> > Terms of use : http://incubator.apache.org/harmony/ mailing.html >> >> > To unsubscribe, e-mail: harmony-dev- >> >> [EMAIL PROTECTED] >> >> > For additional commands, e-mail: harmony-dev- >> >> [EMAIL PROTECTED] >> >> > >> >> > >> >> >> >> >> > >> > >> > -- >> > Denis M. Kishenko >> > Intel Middleware Products Division >> > >> > >> - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> > For additional commands, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> > >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] >> For additional commands, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> >> > > > -- > Denis M. Kishenko > Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] > For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Denis M. Kishenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] new "Getting Started" guides
Fixed. Thanks. No, you weren't being too picky - you were right on :) geir On Sep 27, 2006, at 8:44 AM, Sian January wrote: Hi Geir, Those new documents look really good. I just found a few spelling mistakes on the first one (http://incubator.apache.org/harmony/ quickhelp_users.html). In the first paragraph "no development tools our need to" should probably be "no development tools or need to". In the fourth paragraph "run well on the paltforms offered" should be "run well on the platforms offered" and in the fifth paragraph I think "unpack inÄto a jre directory" should be "unpack into a jre directory". I hope you don't think I'm being picky - I just think it's better for the project's image if we have correct spelling and grammar etc on the website. Thanks, Sian On 22/09/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: As discussed earlier today, there are now two new "Getting Started" guides on the website, accessible from the homepage. http://incubator.apache.org/harmony/quickhelp_users.html http://incubator.apache.org/harmony/quickhelp_contributors.html There is still more work to do - for example, we need to fill in the lists of tools needed and dependencies. (I'll add a fresh Ubuntu VM in Parallels tomorrow and work though all the deps that need to be added) Give a read, test it out, and comment... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Sian January 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]
[vm] IBM VME related issues
Here is the list of JIRA issues which should not slip attention of IBM engineers: HARMONY-1596 HARMONY-1309 HARMONY-813 These are just the ones I'm aware of, please extend this list if you know some :) -- 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: [drlvm] [launcher] Executable hangs
On the 0x1F2 day of Apache Harmony Armand Navabi wrote: > This did not seem to solve the problem. It does not successfully put a > break in main.c (says no source file main.c). Oops, some day I made everything build in debug mode locally. And forgot about it. Currently there is no option for that. TBD, obviously. I do it with the patch (linux only) like this: Index: working_vm/build/build.sh === --- working_vm/build/build.sh (revision 449589) +++ working_vm/build/build.sh (working copy) @@ -80,6 +80,6 @@ # it is necessarily to compile 'vm.jitrino' in release mode -$ANT_COMMAND -f ./make/build.xml -Dvm.jitrino.cfg=release "$@" || ERROR +$ANT_COMMAND -f ./make/build.xml "$@" || ERROR Index: working_vm/build/make/components/vm/jitrino.xml === --- working_vm/build/make/components/vm/jitrino.xml (revision 449589) +++ working_vm/build/make/components/vm/jitrino.xml (working copy) @@ -25,7 +25,7 @@ --> - + @@ -50,7 +50,8 @@ - + + Index: working_vm/build/make/targets/common_vm.xml === --- working_vm/build/make/targets/common_vm.xml (revision 449589) +++ working_vm/build/make/targets/common_vm.xml (working copy) @@ -105,6 +105,8 @@ + + Index: working_classlib/depends/build/makefile.include === --- working_classlib/depends/build/makefile.include (revision 448846) +++ working_classlib/depends/build/makefile.include (working copy) @@ -28,5 +28,5 @@ DLLPATH=$(HY_HDK)/jdk/jre/bin/ SHAREDSUB=../shared/ -CFLAGS = -O1 $(HY_CFLAGS) -DLINUX -D_REENTRANT -DIPv6_FUNCTION_SUPPORT \ +CFLAGS = -O0 -g $(HY_CFLAGS) -DLINUX -D_REENTRANT -DIPv6_FUNCTION_SUPPORT \ -D$(HY_ARCH_DEFINE) $(VMDEBUG) -I$(HY_HDK)/include -I$(HY_HDK)/jdk/include -I. -I$(SHAREDSUB) Guys, I hope someone finishes that into a final solution so we can put that to SVN. Most likely, I'll do that, when I am done with fixing Jitrino.OPT to run the ClassLoaderTest. Any volunteering is, as always, welcome)) > [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ gdb > ./java > GNU gdb 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db > library "/lib/libthread_db.so.1". > > (gdb) break main.c:360 > No source file named main.c. > Make breakpoint pending on future shared library load? (y or [n]) n > (gdb) show environment > > ... > LD_LIBRARY_PATH=/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/:/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default/ > ... > JAVA_HOME=/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre > ... > > > I am able to do "break main", but I tried to do what you have explained > below (i.e. break somewhere after libjitrino.so is loaded), but it says > compile_jit_a_method is not defined. Thank you for digging into it. That's really valuable. I hope we will fix the issue soon. > Thanks, > Armand > > Egor Pasko wrote: > > I solve this by breaking inside launcher after VM lib is loaded, then > > I break somewhere after libjitrino.so is loaded. Then I can break > > anywhere :) > > > > looks like this: > > break main.c:360 > > r > > dis > > break compile_jit_a_method > > c > > dis > > break whatever function you want > > > > You can make it a script via GDB's 'define' and put somewhere in > > ~/.gdbinit, two scripts are better: first for initial run, the second > > script does the same but reusing old breakpoint numbers: > > dis > > en 1 > > r > > dis > > en 2 > > c > > dis > > > > I should put that into the FAQ, obviously. > > > > > >> And then when I run the program it never stops at the breakpoint, though I > >> see the print I have inserted in the code. Secondly, and more importantly, > >> if I try to do anything interesting, like run helloworld, gdb seems to lose > >> a thread and then hang (says it Cannot find a thread. Invalid thread > >> handle). I have to then stop it and go kill it. > >> > > > > this one is probably a separate issue (not connected with "future > > shared library load"). Try my above suggestion, please. > > > > > >> GNU gdb 6.4 > >> Copyright 2005 Free Software Foundation, Inc. > >> GDB is free software, covered by the GNU General Public License, a
Re: [drlvm] [launcher] Executable hangs
This did not seem to solve the problem. It does not successfully put a break in main.c (says no source file main.c). [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ gdb ./java GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) break main.c:360 No source file named main.c. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) show environment ... LD_LIBRARY_PATH=/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/:/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default/ ... JAVA_HOME=/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre ... I am able to do "break main", but I tried to do what you have explained below (i.e. break somewhere after libjitrino.so is loaded), but it says compile_jit_a_method is not defined. Thanks, Armand Egor Pasko wrote: > I solve this by breaking inside launcher after VM lib is loaded, then > I break somewhere after libjitrino.so is loaded. Then I can break > anywhere :) > > looks like this: > break main.c:360 > r > dis > break compile_jit_a_method > c > dis > break whatever function you want > > You can make it a script via GDB's 'define' and put somewhere in > ~/.gdbinit, two scripts are better: first for initial run, the second > script does the same but reusing old breakpoint numbers: > dis > en 1 > r > dis > en 2 > c > dis > > I should put that into the FAQ, obviously. > > >> And then when I run the program it never stops at the breakpoint, though I >> see the print I have inserted in the code. Secondly, and more importantly, >> if I try to do anything interesting, like run helloworld, gdb seems to lose >> a thread and then hang (says it Cannot find a thread. Invalid thread >> handle). I have to then stop it and go kill it. >> > > this one is probably a separate issue (not connected with "future > shared library load"). Try my above suggestion, please. > > >> GNU gdb 6.4 >> Copyright 2005 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db >> library "/lib/libthread_db.so.1". >> >> (gdb) r helloworld >> Starting program: >> /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java >> helloworld >> [Thread debugging using libthread_db enabled] >> [New Thread 16384 (LWP 11007)] >> [New Thread 32769 (LWP 11010)] >> [New Thread 16386 (LWP 11011)] >> Cannot find thread 32769: invalid thread handle >> (gdb) q >> The program is running. Exit anyway? (y or n) y >> >> [1]+ Stopped gdb ./java >> >> >> Thanks, >> Armand >> >> >> On the 0x1F0 day of Apache Harmony Armand Navabi wrote: >> When I try to run ./java helloworld, it just hangs and I have to kill the process. I investigated this a little bit, and I found that it hangs on the call to FindClass (in main.c line around line 1199). I am unable debug with gdb also, so I have resorted to printf's, and in jni.cpp, I found the definition of FindClass, and put an printf to see what class it is trying to find when it hangs. I see the following: Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread Also, when I run ./java -Xtrace:em, I get the following (and it hangs): ... EM: compile start:[JET_DPGO n=802] java/lang/Thread::join()V EM: compile done:[JET_DPGO n=802: OK] java/lang/Thread::join()V EM: compile start:[JET_DPGO n=803] java/lang/Object::wait()V EM: compile done:[JET_DPGO n=803: OK] java/lang/Object::wait()V Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread Again, it seems to always hang after FindClass is called for java/lang/Thread. I have tried setting LD_LIBRARY_PATH as suggested earlier. I also have JAVA_HOME set (and I have tried it with it unset). Everything seems to have the same behavior. [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $LD_LIBRARY_PATH /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/:/ homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/ default [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $JAVA_HOME /homes/anavabi/Harmony/enhanc
Re: [doc] new "Getting Started" guides
On 9/22/06, Geir Magnusson Jr. wrote: As discussed earlier today, there are now two new "Getting Started" guides on the website, accessible from the homepage. http://incubator.apache.org/harmony/quickhelp_users.html http://incubator.apache.org/harmony/quickhelp_contributors.html There is still more work to do - for example, we need to fill in the lists of tools needed and dependencies. (I'll add a fresh Ubuntu VM in Parallels tomorrow and work though all the deps that need to be added) Give a read, test it out, and comment... Hi Geir, It is great that you've created guides and put references to them at top. So now it is clear for newcomer what the next step is. And I'd like to suggest the following improvement for contributors guide: the page contains only few words about projects parts and it may create impression that Harmony is a one big/complex piece of software that has a lot of dependencies to download. I think that it is important to say clearly in the beginning of the page that the project consists of many quite independent parts. And the newcomer has a choice to work with whole code base (a.k.a. federated build) or with a part of the project. So the top of the page should contain two references to federated build and to a description of the project's components. We have instructions for federated build. It looks OK for me. And the description of components should give detailed picture of all components not just mention VM and Classlib. And the components' description should points to components' homepages. BTW, just random idea. I'd let each module to live by its own life by having its own homepage, releases, mailing list and JIRA component, like we have for ORB module (Apache Yoko project). Does this make sense? 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: [general] jre and hdk snapshots posted to general snapshot site
On 9/27/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: If we plan to use HDK for supporting developers who work on single module (that is a good idea IMHO) then we definitely need to supply jar with tests. We may also supply the build file with placeholders for user classes & tests dirs that will be prepended to classpath/bootclasspath. It is just other use case. If nobody objects I'll prepare patches for it. thanks, Vladimir Regards, 2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>: > On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > > > > > If I recall, the point of the test.jar was to have a pre-built jar of > > tests in the HDK so that someone could setup the build-test infra > > using the HDK so they could run tests on their platform w/o having to > > build everything. Good idea. > > > Yes, you are correct. This idea implemented in the jira 964. > > If that's so, then something would > > have to be configured to have the classlib "test" target use that > > jar. All I'm saying is that how we do this is important, as we don't > > want to cause pain for classlib developers who use the HDK for > > development support. > > > > Seems, we think about different use cases. > > In my case, user can download the HDK for own platform (if we have one) run > tests and look on results (also, may be upload it to the harmony site). Also > it can be used for application run to check 'enable' status. But if this > user interested in Harmony development he should checkout ws and use > built-in ant targets to build and test updated ws. > > > > How you plan to use HDK? It looks like initial miscommunication :) > thanks, Vladimir > > > > > geir > > > > > > > > Thanks, Vladimir > > > > > > > > > > > > > > > > > >> > Thanks, Vladimir > > >> > > > >> > geir > > >> >> > > >> >> > > > >> >> > > > >> >> > > > >> >> > Thanks, Vladimir > > >> >> > > > >> >> > > > >> >> > > > >> >> > On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > >> >> >> > > >> >> >> They are at the regular place > > >> >> >> > > >> >> >> http://people.apache.org/dist/incubator/harmony/snapshots > > >> >> >> > > >> >> >> I moved all the old classlib snapshots into /old and I'll > > >> >> update the > > >> >> >> website accordingly. I'll be automating this. Also, lets not > > >> >> >> make much > > >> >> >> noise about this for a little while so we can test to make sure > > >> >> >> there's > > >> >> >> no major errors. Things seem good. I have a list of more > > >> >> things to > > >> >> >> fix, but I realized today that I was obsessing over the > > >> snapshot > > >> >> >> contents - it's not a release, and it's "good enough". > > >> >> >> > > >> >> >> I'd like to ditch both /old and the remaining classlib > > >> >> snapshots, as > > >> >> >> > > >> >> >> 1) they are snapshots - history doesn't matter > > >> >> >> > > >> >> >> 2) the classlib is now in the HDK, so we just need to adjust > > >> the > > >> >> >> docs to > > >> >> >> match. > > >> >> >> > > >> >> >> I'll do the latter, but wanted to see if anyone has a problem > > >> >> w/ me > > >> >> >> removing /old and the last classlib snapshot. I'll do this > > >> if I > > >> >> >> don't > > >> >> >> hear any protest, so either positively acknowledge this action > > >> >> if you > > >> >> >> support it, dont' do a thing if you support or dont' care, > > >> or say > > >> >> >> why we > > >> >> >> shouldn't :) > > >> >> >> > > >> >> >> geir > > >> >> >> > > >> >> >> > > >> >> > > >> - > > >> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html > > >> >> >> To unsubscribe, e-mail: harmony-dev- > > >> >> [EMAIL PROTECTED] > > >> >> >> For additional commands, e-mail: harmony-dev- > > >> >> >> [EMAIL PROTECTED] > > >> >> >> > > >> >> >> > > >> >> > > >> >> > > >> >> > > >> - > > >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html > > >> >> To unsubscribe, e-mail: harmony-dev- > > >> [EMAIL PROTECTED] > > >> >> For additional commands, e-mail: harmony-dev- > > >> >> [EMAIL PROTECTED] > > >> >> > > >> >> > > >> > > >> > > >> - > > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: harmony-dev- > > >> [EMAIL PROTECTED] > > >> > > >> > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional com
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
On 9/27/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: Thanks to Egor and Gregory's responses to the JET write barrier patch. Those help. I was away from JIT development for a while. :-) Since the patch is small, if needed, please feel free to modify it as a JIRA update, or a committer to merge it then we submit new patch later. Basically the write barrier should be as small (quick) as possible and involves no additional VM runtime operations. A view to write barrier can be that, it is only an extended bytecode of the orignal reference store one. That means, we can implement it in anyway appropriate as long as the semantics of the reference store is kept, either in JIT IR, in LIL, Please no LiL. We need to replace LiL code with either Java/vmmagic, jit intrinsic or emitter based asm code. Even JIT IR would be preferable to LiL. in asm or as a function call. Performance and flexibility are the main goals. The performance is easy to understand, the flexibility refers to that a GC developer probably can conveniently change the write barrier implementation. As I know, a volunteer (Mikhail Fursov?) is writing helper inlining for DRLVM. Hopefully that will be the ultimate solution for write barrier implementation. Before that is ready, an intermediate solution would be acceptable. Thanks, xiaofeng > On 27 Sep 2006 17:20:36 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > I am curious about the switch > VM_Global_State::loader_env->use_lil_stubs. Does everything work in > both true and false? What do we need this switch for? Doesn't it > induce unnecessary complication/duplication? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division
Re: [classlib][awt] Non bug??? RI AffineTransform.transform(...) throws ArrayIndexOutOfBoundsException while Harmony doesn't
On 9/27/06, Denis Kishenko <[EMAIL PROTECTED]> wrote:
Hi all
RI implementation of AffineTransform of transform(float[], int,
float[], int, int) and transform(double[], int, double[], int, int)
methods throws ArrayIndexOutOfBoundsException if offset is out of
bounds and number of points to transform is zero. Harmony doesn't
throw any exception. Spec doesn't say about any exceptions.
RI use System.arraycopy(...) (see track trace) which throws this
exception. But Harmony doesn't use System.arraycopy(...) so we have
difference in behavior.
I see two possibilities
1. Stay as non-bug. If number of points is zero then logically we have
to do nothing w/o exceptions.
2. Follow RI. In this case we have to add checks like this
if (srcOff > src.length || dstOff > dst.length) {
throw new ArrayIndexOutOfBoundsException(...);
}
it looks a bit strange from my point of view.
I vote for non-bug.
Comments?
Hello Denis,
According to our "Compatibility Guidelines"[1], I suggest we follow RI
for this issue though you may feel uncomfortable about the additional
code ;-)
[1]http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
Best regards,
Richard
2006/9/27, Denis Kishenko (JIRA) <[EMAIL PROTECTED]>:
> [classlib][awt] RI AffineTransform.transform(...) throws
ArrayIndexOutOfBoundsException while Harmony doesn't
>
-
>
> Key: HARMONY-1606
> URL: http://issues.apache.org/jira/browse/HARMONY-1606
> Project: Harmony
> Issue Type: Bug
> Components: Non-bug differences from RI
>Reporter: Denis Kishenko
>
>
> RI implementation of AffineTransform of transform(float[], int, float[], int,
int) and transform(double[], int, double[], int, int) methods throws
ArrayIndexOutOfBoundsException if offsets are out of buffer bounds and number of
points to transform is zero. Harmony doesn't throw any exception. Spec doesn't say
about any exceptions.
>
> As you see from stack trace RI call System.arraycopy(...) which throws
exception because of offset is really out of bounds. But Harmony implementation
doesn't use System.arraycopy(...) so we have difference in behavior.
>
> === Test.java ===
> import java.awt.geom.AffineTransform;
>
> public class Test {
>static public void main(String[] args) {
>AffineTransform t = new AffineTransform();
>try {
>t.transform(new float[] {}, 1, new float[] {}, 2, 0);
>} catch (Exception e) {
>e.printStackTrace();
>}
>try {
>t.transform(new double[] {}, 1, new double[] {}, 2, 0);
>} catch (Exception e) {
>e.printStackTrace();
>}
>}
> }
>
> = RI ===
> java.lang.ArrayIndexOutOfBoundsException
>at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown
Source)
>at java.awt.geom.AffineTransform.transform(AffineTransform.java:2308)
>at Test.main(Test.java:10)
> java.lang.ArrayIndexOutOfBoundsException
>at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown
Source)
>at java.awt.geom.AffineTransform.transform(AffineTransform.java:2421)
>at Test.main(Test.java:15)
>
> Harmony ===
> nothing
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
--
Denis M. Kishenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test] "fail" statements omitted in many exception catching test cases
Great job, Robert. ;-)
I will have a look at sql.
On 9/28/06, Rui Hu <[EMAIL PROTECTED]> wrote:
Great Mark!
I've merged your code into my script. The script can be downloaded at [1].
Usage:
perl failFinder.pl root_of_module
e.g. Search out all related lines in luni module and redirect it to
result.txt
perl failFinder.pl trunk/modules/luni > result.txt
e.g. Search out all related lines in all modules and redirect it to
result.txt
perl failFinder.pl trunk/modules/ > result.txt
Anyone can find out the related lines of any modules.
[1]:
http://wiki.apache.org/harmony-data/attachments/failstatementsomitted/attachments/failFinder.pl
On 9/27/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
>
>
> This perl script does a marginally better job by being slightly stricter
> on matching context around 'catch'/'fail', by handling comments slightly
> better and by handling 'catch (...) { }' appearing on a single line.
>
> It also finds a few more hits such as:
>
> sql/src/test/java/org/apache/harmony/sql/tests/java/sql/TimeTest.java +208
>
> which is a false positive but which uses "assertTrue(false);" which
> should be fixed anyway.
>
> -Mark.
>
> #!/usr/bin/perl -w
> use strict;
>
> my $previous_line = "";
> my $possible_line_number;
> while (<>) {
> next if (/^\s*$/); # skip blank lines
> if ($possible_line_number) {
>if (m!^\s*(//|/\*|})!) {
> print $ARGV, ' +', $possible_line_number, "\n";
>}
>undef $possible_line_number;
> }
> if (!m!^\s*(/?\*|//)! && /\bcatch\s*\(/ && $previous_line !~
> /\bfail\s*\(/) {
>$possible_line_number = $.;
>if (/catch\s*\([^\)]+\)\s*{\s*}/) {
> print $ARGV, ' +', $possible_line_number, "\n";
> undef $possible_line_number;
>}
> }
> $previous_line = $_;
> }
>
> On 27 September 2006 at 15:02, Robert Hu <[EMAIL PROTECTED]> wrote:
> > --090601000506020908060004
> > Content-Transfer-Encoding: 7bit
> > Content-Type: text/plain; charset=GB2312
> >
> > Hi All,
> >
> > In our unit test of classlib, there are huge number of test cases about
> excep
> > tion catching. The typical style of those cases is like that:
> >
> > try {
> > someStatementShouldThrowAnException;
> > * fail("Expected an exception");*
> > } catch (SomeException e){
> > // Expected
> > }
> >
> > If we omit the "fail" statement, the test case is wrong because the
> exception
> > -throwing checking is disabled.
> >
> > I've found that the "fail" statement is omitted in many test cases of
> our Har
> > mony classlib. So I set some rules to find out all lines of code related
> with
> > it. If a line of code comform all the 5 rules, it may be a bug:
> > 1.in a "*Test.java" file
> > 2.does not start with "//"
> > 3.contains "catch"
> > 4.its previous line does not contains "fail"
> > 5.its next line contains "//" or "}"
> >
> >
> > Then I found out 1711 lines of code in 309 files comform all the 5 rules
> in r
> > 450321. (Attachment file is the result.)
> > Of course not all of them are bug, because some test cases are not of
> above s
> > tyle.
> >
> > And I also find out some real bugs, we can fix them easilly:
> >
> trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:
> > 652\658\664\670\676\685\698\704\711(line number)
> >
> trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTest.
> > java:57
> >
> trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileIn
> > putStreamTest.java:36
> >
> trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileOu
> > tputStreamTest.java:35
> > ..
> >
> > *I must say frankly that it's hard to find out all bugs of this kind
> without
> > any "victims" automatically, we must find out real bugs ourselves.*
> >
> > Hope the result in attachment file can help us to find out more bugs.
> >
> > Anybody has better search rules or better solution to find out those
> bugs? Pl
> > s. share with us, thanks a lot.
> >
> > --
> > Robert Hu
> > China Software Development Lab, IBM
> >
> >
> > --090601000506020908060004
> > Content-Type: text/plain;
> > name="result.txt"
> > Content-Disposition: inline;
> > filename="result.txt"
> > Content-Transfer-Encoding: quoted-printable
> >
> > current position is trunk\modules
> >
> .\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarF=
> > ileTest.java:66\79\190
> >
> .\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl=
> > aterOutputStreamTest.java:220\230
> >
> .\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl=
> > aterTest.java
> :188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\10=
> > 99\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
> >
> .\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipF=
> > ileTest.java:67\291
> >
> .\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipI=
> > nputStreamTest.java:200
> >
> .\auth\s
Re: [classlib][test] "fail" statements omitted in many exception catching test cases
Thanks for checking the result and working on it. I put the result on Harmony wiki[1], anyone is welcome to check the result to find some bugs. [1]:http://wiki.apache.org/harmony/failstatementsomitted On 9/27/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: Hi Robert, Nice work! I've checked the entries for classes from the beans module. It seems you found at least three bugs in tests for beans: Bugs: .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextServicesSupportTest.java:739 .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextSupportTest.java:1388 .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLEncoderTest.java:449 Valid: .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextSupportTest.java:234\251 .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\IntrospectorTest.java:1266\1304 .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\StatementTest.java:93 .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLDecoderTest.java:92 .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLEncoderTest.java:334 Thank you for this. I will file corresponding JIRA. Regards, -- Robert Hu China Software Development Lab, IBM
Re: [classlib][test] "fail" statements omitted in many exception catching test cases
Great Mark!
I've merged your code into my script. The script can be downloaded at [1].
Usage:
perl failFinder.pl root_of_module
e.g. Search out all related lines in luni module and redirect it to
result.txt
perl failFinder.pl trunk/modules/luni > result.txt
e.g. Search out all related lines in all modules and redirect it to
result.txt
perl failFinder.pl trunk/modules/ > result.txt
Anyone can find out the related lines of any modules.
[1]:
http://wiki.apache.org/harmony-data/attachments/failstatementsomitted/attachments/failFinder.pl
On 9/27/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
This perl script does a marginally better job by being slightly stricter
on matching context around 'catch'/'fail', by handling comments slightly
better and by handling 'catch (...) { }' appearing on a single line.
It also finds a few more hits such as:
sql/src/test/java/org/apache/harmony/sql/tests/java/sql/TimeTest.java +208
which is a false positive but which uses "assertTrue(false);" which
should be fixed anyway.
-Mark.
#!/usr/bin/perl -w
use strict;
my $previous_line = "";
my $possible_line_number;
while (<>) {
next if (/^\s*$/); # skip blank lines
if ($possible_line_number) {
if (m!^\s*(//|/\*|})!) {
print $ARGV, ' +', $possible_line_number, "\n";
}
undef $possible_line_number;
}
if (!m!^\s*(/?\*|//)! && /\bcatch\s*\(/ && $previous_line !~
/\bfail\s*\(/) {
$possible_line_number = $.;
if (/catch\s*\([^\)]+\)\s*{\s*}/) {
print $ARGV, ' +', $possible_line_number, "\n";
undef $possible_line_number;
}
}
$previous_line = $_;
}
On 27 September 2006 at 15:02, Robert Hu <[EMAIL PROTECTED]> wrote:
> --090601000506020908060004
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain; charset=GB2312
>
> Hi All,
>
> In our unit test of classlib, there are huge number of test cases about
excep
> tion catching. The typical style of those cases is like that:
>
> try {
> someStatementShouldThrowAnException;
> * fail("Expected an exception");*
> } catch (SomeException e){
> // Expected
> }
>
> If we omit the "fail" statement, the test case is wrong because the
exception
> -throwing checking is disabled.
>
> I've found that the "fail" statement is omitted in many test cases of
our Har
> mony classlib. So I set some rules to find out all lines of code related
with
> it. If a line of code comform all the 5 rules, it may be a bug:
> 1.in a "*Test.java" file
> 2.does not start with "//"
> 3.contains "catch"
> 4.its previous line does not contains "fail"
> 5.its next line contains "//" or "}"
>
>
> Then I found out 1711 lines of code in 309 files comform all the 5 rules
in r
> 450321. (Attachment file is the result.)
> Of course not all of them are bug, because some test cases are not of
above s
> tyle.
>
> And I also find out some real bugs, we can fix them easilly:
>
trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:
> 652\658\664\670\676\685\698\704\711(line number)
>
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTest.
> java:57
>
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileIn
> putStreamTest.java:36
>
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileOu
> tputStreamTest.java:35
> ..
>
> *I must say frankly that it's hard to find out all bugs of this kind
without
> any "victims" automatically, we must find out real bugs ourselves.*
>
> Hope the result in attachment file can help us to find out more bugs.
>
> Anybody has better search rules or better solution to find out those
bugs? Pl
> s. share with us, thanks a lot.
>
> --
> Robert Hu
> China Software Development Lab, IBM
>
>
> --090601000506020908060004
> Content-Type: text/plain;
> name="result.txt"
> Content-Disposition: inline;
> filename="result.txt"
> Content-Transfer-Encoding: quoted-printable
>
> current position is trunk\modules
>
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarF=
> ileTest.java:66\79\190
>
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl=
> aterOutputStreamTest.java:220\230
>
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl=
> aterTest.java
:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\10=
> 99\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
>
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipF=
> ileTest.java:67\291
>
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipI=
> nputStreamTest.java:200
>
.\auth\src\test\java\common\javax\security\auth\callback\ConfirmationCallba=
> ckTest.java:60\147
>
.\auth\src\test\java\common\javax\security\auth\callback\LanguageCallbackTe=
> st.java:60
>
.\auth\src\test\java\common\javax\security\auth\kerberos\ServicePermissionT=
> est.java:302
> .\auth\src\test\java\common\javax\security\auth\PolicyTest.java:132
>
.\auth\src\test
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
Thanks to Egor and Gregory's responses to the JET write barrier patch. Those help. I was away from JIT development for a while. :-) Since the patch is small, if needed, please feel free to modify it as a JIRA update, or a committer to merge it then we submit new patch later. Basically the write barrier should be as small (quick) as possible and involves no additional VM runtime operations. A view to write barrier can be that, it is only an extended bytecode of the orignal reference store one. That means, we can implement it in anyway appropriate as long as the semantics of the reference store is kept, either in JIT IR, in LIL, in asm or as a function call. Performance and flexibility are the main goals. The performance is easy to understand, the flexibility refers to that a GC developer probably can conveniently change the write barrier implementation. As I know, a volunteer (Mikhail Fursov?) is writing helper inlining for DRLVM. Hopefully that will be the ultimate solution for write barrier implementation. Before that is ready, an intermediate solution would be acceptable. Thanks, xiaofeng On 27 Sep 2006 17:20:36 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: I am curious about the switch VM_Global_State::loader_env->use_lil_stubs. Does everything work in both true and false? What do we need this switch for? Doesn't it induce unnecessary complication/duplication? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
On 27 Sep 2006 17:20:36 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: I am curious about the switch VM_Global_State::loader_env->use_lil_stubs. Does everything work in both true and false? What do we need this switch for? Doesn't it induce unnecessary complication/duplication? The LIL stub has been tested. It is there as a place holder for future write barrier optimizations. Thanks, xiaofeng - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
On 9/28/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: On Wednesday 27 September 2006 14:20 Egor Pasko wrote: > On the 0x1F1 day of Apache Harmony Xiao-Feng Li wrote: > > Thanks. Yes, this is supposed to be review by JIT person. On the other > > hand, if JIT person has better solution, GCv5 would like to use. > > Anyway we hope write barrier is to be functioning in the DRLVM soon. > > As a JIT-oriented guy, I looked through the patch. Looks good. The > write barrier does NOT push an M2N frame before invoking > gc_heap_slot_write_ref(), but it's OK since there will be no stack > unwinding from here. I want to make sure that there are going to be no JVMTI events sent inside of gc_heap_slot_write_ref. Otherwise M2N frame is necessary to allow stack iterator to work in case a JVMTI agent calls something like GetStackTrace. No, stack should never be examined in write barrier. That's completely contridicting the purpose of write barrier. Thanks, xiaofeng - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
On Wednesday 27 September 2006 16:35 Geir Magnusson Jr. wrote: > :) > > Is there an easy fix, or do we rollback? Interpreter is meant for the development for the most part. I think it is not critical if it doesn't work for a short time. It is not used by most of the community anyway because they don't specify -Xint option to run the programs. I hope the patch submitter will respond with a fix soon enough. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] [launcher] Executable hangs
Hmm never saw it hanging at this point. It looks like a java class loader starts on loading a j.l.Thread class and somehow deadlocks or waits for something. I would try to get a stack trace in the first place, evaluating st_print() in debugger but it doesn't always work correctly. Can anyone else suggest a way to debug this problem? On Wednesday 27 September 2006 09:35 Armand Navabi wrote: > Gregory Shimansky wrote: > > I think not. DRLVM needs its own threading library. The reason is > > discussed in a separate thread "thread library - let there be one". I am > > not sure I understand all the reasoning for separate libhythr.so > > implementation, but I know the drlvm version should be in bin/ and > > bin/default/ directories. > > Ok, I read that thread. Is there an easy temporary fix to this? > > > What is the reason to set breakpoint in jni.cpp:478? It is a condition > > that if JNI FindClass is called in exception state it shouldn't do > > anything, just return NULL. > > I'm sorry, my line 478 is different than yours, because I have other > prints and things in there. I was not putting the breakpoint on the > line that checks if it is called in exception state. Basically, I just > put a print inside of that procedure because I traced the hanging to > that method (or so I thought). My point was that I am unable to > breakpoints anywhere in jni.cpp. Below you have explained what problem > that is related to. And as far as tracing, you have suggested a much > more efficient way to trace where it is going in the code. Thanks. > > >> Make breakpoint pending on future shared library load? (y or [n]) y > >> > >> And then when I run the program it never stops at the breakpoint, though > >> I see the print I have inserted in the code. Secondly, and more > >> importantly, if I try to do anything interesting, like run helloworld, > >> gdb seems to lose a thread and then hang (says it Cannot find a thread. > >> Invalid thread handle). I have to then stop it and go kill it. > > > > The solution for this was found and discussed in thread "APR fails to > > load a JIT library when using a fully qualified path". The launcher execs > > itself with a new environment setting for LD_LIBRARY_PATH and gdb cannot > > work around this. > > I reread those threads and it seems some changes were suggested. Have > these changes been made. I couldn't see (or perhaps couldn't figure > out) any way to quickly fix this from the discussions. It seemed as > though people were suggesting moving and merging libraries. If it has > been fixed, I should have it because I have recently updated. > > > I have a proposal for you. Run "java -Xthread -Xtrace Hello" for hello > > world application. The -Xtrace option will produce a lot of output but it > > will enable all debugging tracing in drlvm and when it hangs for you it > > will be a very close location to the reason of the problem. If there is > > no output with -Xtrace, then it probably means launcher problems. Please > > update the sources, some launcher problems were resolved just recently > > I updated all the classlib and drlvm code earlier today. Just to make > sure we are talking about the same thing here, I have compiled > helloworld.java separately with Sun's compiler and then I made sure it > ran (it runs both with Sun's java and the classlib with IBM's VM), and > then I moved it to the drlvm's bin directory. > > There is no particular Hello application you are talking about correct? > The application I am running was a java program I wrote myself and > compiled. > > And then I tried to run my hello world application as you said. Like > you said it produced a lot of output and towards the end when it hanged, > this is the last output it produced: > > [0x4000] : Looking for native: > java/lang/VMThreadManager.start(Ljava/lang/Thread;JZI)I > [0x4000] : trying: Java_java_lang_VMThreadManager_start > [0x4000] : Compiled method > java/lang/VMThreadManager.start(Ljava/lang/Thread;JZI)I, entry 0xb68a4000 > [0x4000] : GetObjectClass called > [0x4000] : GetObjectClass: class = java/lang/FinalizerThread > [0x4000] : GetFieldID called > [0x4000] : GetFieldID java/lang/FinalizerThread.vm_thread J = 0x8286894 > [0x4000] : GetLongField called, id = 0x8286894 > [0x4000] : IsInstanceOf called > [0x4000] : GetObjectClass called > [0x4000] : GetObjectClass: class = java/lang/FinalizerThread > [0x8003] : gc_thread_init 0x807d720 > [0x8003] : FindClass called, name = java/lang/Thread > [0x8003] : FindClass called, name = java/lang/Thread > [0x8003] : si_goto_previous from ip = (nil) (M2N) > [0x8003] : si_unwind_from_m2n, ip = (nil) > [0x8003] : si_goto_previous to ip = (nil) (M2N) > [0x8003] : StartLoading class java/lang/Thread with loader 0x8633a18 > [0x8003] : 0x8633a18 0x807d660 I java/lang/Thread > [0x8003] : Loader U (0x8633a18) loading class: java/lang/Thread... > [0x8003] : enter method java/lang/ClassLoader loadClass > (Ljava/lang/String;)Ljava/lang/Class; > > At thi
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
On Wednesday 27 September 2006 14:20 Egor Pasko wrote: > On the 0x1F1 day of Apache Harmony Xiao-Feng Li wrote: > > Thanks. Yes, this is supposed to be review by JIT person. On the other > > hand, if JIT person has better solution, GCv5 would like to use. > > Anyway we hope write barrier is to be functioning in the DRLVM soon. > > As a JIT-oriented guy, I looked through the patch. Looks good. The > write barrier does NOT push an M2N frame before invoking > gc_heap_slot_write_ref(), but it's OK since there will be no stack > unwinding from here. I want to make sure that there are going to be no JVMTI events sent inside of gc_heap_slot_write_ref. Otherwise M2N frame is necessary to allow stack iterator to work in case a JVMTI agent calls something like GetStackTrace. Also can a hardware exception occur as a result of this helper call? Just a note. Patch uses tabs and DOS EOLs. Can we use spaces and unix line endings instead? > I am curious about the switch > VM_Global_State::loader_env->use_lil_stubs. Does everything work in > both true and false? What do we need this switch for? Doesn't it > induce unnecessary complication/duplication? > > > On 9/27/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > > It would probably be best if a JIT person committed this patch. Maybe > > > Stephan Mishura? > > > > > > If its not committed soon, bug me and I will do it. > > > > > > On 9/26/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > > Hi, the patch attached in JIRA 1580 (submitted by YuNan) is a write > > > > barrier implementation for JET that GCv5 is going to use (it doesn't > > > > impact anything else). It would be great if some commiter can help to > > > > review and commit it. Thanks. -xiaofeng > > > > > > > > http://issues.apache.org/jira/browse/HARMONY-1580?page=all > > > > > > > > The patch is against revision revision 442796. > > > > > > > > Repeat the desciption of the patch: > > > > "Attached patch is an implementation of write barrier for JET > > > > compiler of DRLVM. The patch lets JET to call > > > > "gc_requires_barriers()" of GC to determine if it needs to insert the > > > > write barrier code into the jitted code, so it doesn't impact current > > > > DRLVM/GC at all. It calls gc_heap_slot_write_ref( ) of GC module, > > > > which takes three parameters. The signature is "void > > > > gc_heap_slot_write_ref (Managed_Object_Handle > > > > p_obj_holding_ref,Managed_Object_Handle *p_slot, > > > > Managed_Object_Handle p_target)". > > > > > > > > The patch is based on revision 442796. We hope it can be committed to > > > > Harmony soon because GCv5 will be depending on it. We don't use > > > > existing getaddress__gc_write_barrier_fastcall () in DRLVM because it > > > > only remembers object rather than the slot, and the name is not > > > > descriptive. But we may use it later. Thanks." -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wonka, Mika, and Apache
great interest Chris -- let's get the wheels moving. Regards, Tim Chris Gray wrote: > Hello guys, > > To introduce myself: I'm one of the original developers of the Wonka embedded > VM, and my company sells both support for Wonka and our own derivative which > we call Mika. Recently we made Mika available under the same BSD-style > licence as Wonka. > > My question is whether Apache would be interested in adopting Wonka/Mika as a > project, either within Harmony or as an embedded counterpart thereto. > Currently ownership of the code is divided between Punch Telematix, who > acquired the assets of my former employer Acunia, and my own company. Punch > have no interest in the VM beyond the fact that it is an essential component > of a product (the CarCube) which they inherited from Acunia. I believe they > would have no objection to granting rights to the AF, beyond the sheer effort > of doing so. They can probably be persuaded, but first I'd like to know if > there is sufficient interest within the AF. > > Best regards, > > Chris > -- 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: [jira] Created: (HARMONY-1609) Applet, ImageIO and Print modules
Woo hoo! Good work Alexey and team. Tim Alexey Petrenko (JIRA) wrote: > Applet, ImageIO and Print modules > - > > Key: HARMONY-1609 > URL: http://issues.apache.org/jira/browse/HARMONY-1609 > Project: Harmony > Issue Type: New Feature > Components: Classlib, Contributions > Reporter: Alexey Petrenko > Attachments: apio.zip > > This contribution consists of Applet, ImageIO and Print modules > implementation and tests. > It also adds few classes to awt and swing modules which are depends on this > modules. > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM
On 9/26/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: On 9/27/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote: > (3) > One more lock is added - hythread_lib_lock. How is that differ from > the hythread_global_lock that we already have? Each extra lock to the > system may add more possibilities for deadlocks, as well as can > negatively impact the scalability (unless some of the existing locks > are split). hythread_lib_lock acquires exactly the same lock as hythread_global_lock. Probably I miss something but we need to be compatible with IBM threading library now. This library has such function. That's why I added it. Sounds right? Well, this sort of, kind of sounds right but not quite. Its a little more subtle than being compatible with IBM threading library. The first goal is to identify the parts of IBM threading library that are JVM independent. It makes sense for DRLVM to be compatible with the independent parts. This should be a nobrainer. The parts of IBM threading library that assume a specific JVM implementation will be a problem. We will need to find a solution that is endorsed by all the stakeholders (including J9 folks). The hythread_global_lock falls into this category. For starts, I would like to see a concise description from the portlib owners on what hythread_global_lock protects, which locks have to be held before grabbing this lock, are there any restrictions on what system calls can be made while holding this lock (like sleep or wait), etc. To get a better idea what's in the patch.diff, I printed it out. Its 120+ pages. Quite a big patch! Most of it looks like straight forward JNI interface glue. There are some tricky parts. I would like to know the design review process for these parts. Using grep, I found 20 locations where ...suspend_enable... and ...suspend_disable... have been added. And 25 locations where enable/disable have been removed. Failure in this logic can lead to incorrect reference pointer enumeration. These are probably the hardest bugs to find. Please tell us who has looked at this code in depth. Are there any known design flaws in it? I also notice APIs called tmn_suspend_enable(), hythread_suspend_enable() -- are these simply different names for the same binary executible. Or different binaries that do the same thing?? -- Weldon Washburn Intel Middleware Products Division
Re: Can't unsubscribe...
done On Sep 27, 2006, at 2:05 PM, Phil Forestall wrote: Geir: I've been trying to unsub for a while too. Nothing seems to work. Would you mind unsubbing [EMAIL PROTECTED] from the Harmony and JIRA lists? It's been a trip. Many Thanks. Phil Forestall 'Never trust a computer too big to throw out of a window.' - Paul Allen From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> Reply-To: harmony-dev@incubator.apache.org To: harmony-dev@incubator.apache.org CC: [EMAIL PROTECTED] Subject: Re: Can't unsubscribe... Date: Sat, 23 Sep 2006 16:55:31 -0400 Done geir On Sep 23, 2006, at 4:52 PM, Fernando Cassia wrote: this one... [EMAIL PROTECTED] I find myself erasing messages all the time... (my 2.5gb space is at 99%).. and the ones to blame for that are the two dozen mailing lists I've subscribed to... :-) Thanks FC On 9/23/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: which address do you want to unsub? geir On Sep 23, 2006, at 4:43 PM, Fernando Cassia wrote: > Help... I need to move my mailing list subscriptions from this > email address > to another. > > I emailed the "unsubscribe" address shown at the footer of every > message, > but so far it doesn seem to have worked. > Any ideas/suggestions? (please refrain from saying "throw your > computer off > a cliff" ;-). > > Is this a "join if you wish, leave if you can" kind of mailing > list?. ;-) > > FC --- -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- "When I do good, I feel good; when I do bad, I feel bad. That's my religion." - Abraham Lincoln. "I do not believe in the immortality of the individual, and I consider ethics to be an important but exclusively human concern, without any supernatural authority behind it." - Albert Einstein. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't unsubscribe...
Geir: I've been trying to unsub for a while too. Nothing seems to work. Would you mind unsubbing [EMAIL PROTECTED] from the Harmony and JIRA lists? It's been a trip. Many Thanks. Phil Forestall 'Never trust a computer too big to throw out of a window.' - Paul Allen From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> Reply-To: harmony-dev@incubator.apache.org To: harmony-dev@incubator.apache.org CC: [EMAIL PROTECTED] Subject: Re: Can't unsubscribe... Date: Sat, 23 Sep 2006 16:55:31 -0400 Done geir On Sep 23, 2006, at 4:52 PM, Fernando Cassia wrote: this one... [EMAIL PROTECTED] I find myself erasing messages all the time... (my 2.5gb space is at 99%).. and the ones to blame for that are the two dozen mailing lists I've subscribed to... :-) Thanks FC On 9/23/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: which address do you want to unsub? geir On Sep 23, 2006, at 4:43 PM, Fernando Cassia wrote: > Help... I need to move my mailing list subscriptions from this > email address > to another. > > I emailed the "unsubscribe" address shown at the footer of every > message, > but so far it doesn seem to have worked. > Any ideas/suggestions? (please refrain from saying "throw your > computer off > a cliff" ;-). > > Is this a "join if you wish, leave if you can" kind of mailing > list?. ;-) > > FC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- "When I do good, I feel good; when I do bad, I feel bad. That's my religion." - Abraham Lincoln. "I do not believe in the immortality of the individual, and I consider ethics to be an important but exclusively human concern, without any supernatural authority behind it." - Albert Einstein. - 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][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}
gpProtectedMain() is in classlib/trunk/modules/luni/src/main/native/launcher/shared/main.c signalProtectedMain() is in classlib/trunk/modules/luni/src/main/native/launcher/shared/cmain.c Incidentally, I am noticing that portlib gets initialized with a default copy of MasterPortLibraryTable from portpriv.h. This could be causing all kinds of undefined behavior. I think shortly after hyport_create_library() is called, we should re-write the functions to point into DRLVM thread manager. Andrey Chernyshev -- what do you think? On 9/26/06, Leo Li <[EMAIL PROTECTED]> wrote: Hi, Weldon: Which file includes signalProtectMain() or gpProtectedMain ? :) On 9/25/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > It looks like hysignal.c is using the right monitor enter/exit(). That > is, > the one > from drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/hythr.dll > > However, a bunch of functions in classlib's hysignal.c have an incoming > argument of "HyPortLibrary *portlib". The portlib variable can either > point > to the original classlib portlib C struct. Or it can point to PORTLIB > which > is a C struct with all the entries nulled out (more on this later.) > > I think the next question to ask is what hysignal.c does with > the "HyPortLibrary *portlib" argument. If anyone knows, please tell us. > Otherwise I will keep digging. > > From stepping through DRLVM bootup, it looks like classlib's portlib is > _dropped_ in signalProtectMain(). Then launcher gpProtectedMain calls > invocation(PORTLIB,...) where PORTLIB is a nulled out HyPortLibrary C > struct. We need to put comments in the code describing the switch from > classlib's portlib to drlvm's nulled out version. > > On 9/22/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > > > All, > > Its not clear at this moment what threading implementation is being > > executed when hysignal.c calls hythread_monitor_enter(). If someone > > already knows, please tell us. Otherwise, I will step through it with > the > > debugger to find out what is going on. > > - Weldon > > > > -- > > Weldon Washburn > > Intel Middleware Products Division > > > > > > -- > Weldon Washburn > Intel Middleware Products Division > > -- Leo Li China Software Development Lab, IBM -- Weldon Washburn Intel Middleware Products Division
Re: [drlvm][classlib] thread library - let there be one!
+1 on the below. I am assuming Andrey and his team will do this work. (Andrey, when will you start?) Hopefully we can clean up how drlvm handles the classlib portlib function table at the same time. Currently two versions of this table are created during startup. "Portlib function table - let there be one!" Seriously, this is incredibly difficult code to maintain. On 9/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Yes, exactly. Regards, Tim Andrey Chernyshev wrote: > On 9/26/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote: >> >> > Weldon, I agree with your comments and observations below. Let's take >> > baby steps to get fully unified. I'm sure we all want to keep things >> > working throughout. >> >> So what's the first stop? Move hythread as-is out of classlib to a >> peer in the tree? > > I can suggest the following steps: > - pull out hythread from classlib, make it a shared component > - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and > upper layer (hythead_xxx) > - migrate classlib code to the bottom layer (1) of hythread > - migrate DRLVM's thread manager to (1) from APR > Each step can be done without breaking the whole code stack. > As a result, we'll have a bottom part of hythread which will be shared > between the classlib and DRLVM. > > Some additional steps could be: > - pull the rest of the portlib out of the classlib, make it a shared > component as well > - migrate DRLVM to portlib > > Thanks, > Andrey. > > >> >> geir >> >> > >> > Regards, >> > Tim >> > >> > Weldon Washburn wrote: >> >> On 9/20/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> >>> >> >>> Artem Aliev wrote: >> Gier, >> >> The hythread is just most visible example. There are also signal >> handling problem. classlib hysig lib setup signal handlers and then >> drlvm overrides them by its owns. There are code duplication in >> classlib hyprt.dll drlvm port.lib: >> classlib/trunk/modules/luni/src/main/native/port vm/port/src >> >> These three pair of components contains significant part of the >> system dependent code for both VM and CLASSLIB. I think, all this >> code naturally defines portlib component that could be shared >> between >> classlib and VMs. So, as a first step, we could move all this >> code in >> to the one place, name portlib to have three directories classlib, >> drlvm, portlib. >> >>> >> >>> I think it is quite reasonable to call out the portlib and threadlib >> >>> separate (in the repository) to the VM and classlib. As you >> >>> point out, >> >>> then VM and classlib can share the code -- though it will not >> >>> become a >> >>> requirement for VMs that run the harmony code to be using those >> >>> libraries for their own implementation. >> >> >> >> >> >> Tim, >> >> One of the things to worry about is system-wide lock protocol. We >> >> will >> >> need >> >> to think through what locks portlib, threadlib and JVM are holding >> >> and if >> >> there are any deadlock possibilities. >> >> >> >> Another issue is the implementation of signal chaining. There >> >> seems to be >> >> code in hysignal.c that implement "-Xrs". I guess the idea is that a >> >> Harmony JVM would somehow not link this code and use its own >> >> implementation. The bottom line is that we probably need to >> >> carefully pick >> >> through what is currently in classlib threads/signals and rearrange >> >> stuff so >> >> that it reduces the confusion. We need to make this part of the >> >> system >> >> much >> >> easier to work on. >> >> >> >> Do you have recommendations on next steps? Does it make sense to >> >> start >> >> moving stuff into the directories described above. Or is more >> >> discussion >> >> needed. >> >> >> >> >> >> >> >>> As the second step, the pairs of libraries should be merged and the >> classlib and drlvm refactoried to have only 3 lib instead of 6. >> >>> >> >>> Yep, this would be part of the consolidation into new Harmony top- >> >>> level >> >>> components. It makes sense that we share the same impl in the >> >>> project. >> >>> >> The 3rd step is to replace most of the functions with APR ones and >> move the rest of the code to the APR. >> >>> >> >>> I think it is quite well documented on this list that this should >> >>> not be >> >>> a goal. >> >> >> >> >> >> I agree we don't need to move classlib to APR provided that: >> >> >> >> 1) >> >> There is an easy to understand distinct seperation of the different >> >> threading/signals packages. In specific, we need to know which >> >> threading >> >> package is being called by DRLVM without ambiguity. >> >> >> >> 2) >> >> There is clear understanding of how JVM and classlib threading/ >> >> signals >> >> interoperate. >> >> >> >> >> >> Regards, >> >>> Tim >> >>> >> Thoughts? >> >> Thanks >> Artem >> >> >> >> >> >> >>
Re: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test
Ignore this build break, I was updating the dependencies at the time. Tim Apache Harmony Build wrote: > [exec] -check: > [exec] [echo] Checking for depends/jars/yoko-m1/yoko.jar > > [exec] BUILD FAILED > [exec] /home/hybld/continuum-working-directory/6/classlib/build.xml:154: > The following error occurred while executing this line: > [exec] > /home/hybld/continuum-working-directory/6/classlib/make/build-test.xml:124: > The following error occurred while executing this line: > [exec] > /home/hybld/continuum-working-directory/6/classlib/make/depends.xml:36: The > following error occurred while executing this line: > [exec] > /home/hybld/continuum-working-directory/6/classlib/make/depends.xml:202: ... > > [exec] Missing dependency. The jar from: > > [exec] > http://people.apache.org/maven-snapshot-repository/org/apache/yoko/yoko-spec-corba/1.0-incubating-M1-SNAPSHOT/yoko-spec-corba-1.0-incubating-M1-20060925.152805-4.jar > > [exec] should be downloaded to: > > [exec] depends/jars/yoko-m1/yoko.jar > > [exec] Run "ant fetch-depends" to automatically fetch dependencies. > [exec] Note: Some of Harmony's dependencies are licensed under terms > other > [exec] than the Apache License v2. > > [exec] Total time: 6 seconds > [echo] Tests.failed is set to true > [exec] Result: 1 > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] yoko updated
Yoko version has been updated. You have to 'rm depends/jars/yoko/yoko.jar' and re-run the 'ant fetch-depends' target (or else the build complains about an MD5 failure). I'll move the Yoko JARs download into version-specific directory. 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: [drlvm][jit] Internal testing framework for Jitrino.OPT compiler
Ivan, I've checked all of the tests - this is very good beginning! I see 2 directions to advance: 1) Integrate Jitrino tests into common harmony test system. So we can ask people to use our test suite. 2) Start to test not only CFG but more complex IR examples. I mean to test IR with instructions using optimizations. I want to get item 1 as TODO for myself. Could you take item 2 and write several IR templates with instructions and use these templates in tests? getNodeCountTest2 - this is a real bug. This bug does not affect any of JIT algorithms today, but anyway it must be fixed. Could you create and post the fix into JIRA? If you have questions I can help you with the fix. On 9/26/06, Ivan Kollegov <[EMAIL PROTECTED]> wrote: Hello. The documentation has helped me to write the tests. I have written 4 templates of graphs and 20 tests for methods of ControlFlowGraph. I have founded a problem with test getNodeCountTest2. If there are no nodes in graph I have follows "java.exe has encountered a problem and needs to close. We are sorry for the inconvenience." You can find all my test there http://issues.apache.org/jira/browse/HARMONY-1531 Can you check if these tests are OK? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mikhail Fursov
Re: [testing] HARMONY-995: adding new target to builds for automatic testing
On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: How will you be able to grab that information from the logs, so I can see histories and such? I'm not going to go manually scanning logs. I want a web page that shows me the history. This is what the CI system does right now. Why would we want to reverse that? I want to be able to graph the times to look for aberrations I guess you can write log-scanning code, but that seems to be longer than the 19 extra lines that would be in the script for cruise control... OK. At least now I see a difference. You think about web-interface primary but I about notification interface. In both cases to define the reason of failure you should scanning logs but to see the 'current state' web interface more convenient. At nearest time I will experiment with both systems to define the best one and share results. thanks, Vladimir geir > > thanks, Vladimir > > Maybe I'm misunderstanding your motivation? >> >> Having that target in classlib is fine. But I can't see why we'd >> ever want to use it in the context that we are discussing it >> >> geir >> >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> >> - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] jre and hdk snapshots posted to general snapshot site
If we plan to use HDK for supporting developers who work on single module (that is a good idea IMHO) then we definitely need to supply jar with tests. We may also supply the build file with placeholders for user classes & tests dirs that will be prepended to classpath/bootclasspath. Regards, 2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>: On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > If I recall, the point of the test.jar was to have a pre-built jar of > tests in the HDK so that someone could setup the build-test infra > using the HDK so they could run tests on their platform w/o having to > build everything. Good idea. Yes, you are correct. This idea implemented in the jira 964. If that's so, then something would > have to be configured to have the classlib "test" target use that > jar. All I'm saying is that how we do this is important, as we don't > want to cause pain for classlib developers who use the HDK for > development support. Seems, we think about different use cases. In my case, user can download the HDK for own platform (if we have one) run tests and look on results (also, may be upload it to the harmony site). Also it can be used for application run to check 'enable' status. But if this user interested in Harmony development he should checkout ws and use built-in ant targets to build and test updated ws. How you plan to use HDK? It looks like initial miscommunication :) thanks, Vladimir > geir > > > > > Thanks, Vladimir > > > > > > > > > > > >> > Thanks, Vladimir > >> > > >> > geir > >> >> > >> >> > > >> >> > > >> >> > > >> >> > Thanks, Vladimir > >> >> > > >> >> > > >> >> > > >> >> > On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > >> >> >> > >> >> >> They are at the regular place > >> >> >> > >> >> >> http://people.apache.org/dist/incubator/harmony/snapshots > >> >> >> > >> >> >> I moved all the old classlib snapshots into /old and I'll > >> >> update the > >> >> >> website accordingly. I'll be automating this. Also, lets not > >> >> >> make much > >> >> >> noise about this for a little while so we can test to make sure > >> >> >> there's > >> >> >> no major errors. Things seem good. I have a list of more > >> >> things to > >> >> >> fix, but I realized today that I was obsessing over the > >> snapshot > >> >> >> contents - it's not a release, and it's "good enough". > >> >> >> > >> >> >> I'd like to ditch both /old and the remaining classlib > >> >> snapshots, as > >> >> >> > >> >> >> 1) they are snapshots - history doesn't matter > >> >> >> > >> >> >> 2) the classlib is now in the HDK, so we just need to adjust > >> the > >> >> >> docs to > >> >> >> match. > >> >> >> > >> >> >> I'll do the latter, but wanted to see if anyone has a problem > >> >> w/ me > >> >> >> removing /old and the last classlib snapshot. I'll do this > >> if I > >> >> >> don't > >> >> >> hear any protest, so either positively acknowledge this action > >> >> if you > >> >> >> support it, dont' do a thing if you support or dont' care, > >> or say > >> >> >> why we > >> >> >> shouldn't :) > >> >> >> > >> >> >> geir > >> >> >> > >> >> >> > >> >> > >> - > >> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> >> >> To unsubscribe, e-mail: harmony-dev- > >> >> [EMAIL PROTECTED] > >> >> >> For additional commands, e-mail: harmony-dev- > >> >> >> [EMAIL PROTECTED] > >> >> >> > >> >> >> > >> >> > >> >> > >> >> > >> - > >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> >> To unsubscribe, e-mail: harmony-dev- > >> [EMAIL PROTECTED] > >> >> For additional commands, e-mail: harmony-dev- > >> >> [EMAIL PROTECTED] > >> >> > >> >> > >> > >> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: harmony-dev- > >> [EMAIL PROTECTED] > >> > >> > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- 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][apr] APR fails to load a JIT library when using a fully qualified path
On 9/27/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: If anyone is interested to discuss the details or have something to add I propose to use this thread and the same JIRA. I was wrong when proposed to use this email thread for the discussion. The subject is not suitable at all. I will start new thread. -- Mikhail Fursov
[classlib][awt] Non bug??? RI AffineTransform.transform(...) throws ArrayIndexOutOfBoundsException while Harmony doesn't
Hi all
RI implementation of AffineTransform of transform(float[], int,
float[], int, int) and transform(double[], int, double[], int, int)
methods throws ArrayIndexOutOfBoundsException if offset is out of
bounds and number of points to transform is zero. Harmony doesn't
throw any exception. Spec doesn't say about any exceptions.
RI use System.arraycopy(...) (see track trace) which throws this
exception. But Harmony doesn't use System.arraycopy(...) so we have
difference in behavior.
I see two possibilities
1. Stay as non-bug. If number of points is zero then logically we have
to do nothing w/o exceptions.
2. Follow RI. In this case we have to add checks like this
if (srcOff > src.length || dstOff > dst.length) {
throw new ArrayIndexOutOfBoundsException(...);
}
it looks a bit strange from my point of view.
I vote for non-bug.
Comments?
2006/9/27, Denis Kishenko (JIRA) <[EMAIL PROTECTED]>:
[classlib][awt] RI AffineTransform.transform(...) throws
ArrayIndexOutOfBoundsException while Harmony doesn't
-
Key: HARMONY-1606
URL: http://issues.apache.org/jira/browse/HARMONY-1606
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Denis Kishenko
RI implementation of AffineTransform of transform(float[], int, float[], int,
int) and transform(double[], int, double[], int, int) methods throws
ArrayIndexOutOfBoundsException if offsets are out of buffer bounds and number
of points to transform is zero. Harmony doesn't throw any exception. Spec
doesn't say about any exceptions.
As you see from stack trace RI call System.arraycopy(...) which throws
exception because of offset is really out of bounds. But Harmony implementation
doesn't use System.arraycopy(...) so we have difference in behavior.
=== Test.java ===
import java.awt.geom.AffineTransform;
public class Test {
static public void main(String[] args) {
AffineTransform t = new AffineTransform();
try {
t.transform(new float[] {}, 1, new float[] {}, 2, 0);
} catch (Exception e) {
e.printStackTrace();
}
try {
t.transform(new double[] {}, 1, new double[] {}, 2, 0);
} catch (Exception e) {
e.printStackTrace();
}
}
}
= RI ===
java.lang.ArrayIndexOutOfBoundsException
at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown
Source)
at java.awt.geom.AffineTransform.transform(AffineTransform.java:2308)
at Test.main(Test.java:10)
java.lang.ArrayIndexOutOfBoundsException
at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown
Source)
at java.awt.geom.AffineTransform.transform(AffineTransform.java:2421)
at Test.main(Test.java:15)
Harmony ===
nothing
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Denis M. Kishenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][apr] APR fails to load a JIT library when using a fully qualified path
I put the initial version of MSVC2003 build into JIRA [ http://issues.apache.org/jira/browse/HARMONY-1607 ] This version contains only Jitrino/EM/Encoder projects and I'm going to add more modules soon. If anyone is interested to discuss the details or have something to add I propose to use this thread and the same JIRA. On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Sep 26, 2006, at 1:29 PM, Tim Ellison wrote: > "the various cruft we have around for Eclipse" > > 'Cruft' doesn't seem to appear in my copy of the Oxford English > Dictionary. I assume it means 'high fidelity development environment > artifacts' right? :o) Exactly. "Cruft" :) > > I'm ok with putting in some VS metadata too. > > Regards, > Tim > > > Geir Magnusson Jr. wrote: >> Just so we're all on the same page... >> >> This is understood to be like the various cruft we have around for >> Eclipse - nice to have for developers but not a supported way to >> build >> the project? >> >> geir >> >> >> On Sep 25, 2006, at 2:14 PM, Gregory Shimansky wrote: >> >>> On Monday 25 September 2006 19:24 Mikhail Fursov wrote: I spent a couple of hours today investigating this bug. The result is: this is not a bug, this is the problem of the MSVC project file I use to build and to debug JIT. So it was my error. BTW: if anyone is interested to use MSVC project files to build JIT or other components of DRLVM I can put them into JIRA and support these files in the nearest future. >>> >>> I think this would be very useful for development on windows. I >>> don't use >>> VS.NET for anything but debugging but then project is useful to >>> find some >>> symbol's definition/declaration and helps the debugger to >>> understand the >>> symbol info. >>> >>> +1. >>> >>> --Gregory Shimansky, Intel Middleware Products Division >>> >>> >>> - >>> Terms of use : http://incubator.apache.org/harmony/mailing.html >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: harmony-dev- >>> [EMAIL PROTECTED] >>> >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> >> > > -- > > 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] -- Mikhail Fursov
Re: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run
I should guess 2006/9/27, Geir Magnusson Jr. <[EMAIL PROTECTED]>: I have a tattoo. geir On Sep 27, 2006, at 8:52 AM, Denis Kishenko wrote: > do you wear such one =) > > 2006/9/27, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> you can wear it too if you want. either share with Vladimir, or make >> your own copy :) >> >> On Sep 27, 2006, at 8:39 AM, Denis Kishenko wrote: >> >> > Vladimir, my congratulations! >> > >> > 2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>: >> >> Thanks :) >> >> >> >> On 9/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> >> > >> >> > Here's a badge for you to cut out and wear >> >> > >> >> > +-+ >> >> > | Harmony | >> >> > | Champion! | >> >> > +-+ >> >> > >> >> > Keep up the good work! >> >> > >> >> > Regards, >> >> > Tim >> >> > >> >> > Vladimir Ivanov wrote: >> >> > > It is my 200 issue in Harmony. Seems, I'm the champion :) >> >> > > >> >> > > -- Forwarded message -- >> >> > > From: Vladimir Ivanov (JIRA) <[EMAIL PROTECTED]> >> >> > > Date: Sep 25, 2006 7:50 PM >> >> > > Subject: [jira] Created: (HARMONY-1569) [drlvm][testing] >> >> JAVA_HOME >> >> > veriable >> >> > > should be set to tested runtime before test run >> >> > > To: [EMAIL PROTECTED] >> >> > > >> >> > > [drlvm][testing] JAVA_HOME veriable should be set to tested >> >> runtime >> >> > before >> >> > > test run >> >> > > >> >> > >> >> >> - >> >> -- >> >> > > >> >> > > >> >> > >Key: HARMONY-1569 >> >> > >URL: http://issues.apache.org/jira/browse/ >> >> HARMONY-1569 >> >> > >Project: Harmony >> >> > > Issue Type: Improvement >> >> > > Components: DRLVM >> >> > > Reporter: Vladimir Ivanov >> >> > > >> >> > > >> >> > > Now, the system JAVA_HOME variable is used. The value should >> >> point to >> >> > > tested >> >> > > runtime. >> >> > > >> >> > > -- >> >> > > 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 >> >> > > >> >> > >> >> > -- >> >> > >> >> > Tim Ellison ([EMAIL PROTECTED]) >> >> > IBM Java technology centre, UK. >> >> > >> >> > >> >> >> - >> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> > To unsubscribe, e-mail: harmony-dev- >> >> [EMAIL PROTECTED] >> >> > For additional commands, e-mail: harmony-dev- >> >> [EMAIL PROTECTED] >> >> > >> >> > >> >> >> >> >> > >> > >> > -- >> > Denis M. Kishenko >> > Intel Middleware Products Division >> > >> > >> - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> > For additional commands, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> > >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> >> > > > -- > Denis M. Kishenko > Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Denis M. Kishenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1505) [build?] Some of the Harmony jni libraries has wrong function names inside
Investigation shown another problem... Number of JNI methods in archive and luni modules does not marked with JNIEXPORT as it required by the spec. This issue should be also fixed. I'll split the original (1505) issue on two subtasks. To make patches smaller. SY, Alexey 2006/9/27, Alexey Petrenko <[EMAIL PROTECTED]>: MS VC documentation recommends to use "__declspec(dllexport)" option instead of EXPORTS section. In our case it is JNIEXPORT. And all of the JNI functions are marked as JNIEXPORT. 2006/9/27, Mark Hindess <[EMAIL PROTECTED]>: > > On 27 September 2006 at 15:18, "Alexey Petrenko" <[EMAIL PROTECTED]> wrote: > > So... If there is now EXPORTS section advocates I will prepare a patch > > to remove them from the def files for Windows. > > If removing them means we are exporting all symbols, then I'd rather > keep explicit exports of the symbols we intend to be public. > > Is there no way to fix it and keep the explicit list of "public" > symbols? > > -Mark. > > > SY, Alexey > > > > 2006/9/26, Alexey Petrenko <[EMAIL PROTECTED]>: > > > Guys, > > > > > > investigation shown that if we remove EXPORTS section from the def > > > file then the result dll has correct names. > > > > > > Is there any objections on removing EXPORTS sections from the def > > > files on Windows? > > > > > > SY, Alexey > > > > > > 2006/9/20, Alexey Petrenko (JIRA) <[EMAIL PROTECTED]>: > > > > [build?] Some of the Harmony jni libraries has wrong function names insid > > e > > > > - > > - > > > > > > > > Key: HARMONY-1505 > > > > URL: http://issues.apache.org/jira/browse/HARMONY-1505 > > > > Project: Harmony > > > > Issue Type: Bug > > > > Components: Classlib > > > > Environment: Windows > > > >Reporter: Alexey Petrenko > > > > > > > > > > > > Some of the Harmony jni libraries, for example hyluni.dll, has function n > > ames which are not prefixed by underscore ( _ ). > > > > > > > > JNI spec says that all the JNI methods on Windows should be declared as _ > > _stdcall. [1] And MS C documentation says that __stdcall function names shoul > > d be prefixed by underscore. [2] > > > > > > > > [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp615 > > > > [2] http://msdn2.microsoft.com/en-us/library/zxk0tw93.aspx > > > > > > > > -- > > > > 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 > > > > > > > > > > > > > > > > > > > > > -- > > > Alexey A. Petrenko > > > Intel Middleware Products Division > > > > > > > > > -- > > 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 -- 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: [testing] HARMONY-995: adding new target to builds for automatic testing
On Sep 27, 2006, at 9:11 AM, Vladimir Ivanov wrote: On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Can I ask what you are trying to do? The build-test thingy wont' get simpler because of this patch, because we want the build-test tool to record it's actions in fine detail, and the only way to do that is to do the actions individually. Therefore, calling some do-everything target is a non-starter as lots of important information will be lost, with the only gain I can see is saving 19 lines of code that we'd write once and everyone would use. it just hides information for no gain. Sorry, I can not see any place where we hide information. Build logs will be available with the same details. Strictly speaking, nothing will change (except script simplification) - just some legal build sequence will be moved from external tool to the build system. How will you be able to grab that information from the logs, so I can see histories and such? I'm not going to go manually scanning logs. I want a web page that shows me the history. This is what the CI system does right now. Why would we want to reverse that? I want to be able to graph the times to look for aberrations I guess you can write log-scanning code, but that seems to be longer than the 19 extra lines that would be in the script for cruise control... geir thanks, Vladimir Maybe I'm misunderstanding your motivation? Having that target in classlib is fine. But I can't see why we'd ever want to use it in the context that we are discussing it geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - 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] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run
I have a tattoo. geir On Sep 27, 2006, at 8:52 AM, Denis Kishenko wrote: do you wear such one =) 2006/9/27, Geir Magnusson Jr. <[EMAIL PROTECTED]>: you can wear it too if you want. either share with Vladimir, or make your own copy :) On Sep 27, 2006, at 8:39 AM, Denis Kishenko wrote: > Vladimir, my congratulations! > > 2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>: >> Thanks :) >> >> On 9/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> > >> > Here's a badge for you to cut out and wear >> > >> > +-+ >> > | Harmony | >> > | Champion! | >> > +-+ >> > >> > Keep up the good work! >> > >> > Regards, >> > Tim >> > >> > Vladimir Ivanov wrote: >> > > It is my 200 issue in Harmony. Seems, I'm the champion :) >> > > >> > > -- Forwarded message -- >> > > From: Vladimir Ivanov (JIRA) <[EMAIL PROTECTED]> >> > > Date: Sep 25, 2006 7:50 PM >> > > Subject: [jira] Created: (HARMONY-1569) [drlvm][testing] >> JAVA_HOME >> > veriable >> > > should be set to tested runtime before test run >> > > To: [EMAIL PROTECTED] >> > > >> > > [drlvm][testing] JAVA_HOME veriable should be set to tested >> runtime >> > before >> > > test run >> > > >> > >> - >> -- >> > > >> > > >> > >Key: HARMONY-1569 >> > >URL: http://issues.apache.org/jira/browse/ >> HARMONY-1569 >> > >Project: Harmony >> > > Issue Type: Improvement >> > > Components: DRLVM >> > > Reporter: Vladimir Ivanov >> > > >> > > >> > > Now, the system JAVA_HOME variable is used. The value should >> point to >> > > tested >> > > runtime. >> > > >> > > -- >> > > 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 >> > > >> > >> > -- >> > >> > Tim Ellison ([EMAIL PROTECTED]) >> > IBM Java technology centre, UK. >> > >> > >> - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> > For additional commands, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> > >> > >> >> > > > -- > Denis M. Kishenko > Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] > For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Denis M. Kishenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] jre and hdk snapshots posted to general snapshot site
On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: If I recall, the point of the test.jar was to have a pre-built jar of tests in the HDK so that someone could setup the build-test infra using the HDK so they could run tests on their platform w/o having to build everything. Good idea. Yes, you are correct. This idea implemented in the jira 964. If that's so, then something would have to be configured to have the classlib "test" target use that jar. All I'm saying is that how we do this is important, as we don't want to cause pain for classlib developers who use the HDK for development support. Seems, we think about different use cases. In my case, user can download the HDK for own platform (if we have one) run tests and look on results (also, may be upload it to the harmony site). Also it can be used for application run to check 'enable' status. But if this user interested in Harmony development he should checkout ws and use built-in ant targets to build and test updated ws. How you plan to use HDK? It looks like initial miscommunication :) thanks, Vladimir geir > > Thanks, Vladimir > > > > > >> > Thanks, Vladimir >> > >> > geir >> >> >> >> > >> >> > >> >> > >> >> > Thanks, Vladimir >> >> > >> >> > >> >> > >> >> > On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> They are at the regular place >> >> >> >> >> >> http://people.apache.org/dist/incubator/harmony/snapshots >> >> >> >> >> >> I moved all the old classlib snapshots into /old and I'll >> >> update the >> >> >> website accordingly. I'll be automating this. Also, lets not >> >> >> make much >> >> >> noise about this for a little while so we can test to make sure >> >> >> there's >> >> >> no major errors. Things seem good. I have a list of more >> >> things to >> >> >> fix, but I realized today that I was obsessing over the >> snapshot >> >> >> contents - it's not a release, and it's "good enough". >> >> >> >> >> >> I'd like to ditch both /old and the remaining classlib >> >> snapshots, as >> >> >> >> >> >> 1) they are snapshots - history doesn't matter >> >> >> >> >> >> 2) the classlib is now in the HDK, so we just need to adjust >> the >> >> >> docs to >> >> >> match. >> >> >> >> >> >> I'll do the latter, but wanted to see if anyone has a problem >> >> w/ me >> >> >> removing /old and the last classlib snapshot. I'll do this >> if I >> >> >> don't >> >> >> hear any protest, so either positively acknowledge this action >> >> if you >> >> >> support it, dont' do a thing if you support or dont' care, >> or say >> >> >> why we >> >> >> shouldn't :) >> >> >> >> >> >> geir >> >> >> >> >> >> >> >> >> - >> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> >> To unsubscribe, e-mail: harmony-dev- >> >> [EMAIL PROTECTED] >> >> >> For additional commands, e-mail: harmony-dev- >> >> >> [EMAIL PROTECTED] >> >> >> >> >> >> >> >> >> >> >> >> >> - >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> To unsubscribe, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> >> For additional commands, e-mail: harmony-dev- >> >> [EMAIL PROTECTED] >> >> >> >> >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> >> - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testing] HARMONY-995: adding new target to builds for automatic testing
On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Sep 27, 2006, at 8:14 AM, Vladimir Ivanov wrote: > On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > But you can send just one email with a summary of everything that >> happened during that run. >> >> The fact that the system did : >> >>call fetch-depends >>call build clean >>call build >>call test >> >> should have no bearing on how many emails it sends. > > > > Agree. But instead of one line of code in the build we have 20+ in > the tool > (and 3 in my bat-file to do full testing cycle for classlib). Of > cause, tool > can do it (and do now) but we can do some things more easy. Can I ask what you are trying to do? The build-test thingy wont' get simpler because of this patch, because we want the build-test tool to record it's actions in fine detail, and the only way to do that is to do the actions individually. Therefore, calling some do-everything target is a non-starter as lots of important information will be lost, with the only gain I can see is saving 19 lines of code that we'd write once and everyone would use. it just hides information for no gain. Sorry, I can not see any place where we hide information. Build logs will be available with the same details. Strictly speaking, nothing will change (except script simplification) - just some legal build sequence will be moved from external tool to the build system. thanks, Vladimir Maybe I'm misunderstanding your motivation? Having that target in classlib is fine. But I can't see why we'd ever want to use it in the context that we are discussing it geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM
Geir Magnusson Jr. wrote: > What's left in classlib-land? No outstanding issues that would prevent a new snapshot. 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: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run
do you wear such one =) 2006/9/27, Geir Magnusson Jr. <[EMAIL PROTECTED]>: you can wear it too if you want. either share with Vladimir, or make your own copy :) On Sep 27, 2006, at 8:39 AM, Denis Kishenko wrote: > Vladimir, my congratulations! > > 2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>: >> Thanks :) >> >> On 9/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> > >> > Here's a badge for you to cut out and wear >> > >> > +-+ >> > | Harmony | >> > | Champion! | >> > +-+ >> > >> > Keep up the good work! >> > >> > Regards, >> > Tim >> > >> > Vladimir Ivanov wrote: >> > > It is my 200 issue in Harmony. Seems, I'm the champion :) >> > > >> > > -- Forwarded message -- >> > > From: Vladimir Ivanov (JIRA) <[EMAIL PROTECTED]> >> > > Date: Sep 25, 2006 7:50 PM >> > > Subject: [jira] Created: (HARMONY-1569) [drlvm][testing] >> JAVA_HOME >> > veriable >> > > should be set to tested runtime before test run >> > > To: [EMAIL PROTECTED] >> > > >> > > [drlvm][testing] JAVA_HOME veriable should be set to tested >> runtime >> > before >> > > test run >> > > >> > >> - >> -- >> > > >> > > >> > >Key: HARMONY-1569 >> > >URL: http://issues.apache.org/jira/browse/ >> HARMONY-1569 >> > >Project: Harmony >> > > Issue Type: Improvement >> > > Components: DRLVM >> > > Reporter: Vladimir Ivanov >> > > >> > > >> > > Now, the system JAVA_HOME variable is used. The value should >> point to >> > > tested >> > > runtime. >> > > >> > > -- >> > > 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 >> > > >> > >> > -- >> > >> > Tim Ellison ([EMAIL PROTECTED]) >> > IBM Java technology centre, UK. >> > >> > >> - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> > For additional commands, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> > >> > >> >> > > > -- > Denis M. Kishenko > Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Denis M. Kishenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wonka, Mika, and Apache
There certainly is interest in Apache Harmony, as this is very much aligned to what we've already been doing for the past year and a few months. geir On Sep 27, 2006, at 5:09 AM, Chris Gray wrote: Hello guys, To introduce myself: I'm one of the original developers of the Wonka embedded VM, and my company sells both support for Wonka and our own derivative which we call Mika. Recently we made Mika available under the same BSD-style licence as Wonka. My question is whether Apache would be interested in adopting Wonka/ Mika as a project, either within Harmony or as an embedded counterpart thereto. Currently ownership of the code is divided between Punch Telematix, who acquired the assets of my former employer Acunia, and my own company. Punch have no interest in the VM beyond the fact that it is an essential component of a product (the CarCube) which they inherited from Acunia. I believe they would have no objection to granting rights to the AF, beyond the sheer effort of doing so. They can probably be persuaded, but first I'd like to know if there is sufficient interest within the AF. Best regards, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] new "Getting Started" guides
Hi Geir, Those new documents look really good. I just found a few spelling mistakes on the first one (http://incubator.apache.org/harmony/quickhelp_users.html). In the first paragraph "no development tools our need to" should probably be "no development tools or need to". In the fourth paragraph "run well on the paltforms offered" should be "run well on the platforms offered" and in the fifth paragraph I think "unpack inÄto a jre directory" should be "unpack into a jre directory". I hope you don't think I'm being picky - I just think it's better for the project's image if we have correct spelling and grammar etc on the website. Thanks, Sian On 22/09/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: As discussed earlier today, there are now two new "Getting Started" guides on the website, accessible from the homepage. http://incubator.apache.org/harmony/quickhelp_users.html http://incubator.apache.org/harmony/quickhelp_contributors.html There is still more work to do - for example, we need to fill in the lists of tools needed and dependencies. (I'll add a fresh Ubuntu VM in Parallels tomorrow and work though all the deps that need to be added) Give a read, test it out, and comment... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sian January IBM Java Technology Centre, UK
Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
I just wondered what changed after yesterday, rolled back HARMONY-1559 patch and so discovered cause-effect relation. I can say nothing about the fix, we should ask the patch submitter :( On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: :) Is there an easy fix, or do we rollback? geir On Sep 27, 2006, at 8:32 AM, Elena Semukhina wrote: > Hi all, > > after HARMONY-1559 patch has been committed, kernel unit test > RuntimeTest > started to fail on linux in the interpreter mode. > It loops with the message > >[junit] SIGABRT in VM code. >[junit] java: > /nfs/ins/proj/drl/coreapi/esemukhi/git/drlvm/trunk/vm/port/src/lil/ > ia32/pim/stack_iterator_ia32.cpp:211: > StackIterator* si_create_from_native(): Assertion `! > interpreter_enabled()' > failed. > > and fails on timeout. > I rolled back the changes and test passed. > > -- > Thanks, > Elena -- Thanks, Elena
Re: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run
you can wear it too if you want. either share with Vladimir, or make your own copy :) On Sep 27, 2006, at 8:39 AM, Denis Kishenko wrote: Vladimir, my congratulations! 2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>: Thanks :) On 9/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > Here's a badge for you to cut out and wear > > +-+ > | Harmony | > | Champion! | > +-+ > > Keep up the good work! > > Regards, > Tim > > Vladimir Ivanov wrote: > > It is my 200 issue in Harmony. Seems, I'm the champion :) > > > > -- Forwarded message -- > > From: Vladimir Ivanov (JIRA) <[EMAIL PROTECTED]> > > Date: Sep 25, 2006 7:50 PM > > Subject: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME > veriable > > should be set to tested runtime before test run > > To: [EMAIL PROTECTED] > > > > [drlvm][testing] JAVA_HOME veriable should be set to tested runtime > before > > test run > > > - -- > > > > > >Key: HARMONY-1569 > >URL: http://issues.apache.org/jira/browse/ HARMONY-1569 > >Project: Harmony > > Issue Type: Improvement > > Components: DRLVM > > Reporter: Vladimir Ivanov > > > > > > Now, the system JAVA_HOME variable is used. The value should point to > > tested > > runtime. > > > > -- > > 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 > > > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] > For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] > > -- Denis M. Kishenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testing] HARMONY-995: adding new target to builds for automatic testing
On Sep 27, 2006, at 8:14 AM, Vladimir Ivanov wrote: On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: But you can send just one email with a summary of everything that happened during that run. The fact that the system did : call fetch-depends call build clean call build call test should have no bearing on how many emails it sends. Agree. But instead of one line of code in the build we have 20+ in the tool (and 3 in my bat-file to do full testing cycle for classlib). Of cause, tool can do it (and do now) but we can do some things more easy. Can I ask what you are trying to do? The build-test thingy wont' get simpler because of this patch, because we want the build-test tool to record it's actions in fine detail, and the only way to do that is to do the actions individually. Therefore, calling some do-everything target is a non-starter as lots of important information will be lost, with the only gain I can see is saving 19 lines of code that we'd write once and everyone would use. it just hides information for no gain. Maybe I'm misunderstanding your motivation? Having that target in classlib is fine. But I can't see why we'd ever want to use it in the context that we are discussing it geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run
Vladimir, my congratulations! 2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>: Thanks :) On 9/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > Here's a badge for you to cut out and wear > > +-+ > | Harmony | > | Champion! | > +-+ > > Keep up the good work! > > Regards, > Tim > > Vladimir Ivanov wrote: > > It is my 200 issue in Harmony. Seems, I'm the champion :) > > > > -- Forwarded message -- > > From: Vladimir Ivanov (JIRA) <[EMAIL PROTECTED]> > > Date: Sep 25, 2006 7:50 PM > > Subject: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME > veriable > > should be set to tested runtime before test run > > To: [EMAIL PROTECTED] > > > > [drlvm][testing] JAVA_HOME veriable should be set to tested runtime > before > > test run > > > --- > > > > > >Key: HARMONY-1569 > >URL: http://issues.apache.org/jira/browse/HARMONY-1569 > >Project: Harmony > > Issue Type: Improvement > > Components: DRLVM > > Reporter: Vladimir Ivanov > > > > > > Now, the system JAVA_HOME variable is used. The value should point to > > tested > > runtime. > > > > -- > > 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 > > > > -- > > 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] > > -- Denis M. Kishenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
:) Is there an easy fix, or do we rollback? geir On Sep 27, 2006, at 8:32 AM, Elena Semukhina wrote: Hi all, after HARMONY-1559 patch has been committed, kernel unit test RuntimeTest started to fail on linux in the interpreter mode. It loops with the message [junit] SIGABRT in VM code. [junit] java: /nfs/ins/proj/drl/coreapi/esemukhi/git/drlvm/trunk/vm/port/src/lil/ ia32/pim/stack_iterator_ia32.cpp:211: StackIterator* si_create_from_native(): Assertion `! interpreter_enabled()' failed. and fails on timeout. I rolled back the changes and test passed. -- Thanks, Elena - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] jre and hdk snapshots posted to general snapshot site
On Sep 27, 2006, at 8:21 AM, Vladimir Ivanov wrote: On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > If some doubts exist we can vote about it. LOL. No reason to vote - it's a technical issue with a single true'false answer - would having a single jar of tests screw up a developer using the HDK as originally intended, namely as a means to allow them to just checking one classlib module, and use HDK to supply the rest of the required headers, libraries and classes needed for building and testing. if the answer is "yes", then we need to figure out how to deal with it. If "no", then there's no problem and we go forward. The question here isn't "do we want the test.jar" - because I think we all do. The question is "how do we do this conveniently and safely?" > > I can not see any downside to have one more jar in the HDK. The problem could arise if that test.jar was used before the classes in the checked-out module, masking any changes or such that the developer was making. So, conclusion is: - while we does not provide scripts to run tests from this test.jar we have no problems here;\ - when we will prepare scripts we should add tests from modules before this test.jar (or prepare 2 separated scripts). Do I miss something? One of us is. If I recall, the point of the test.jar was to have a pre-built jar of tests in the HDK so that someone could setup the build-test infra using the HDK so they could run tests on their platform w/o having to build everything. Good idea. If that's so, then something would have to be configured to have the classlib "test" target use that jar. All I'm saying is that how we do this is important, as we don't want to cause pain for classlib developers who use the HDK for development support. geir Thanks, Vladimir > Thanks, Vladimir > > geir >> >> > >> > >> > >> > Thanks, Vladimir >> > >> > >> > >> > On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> >> >> >> They are at the regular place >> >> >> >> http://people.apache.org/dist/incubator/harmony/snapshots >> >> >> >> I moved all the old classlib snapshots into /old and I'll >> update the >> >> website accordingly. I'll be automating this. Also, lets not >> >> make much >> >> noise about this for a little while so we can test to make sure >> >> there's >> >> no major errors. Things seem good. I have a list of more >> things to >> >> fix, but I realized today that I was obsessing over the snapshot >> >> contents - it's not a release, and it's "good enough". >> >> >> >> I'd like to ditch both /old and the remaining classlib >> snapshots, as >> >> >> >> 1) they are snapshots - history doesn't matter >> >> >> >> 2) the classlib is now in the HDK, so we just need to adjust the >> >> docs to >> >> match. >> >> >> >> I'll do the latter, but wanted to see if anyone has a problem >> w/ me >> >> removing /old and the last classlib snapshot. I'll do this if I >> >> don't >> >> hear any protest, so either positively acknowledge this action >> if you >> >> support it, dont' do a thing if you support or dont' care, or say >> >> why we >> >> shouldn't :) >> >> >> >> geir >> >> >> >> >> - >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> To unsubscribe, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> >> For additional commands, e-mail: harmony-dev- >> >> [EMAIL PROTECTED] >> >> >> >> >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] >> For additional commands, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> >> - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] HARMONY-1559 patch causes SIGABRT in VM code
Hi all, after HARMONY-1559 patch has been committed, kernel unit test RuntimeTest started to fail on linux in the interpreter mode. It loops with the message [junit] SIGABRT in VM code. [junit] java: /nfs/ins/proj/drl/coreapi/esemukhi/git/drlvm/trunk/vm/port/src/lil/ia32/pim/stack_iterator_ia32.cpp:211: StackIterator* si_create_from_native(): Assertion `!interpreter_enabled()' failed. and fails on timeout. I rolled back the changes and test passed. -- Thanks, Elena
Re: [general] jre and hdk snapshots posted to general snapshot site
On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > If some doubts exist we can vote about it. LOL. No reason to vote - it's a technical issue with a single true'false answer - would having a single jar of tests screw up a developer using the HDK as originally intended, namely as a means to allow them to just checking one classlib module, and use HDK to supply the rest of the required headers, libraries and classes needed for building and testing. if the answer is "yes", then we need to figure out how to deal with it. If "no", then there's no problem and we go forward. The question here isn't "do we want the test.jar" - because I think we all do. The question is "how do we do this conveniently and safely?" > > I can not see any downside to have one more jar in the HDK. The problem could arise if that test.jar was used before the classes in the checked-out module, masking any changes or such that the developer was making. So, conclusion is: - while we does not provide scripts to run tests from this test.jar we have no problems here;\ - when we will prepare scripts we should add tests from modules before this test.jar (or prepare 2 separated scripts). Do I miss something? Thanks, Vladimir > Thanks, Vladimir > > geir >> >> > >> > >> > >> > Thanks, Vladimir >> > >> > >> > >> > On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> >> >> >> They are at the regular place >> >> >> >> http://people.apache.org/dist/incubator/harmony/snapshots >> >> >> >> I moved all the old classlib snapshots into /old and I'll >> update the >> >> website accordingly. I'll be automating this. Also, lets not >> >> make much >> >> noise about this for a little while so we can test to make sure >> >> there's >> >> no major errors. Things seem good. I have a list of more >> things to >> >> fix, but I realized today that I was obsessing over the snapshot >> >> contents - it's not a release, and it's "good enough". >> >> >> >> I'd like to ditch both /old and the remaining classlib >> snapshots, as >> >> >> >> 1) they are snapshots - history doesn't matter >> >> >> >> 2) the classlib is now in the HDK, so we just need to adjust the >> >> docs to >> >> match. >> >> >> >> I'll do the latter, but wanted to see if anyone has a problem >> w/ me >> >> removing /old and the last classlib snapshot. I'll do this if I >> >> don't >> >> hear any protest, so either positively acknowledge this action >> if you >> >> support it, dont' do a thing if you support or dont' care, or say >> >> why we >> >> shouldn't :) >> >> >> >> geir >> >> >> >> >> - >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> To unsubscribe, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> >> For additional commands, e-mail: harmony-dev- >> >> [EMAIL PROTECTED] >> >> >> >> >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> >> - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testing] HARMONY-995: adding new target to builds for automatic testing
On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: We seem to be having a bit of a communication issue. No, he wouldn't miss it, because the system would send mail in that case. The system would send mail in case of failure for every case, and only success for the tests, as you seemed to be asking. Actually, my configuration wouldn't send mail for anything except "transition" - first failure, and then first recovery... I know. I just do small update for yor system :) But you can send just one email with a summary of everything that happened during that run. The fact that the system did : call fetch-depends call build clean call build call test should have no bearing on how many emails it sends. Agree. But instead of one line of code in the build we have 20+ in the tool (and 3 in my bat-file to do full testing cycle for classlib). Of cause, tool can do it (and do now) but we can do some things more easy. thanks, Vladimir geir
Re: [general] jre and hdk snapshots posted to general snapshot site
On Sep 27, 2006, at 7:58 AM, Vladimir Ivanov wrote: On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Sep 27, 2006, at 3:10 AM, Vladimir Ivanov wrote: > Some times ago we discussed (and agreed?) that the HDK should > include tests > (also as support.jar which already included) and issue 984 was > filed to > build test.jar. > > It will nice if test.jar will be added to the new version of HDK :) I think it's good to have the tests there too. However, is there any downside to this? might we cause trouble for people using the HDK for development (rather than the build test infra?) If some doubts exist we can vote about it. LOL. No reason to vote - it's a technical issue with a single true'false answer - would having a single jar of tests screw up a developer using the HDK as originally intended, namely as a means to allow them to just checking one classlib module, and use HDK to supply the rest of the required headers, libraries and classes needed for building and testing. if the answer is "yes", then we need to figure out how to deal with it. If "no", then there's no problem and we go forward. The question here isn't "do we want the test.jar" - because I think we all do. The question is "how do we do this conveniently and safely?" I can not see any downside to have one more jar in the HDK. The problem could arise if that test.jar was used before the classes in the checked-out module, masking any changes or such that the developer was making. Thanks, Vladimir geir > > > > Thanks, Vladimir > > > > On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> >> They are at the regular place >> >> http://people.apache.org/dist/incubator/harmony/snapshots >> >> I moved all the old classlib snapshots into /old and I'll update the >> website accordingly. I'll be automating this. Also, lets not >> make much >> noise about this for a little while so we can test to make sure >> there's >> no major errors. Things seem good. I have a list of more things to >> fix, but I realized today that I was obsessing over the snapshot >> contents - it's not a release, and it's "good enough". >> >> I'd like to ditch both /old and the remaining classlib snapshots, as >> >> 1) they are snapshots - history doesn't matter >> >> 2) the classlib is now in the HDK, so we just need to adjust the >> docs to >> match. >> >> I'll do the latter, but wanted to see if anyone has a problem w/ me >> removing /old and the last classlib snapshot. I'll do this if I >> don't >> hear any protest, so either positively acknowledge this action if you >> support it, dont' do a thing if you support or dont' care, or say >> why we >> shouldn't :) >> >> geir >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] >> For additional commands, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> >> - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] jre and hdk snapshots posted to general snapshot site
On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Sep 27, 2006, at 3:10 AM, Vladimir Ivanov wrote: > Some times ago we discussed (and agreed?) that the HDK should > include tests > (also as support.jar which already included) and issue 984 was > filed to > build test.jar. > > It will nice if test.jar will be added to the new version of HDK :) I think it's good to have the tests there too. However, is there any downside to this? might we cause trouble for people using the HDK for development (rather than the build test infra?) If some doubts exist we can vote about it. I can not see any downside to have one more jar in the HDK. Thanks, Vladimir geir > > > > Thanks, Vladimir > > > > On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> >> They are at the regular place >> >> http://people.apache.org/dist/incubator/harmony/snapshots >> >> I moved all the old classlib snapshots into /old and I'll update the >> website accordingly. I'll be automating this. Also, lets not >> make much >> noise about this for a little while so we can test to make sure >> there's >> no major errors. Things seem good. I have a list of more things to >> fix, but I realized today that I was obsessing over the snapshot >> contents - it's not a release, and it's "good enough". >> >> I'd like to ditch both /old and the remaining classlib snapshots, as >> >> 1) they are snapshots - history doesn't matter >> >> 2) the classlib is now in the HDK, so we just need to adjust the >> docs to >> match. >> >> I'll do the latter, but wanted to see if anyone has a problem w/ me >> removing /old and the last classlib snapshot. I'll do this if I >> don't >> hear any protest, so either positively acknowledge this action if you >> support it, dont' do a thing if you support or dont' care, or say >> why we >> shouldn't :) >> >> geir >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: harmony-dev- >> [EMAIL PROTECTED] >> >> - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] jre and hdk snapshots posted to general snapshot site
On Sep 27, 2006, at 3:10 AM, Vladimir Ivanov wrote: Some times ago we discussed (and agreed?) that the HDK should include tests (also as support.jar which already included) and issue 984 was filed to build test.jar. It will nice if test.jar will be added to the new version of HDK :) I think it's good to have the tests there too. However, is there any downside to this? might we cause trouble for people using the HDK for development (rather than the build test infra?) geir Thanks, Vladimir On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: They are at the regular place http://people.apache.org/dist/incubator/harmony/snapshots I moved all the old classlib snapshots into /old and I'll update the website accordingly. I'll be automating this. Also, lets not make much noise about this for a little while so we can test to make sure there's no major errors. Things seem good. I have a list of more things to fix, but I realized today that I was obsessing over the snapshot contents - it's not a release, and it's "good enough". I'd like to ditch both /old and the remaining classlib snapshots, as 1) they are snapshots - history doesn't matter 2) the classlib is now in the HDK, so we just need to adjust the docs to match. I'll do the latter, but wanted to see if anyone has a problem w/ me removing /old and the last classlib snapshot. I'll do this if I don't hear any protest, so either positively acknowledge this action if you support it, dont' do a thing if you support or dont' care, or say why we shouldn't :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - 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] [launcher] Executable hangs
applied. thx On Sep 27, 2006, at 6:36 AM, Salikh Zakirov wrote: Salikh Zakirov wrote: Armand Navabi wrote: ../java: relocation error: /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/ libhyprt..so : symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference The error DRLVM's version of libhythr.so in fact does not define hythread_exit(), I've heard that Artem is currently preparing a patch to fix the problem by adding hythread_exit() definition. Just for the record, the fix for missing hythread_exit() is available in HARMONY-1590. - 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] Created: (HARMONY-1505) [build?] Some of the Harmony jni libraries has wrong function names inside
MS VC documentation recommends to use "__declspec(dllexport)" option instead of EXPORTS section. In our case it is JNIEXPORT. And all of the JNI functions are marked as JNIEXPORT. 2006/9/27, Mark Hindess <[EMAIL PROTECTED]>: On 27 September 2006 at 15:18, "Alexey Petrenko" <[EMAIL PROTECTED]> wrote: > So... If there is now EXPORTS section advocates I will prepare a patch > to remove them from the def files for Windows. If removing them means we are exporting all symbols, then I'd rather keep explicit exports of the symbols we intend to be public. Is there no way to fix it and keep the explicit list of "public" symbols? -Mark. > SY, Alexey > > 2006/9/26, Alexey Petrenko <[EMAIL PROTECTED]>: > > Guys, > > > > investigation shown that if we remove EXPORTS section from the def > > file then the result dll has correct names. > > > > Is there any objections on removing EXPORTS sections from the def > > files on Windows? > > > > SY, Alexey > > > > 2006/9/20, Alexey Petrenko (JIRA) <[EMAIL PROTECTED]>: > > > [build?] Some of the Harmony jni libraries has wrong function names insid > e > > > - > - > > > > > > Key: HARMONY-1505 > > > URL: http://issues.apache.org/jira/browse/HARMONY-1505 > > > Project: Harmony > > > Issue Type: Bug > > > Components: Classlib > > > Environment: Windows > > >Reporter: Alexey Petrenko > > > > > > > > > Some of the Harmony jni libraries, for example hyluni.dll, has function n > ames which are not prefixed by underscore ( _ ). > > > > > > JNI spec says that all the JNI methods on Windows should be declared as _ > _stdcall. [1] And MS C documentation says that __stdcall function names shoul > d be prefixed by underscore. [2] > > > > > > [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp615 > > > [2] http://msdn2.microsoft.com/en-us/library/zxk0tw93.aspx > > > > > > -- > > > 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 > > > > > > > > > > > > > > > -- > > Alexey A. Petrenko > > Intel Middleware Products Division > > > > > -- > 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: [jira] Created: (HARMONY-1505) [build?] Some of the Harmony jni libraries has wrong function names inside
On 27 September 2006 at 15:18, "Alexey Petrenko" <[EMAIL PROTECTED]> wrote: > So... If there is now EXPORTS section advocates I will prepare a patch > to remove them from the def files for Windows. If removing them means we are exporting all symbols, then I'd rather keep explicit exports of the symbols we intend to be public. Is there no way to fix it and keep the explicit list of "public" symbols? -Mark. > SY, Alexey > > 2006/9/26, Alexey Petrenko <[EMAIL PROTECTED]>: > > Guys, > > > > investigation shown that if we remove EXPORTS section from the def > > file then the result dll has correct names. > > > > Is there any objections on removing EXPORTS sections from the def > > files on Windows? > > > > SY, Alexey > > > > 2006/9/20, Alexey Petrenko (JIRA) <[EMAIL PROTECTED]>: > > > [build?] Some of the Harmony jni libraries has wrong function names insid > e > > > - > - > > > > > > Key: HARMONY-1505 > > > URL: http://issues.apache.org/jira/browse/HARMONY-1505 > > > Project: Harmony > > > Issue Type: Bug > > > Components: Classlib > > > Environment: Windows > > >Reporter: Alexey Petrenko > > > > > > > > > Some of the Harmony jni libraries, for example hyluni.dll, has function n > ames which are not prefixed by underscore ( _ ). > > > > > > JNI spec says that all the JNI methods on Windows should be declared as _ > _stdcall. [1] And MS C documentation says that __stdcall function names shoul > d be prefixed by underscore. [2] > > > > > > [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp615 > > > [2] http://msdn2.microsoft.com/en-us/library/zxk0tw93.aspx > > > > > > -- > > > 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 > > > > > > > > > > > > > > > -- > > Alexey A. Petrenko > > Intel Middleware Products Division > > > > > -- > 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: [drlvm] [launcher] Executable hangs
FWIW, Thanks for sticking with us on this. I'm sure we'll find it. geir On Sep 27, 2006, at 1:35 AM, Armand Navabi wrote: Gregory Shimansky wrote: I think not. DRLVM needs its own threading library. The reason is discussed in a separate thread "thread library - let there be one". I am not sure I understand all the reasoning for separate libhythr.so implementation, but I know the drlvm version should be in bin/ and bin/default/ directories. Ok, I read that thread. Is there an easy temporary fix to this? What is the reason to set breakpoint in jni.cpp:478? It is a condition that if JNI FindClass is called in exception state it shouldn't do anything, just return NULL. I'm sorry, my line 478 is different than yours, because I have other prints and things in there. I was not putting the breakpoint on the line that checks if it is called in exception state. Basically, I just put a print inside of that procedure because I traced the hanging to that method (or so I thought). My point was that I am unable to breakpoints anywhere in jni.cpp. Below you have explained what problem that is related to. And as far as tracing, you have suggested a much more efficient way to trace where it is going in the code. Thanks. Make breakpoint pending on future shared library load? (y or [n]) y And then when I run the program it never stops at the breakpoint, though I see the print I have inserted in the code. Secondly, and more importantly, if I try to do anything interesting, like run helloworld, gdb seems to lose a thread and then hang (says it Cannot find a thread. Invalid thread handle). I have to then stop it and go kill it. The solution for this was found and discussed in thread "APR fails to load a JIT library when using a fully qualified path". The launcher execs itself with a new environment setting for LD_LIBRARY_PATH and gdb cannot work around this. I reread those threads and it seems some changes were suggested. Have these changes been made. I couldn't see (or perhaps couldn't figure out) any way to quickly fix this from the discussions. It seemed as though people were suggesting moving and merging libraries. If it has been fixed, I should have it because I have recently updated. I have a proposal for you. Run "java -Xthread -Xtrace Hello" for hello world application. The -Xtrace option will produce a lot of output but it will enable all debugging tracing in drlvm and when it hangs for you it will be a very close location to the reason of the problem. If there is no output with -Xtrace, then it probably means launcher problems. Please update the sources, some launcher problems were resolved just recently I updated all the classlib and drlvm code earlier today. Just to make sure we are talking about the same thing here, I have compiled helloworld.java separately with Sun's compiler and then I made sure it ran (it runs both with Sun's java and the classlib with IBM's VM), and then I moved it to the drlvm's bin directory. There is no particular Hello application you are talking about correct? The application I am running was a java program I wrote myself and compiled. And then I tried to run my hello world application as you said. Like you said it produced a lot of output and towards the end when it hanged, this is the last output it produced: [0x4000] : Looking for native: java/lang/VMThreadManager.start(Ljava/lang/Thread;JZI)I [0x4000] : trying: Java_java_lang_VMThreadManager_start [0x4000] : Compiled method java/lang/VMThreadManager.start(Ljava/lang/Thread;JZI)I, entry 0xb68a4000 [0x4000] : GetObjectClass called [0x4000] : GetObjectClass: class = java/lang/FinalizerThread [0x4000] : GetFieldID called [0x4000] : GetFieldID java/lang/FinalizerThread.vm_thread J = 0x8286894 [0x4000] : GetLongField called, id = 0x8286894 [0x4000] : IsInstanceOf called [0x4000] : GetObjectClass called [0x4000] : GetObjectClass: class = java/lang/FinalizerThread [0x8003] : gc_thread_init 0x807d720 [0x8003] : FindClass called, name = java/lang/Thread [0x8003] : FindClass called, name = java/lang/Thread [0x8003] : si_goto_previous from ip = (nil) (M2N) [0x8003] : si_unwind_from_m2n, ip = (nil) [0x8003] : si_goto_previous to ip = (nil) (M2N) [0x8003] : StartLoading class java/lang/Thread with loader 0x8633a18 [0x8003] : 0x8633a18 0x807d660 I java/lang/Thread [0x8003] : Loader U (0x8633a18) loading class: java/lang/Thread... [0x8003] : enter method java/lang/ClassLoader loadClass (Ljava/lang/String;)Ljava/lang/Class; At this point, it hangs, and I am forced to Cntrl^c to kill the process. Thanks, Armand - 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
Re: [testing] HARMONY-995: adding new target to builds for automatic testing
On Sep 27, 2006, at 12:52 AM, Vladimir Ivanov wrote: On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Sep 26, 2006, at 10:47 PM, Vladimir Ivanov wrote: > On 9/26/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> <...> >> >> Right, but the system can easily automate doing the three steps in >> phases. The "build-test infrastructure" does that already. Well get >> timing info too... > > > Yes, but some people want to receive one notification for one > module (like > 'classlib OK' that means ws was built and all tests passed). In the > current > model this feature is not accessible. Why not? If someone wanted that, I'd design it so no mail is send on success of fetch and build, but only on tests. In this case he will miss the 'build-broken' event. We seem to be having a bit of a communication issue. No, he wouldn't miss it, because the system would send mail in that case. The system would send mail in case of failure for every case, and only success for the tests, as you seemed to be asking. Actually, my configuration wouldn't send mail for anything except "transition" - first failure, and then first recovery... > <...> >> >> > The external tool may implement some build sequences but seems it >> > should be defined be build itself. >> >> It is defined by build, but people are given the freedom of >> individual piece-parts for good reason. > > > Nobody takes away the freedom. > My suggestion was to add flexibility: if somebody wants build and test > Harmony by one command he can easily do it (not now). If other > peoples want > to do it step-by-step it is OK. It is their choice. > But build should provide both capabilities (at least, while it > costs nothing > - 1 line of code). Agreed - but who wants that now? IOW, what are you doing that requires this? Sometimes I checkout ws as clean and for me it will be convenient to fetch-depend, build and test it at one moment. Of cause, it is not too often :) > > By the way, the "build-test infrastructure" may be updated to > support both > modes by switch: do all commands step-by-step or run one command. I guess I still don't understand why, since I don't see to the user what the difference is if the system does three actions, or just one. For CC, the difference is three or one notification if user does not want to miss some events. But you can send just one email with a summary of everything that happened during that run. The fact that the system did : call fetch-depends call build clean call build call test should have no bearing on how many emails it sends. geir thanks, Vladimir geir > thanks, Vladimir > > geir >> >> > >> > >> > >> > thanks, Vladimir >> > >> > >> > >> >> >> >> > Issue http://issues.apache.org/jira/browse/HARMONY-1565 with >> >> > trivial update >> >> > was created. >> >> >> >> So do we really need this? >> >> >> >> geir >> >> >> >> >> >> > >> >> > thanks, Vladimir >> >> > >> >> > >> >> > >> >> > geir >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > Thanks, Vladimir >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- Forwarded message -- >> >> >> > From: Vladimir Ivanov (JIRA) <[EMAIL PROTECTED]> >> >> >> > Date: Sep 25, 2006 3:31 PM >> >> >> > Subject: [jira] Updated: (HARMONY-995) [testing] add >> support of >> >> >> proxy >> >> >> > settings for get-task >> >> >> > To: [EMAIL PROTECTED] >> >> >> > >> >> >> >[ http://issues.apache.org/jira/browse/HARMONY-995? >> page=all ] >> >> >> > >> >> >> > Vladimir Ivanov updated HARMONY-995: >> >> >> > >> >> >> > >> >> >> > Attachment: build.patch >> >> >> > >> >> >> > add notification, timeouts etc >> >> >> > >> >> >> >> [testing] add support of proxy settings for get-task >> >> >> >> >> >> >> >> >> >> >> >> Key: HARMONY-995 >> >> >> >> URL: http://issues.apache.org/jira/ browse/ >> >> >> HARMONY-995 >> >> >> >> Project: Harmony >> >> >> >> Issue Type: Bug >> >> >> >> Components: build - test - ci >> >> >> >>Reporter: Vladimir Ivanov >> >> >> >>Priority: Minor >> >> >> >> Attachments: build.patch, build.xml.patch, >> >> build.xml.patch >> >> >> >> >> >> >> >> >> >> >> >> 1) add external property file with proxy settings to use >> it int >> >> >> the >> >> >> > build.xml for task (when needed). >> >> >> >> 2) add '/c' symbol to run CC on win >> >> >> >> 3) seems, that readme.txt file should be updated to point as >> >> >> >> define proxy >> >> >> > for svn and get certificate >> >> >> > >> >> >> > -- >> >> >> > 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: ht
Re: [jira] Created: (HARMONY-1505) [build?] Some of the Harmony jni libraries has wrong function names inside
So... If there is now EXPORTS section advocates I will prepare a patch to remove them from the def files for Windows. SY, Alexey 2006/9/26, Alexey Petrenko <[EMAIL PROTECTED]>: Guys, investigation shown that if we remove EXPORTS section from the def file then the result dll has correct names. Is there any objections on removing EXPORTS sections from the def files on Windows? SY, Alexey 2006/9/20, Alexey Petrenko (JIRA) <[EMAIL PROTECTED]>: > [build?] Some of the Harmony jni libraries has wrong function names inside > -- > > Key: HARMONY-1505 > URL: http://issues.apache.org/jira/browse/HARMONY-1505 > Project: Harmony > Issue Type: Bug > Components: Classlib > Environment: Windows >Reporter: Alexey Petrenko > > > Some of the Harmony jni libraries, for example hyluni.dll, has function names which are not prefixed by underscore ( _ ). > > JNI spec says that all the JNI methods on Windows should be declared as __stdcall. [1] And MS C documentation says that __stdcall function names should be prefixed by underscore. [2] > > [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp615 > [2] http://msdn2.microsoft.com/en-us/library/zxk0tw93.aspx > > -- > 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 > > > -- Alexey A. Petrenko Intel Middleware Products Division -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] [launcher] Executable hangs
On the 0x1F1 day of Apache Harmony Salikh Zakirov wrote: > Egor Pasko wrote: > > hm, looks stange to me. I see a def of hythread_exit() in > > hythread.c:1530. Why it is not in libhythr.so is a mystery ;) > > No mistery. hythread_exit() *is* defined in CLASSLIB's libhythr.so, > but DRLVM insists on using its own, different, libhythr.so. Salikh, thank you for clarification. -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] [launcher] Executable hangs
On the 0x1F0 day of Apache Harmony Armand Navabi wrote: > > What is the kernel version BTW? There could be some issues with > > 2.4.x, currently everybody works with 2.6.x > > The kernel version is 2.6.17.8. > > > concerning hythread_exit .. Did you resolve it already? I see the > > symbol _undefined_ too (and no definition of the symbol in hythread.so > > or any other lib, although sources are fine, probably some bug in the > > build system), but dynamic linker does not complain on my machine. > > No, I did not resolve this problem. When I try to run ./java by itself I > see the following: > > ./java: relocation error: > /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt.so > : symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so > with link time reference > > And then it hangs. I did find that this would not happen (i.e. ./java would > run just fine) if I overwrite libhythr.so with the libhythr.so from the > classlib's /deploy/jdk/jre/bin directory. Is that a safe way to resolve > this problem? > > > hm, gdb .. did you 'export' LD_LIBRARY_PATH? > > (sorry for the dummy question:) > > No need apologize. I'm sure in the end it will be a dummy mistake that I'm > making. But yes, I did export the LD_LIBRARY_PATH. I had it first set to > the deploy/jre/bin directory. I also tried to set it to put > deploy/jre/bin/default also in the path. > > Let me be clear when I say I am unable to debug with gdb. First the problem > I am having is when I try to set a breakpoint I always see this: > > (gdb) b jni.cpp:478 > No source file named jni.cpp. > Make breakpoint pending on future shared library load? (y or [n]) y I solve this by breaking inside launcher after VM lib is loaded, then I break somewhere after libjitrino.so is loaded. Then I can break anywhere :) looks like this: break main.c:360 r dis break compile_jit_a_method c dis break whatever function you want You can make it a script via GDB's 'define' and put somewhere in ~/.gdbinit, two scripts are better: first for initial run, the second script does the same but reusing old breakpoint numbers: dis en 1 r dis en 2 c dis I should put that into the FAQ, obviously. > > And then when I run the program it never stops at the breakpoint, though I > see the print I have inserted in the code. Secondly, and more importantly, > if I try to do anything interesting, like run helloworld, gdb seems to lose > a thread and then hang (says it Cannot find a thread. Invalid thread > handle). I have to then stop it and go kill it. this one is probably a separate issue (not connected with "future shared library load"). Try my above suggestion, please. > GNU gdb 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db > library "/lib/libthread_db.so.1". > > (gdb) r helloworld > Starting program: > /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java > helloworld > [Thread debugging using libthread_db enabled] > [New Thread 16384 (LWP 11007)] > [New Thread 32769 (LWP 11010)] > [New Thread 16386 (LWP 11011)] > Cannot find thread 32769: invalid thread handle > (gdb) q > The program is running. Exit anyway? (y or n) y > > [1]+ Stopped gdb ./java > > > Thanks, > Armand > > > On the 0x1F0 day of Apache Harmony Armand Navabi wrote: > > > When I try to run ./java helloworld, it just hangs and I have to kill > > > the process. I investigated this a little bit, and I found that it > > > hangs on the call to FindClass (in main.c line around line 1199). > > > I am > > > unable debug with gdb also, so I have resorted to printf's, and in > > > jni.cpp, I found the definition of FindClass, and put an printf to see > > > what class it is trying to find when it hangs. I see the following: > > > > > > Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread > > > > > > Also, when I run ./java -Xtrace:em, I get the following (and it > > > hangs): > > > ... > > > EM: compile start:[JET_DPGO n=802] java/lang/Thread::join()V > > > EM: compile done:[JET_DPGO n=802: OK] java/lang/Thread::join()V > > > EM: compile start:[JET_DPGO n=803] java/lang/Object::wait()V > > > EM: compile done:[JET_DPGO n=803: OK] java/lang/Object::wait()V > > > Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread > > > > > > Again, it seems to always hang after FindClass is called for > > > java/lang/Thread. > > > > > > I have tried setting LD_LIBRARY_PATH as suggested earlier. I also > > > have > > > JAVA_HOME set (and I have tried it with it unset). Everything > > > seems to > > > have the same behavior. > > > [EMAIL PROTECTED] ~/Harmony/enh
Re: [drlvm] [launcher] Executable hangs
Egor Pasko wrote: > hm, looks stange to me. I see a def of hythread_exit() in > hythread.c:1530. Why it is not in libhythr.so is a mystery ;) No mistery. hythread_exit() *is* defined in CLASSLIB's libhythr.so, but DRLVM insists on using its own, different, libhythr.so. - 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] Is it comfortable for committers when source and test patches are packed in the single diff file?
OK, thanks a lot. P.S. I have found your discussion about separate patches. 2006/9/27, Nathan Beyer <[EMAIL PROTECTED]>: > -Original Message- > From: Tim Ellison [mailto:[EMAIL PROTECTED] > > Geir Magnusson Jr. wrote: > > > > On Sep 26, 2006, at 10:23 AM, Denis Kishenko wrote: > > > >> Geir, thanks for answer. > >> > >> As I understand committers don't run tests from issue's descriptions? > > > > Sometimes. But if a test can be provided, it makes things a lot easier > > on the committers, and improves chances of getting in. > > I agree -- and two patch files is just fine. > > Regards, > Tim I'll add another vote to two patch files. I do exactly what Geir said; apply the test patch, run the tests to see the failure, then apply the source patch to see how it fixes the issue. -Nathan > > >> 2006/9/26, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > >>> I really, really like two patches as we discussed on a different > thread. > >>> > >>> That way, I can apply the test patch, show the bug, apply the source > >>> patch, show it's gone (and then screw up and not commit all the code > >>> in the patch ;) > >>> > >>> Tim was neutral, but didn't care, so there's no opposition to asking > >>> for two. > >>> > >>> geir > >>> > >>> On Sep 26, 2006, at 9:29 AM, Denis Kishenko wrote: > >>> > >>> > Sometime I make two different diff files (source and test patches), > >>> > sometime I make the single one. Does it make sense for committers? > >>> > > >>> > > - > >>> > Terms of use : http://incubator.apache.org/harmony/mailing.html > >>> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> > For additional commands, e-mail: harmony-dev- > [EMAIL PROTECTED] > >>> > > >>> > >>> > >>> - > >>> Terms of use : http://incubator.apache.org/harmony/mailing.html > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> > >> > >> --Denis M. Kishenko > >> Intel Middleware Products Division > >> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Denis M. Kishenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM
Here is the second part which provides details on thread_java_basic.c. 1) jthread_create_with_function a) JavaVM * java_vm argument instead of JNI_Env * env. First of all when jthread_create_with_function is called there is no jni environment created for new thread yet. It will be created when vm_jthread_attach is called. vm_jthread_attach wants to know to which VM current thread should be attached. That's why I pass java VM instead of JNI environment. As I sad once we can think of modifying current scheme and call vm_jthread_attach before jthread_create/jthread_attach. In that case it is reasonable to pass JNI_Env. b) removed support for irregular use. I think it is not very good to have that code for couple of reasons. First (not very important) it is useless actions in any real scenario. At least everything works just fine without it. Second it can hide a real problem. According to current design there should be no such cases when jthread object is not associated with hythread. It can be important to catch if something goes wrong as early as we could. c) removed temporary pool creation. Actually this pool has the same life time as global APR pool. So it is a memory leak. Moreover I just don't see any reason to create it. Lets use existing one with proper life time. d) "daemon" notion was moved to hythread layer. That's really discussable. See one of my previous mail. 2)jthread_attach a) signature has changed significantly. Hmm, that was required to implement InvocationAPI according to spec :-) Ask particular questions please if you have them. 3)jthread_detach same story as 2) 4) wrapper_proc: Seems like a lot of changes but not so many important. Only two changes are really significant: a) moved processing of non-daemon threads to hythread layer. Discussed earlier. b) added initialization of jvmti_thread->jenv field. Actually this is the only place when it is first available... Ups... it seems I missed jvmti_send_thread_start_end_event(1) in one of my merges need to be fixed. Thanks Evgueni On 9/27/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: On 9/27/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > On Tuesday 26 September 2006 17:25 Geir Magnusson Jr. wrote: > > Wanted to start a new thread with better subject line. > > I want to take part in this thread too. > > 1. As Tim has mentioned in a separate thread the multiVM support requires that > we don't use global and static variables in native code. One global variable > used often in drlvm across all of the code is Global_Env::loader_env. I > didn't find it in the patch code so I want to ask you, did you move this > pointer into TLS? Not exactly. You are right I tried to write the code which supports multi VM. But that was not my main goal at this moment. So what I did in that direction is 1) I added JNIEnv * into VM_thread structure. So you can always get a Global_Env having JNIEnv. Probably it makes sense to use VM local storage to keep Global_Env as well. I consider it as another tasknot InvocationAPI 2) Localized thread library instance for each VM. 3) Fixed those places where Global_Env can be extracted from JNI_Env *. see jni_get_vm_env function. > > 2. Can we get avoid all of the CR-LF EOLs introduced in this patch? I will do my best in the future. I promise :-) Evgueni > > -- > Gregory Shimansky, Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] [launcher] Executable hangs
Salikh Zakirov wrote: > Armand Navabi wrote: >> ../java: relocation error: >> /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt..so >> : symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so >> with link time reference > > The error DRLVM's version of libhythr.so in fact does not define > hythread_exit(), > I've heard that Artem is currently preparing a patch to fix the problem > by adding hythread_exit() definition. Just for the record, the fix for missing hythread_exit() is available in HARMONY-1590. - 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] [launcher] Executable hangs
On the 0x1F1 day of Apache Harmony Salikh Zakirov wrote: > Armand Navabi wrote: > >> What is the kernel version BTW? There could be some issues with > >> 2.4.x, currently everybody works with 2.6.x > > > > The kernel version is 2.6.17.8. > > > >> concerning hythread_exit .. Did you resolve it already? I see the > >> symbol _undefined_ too (and no definition of the symbol in hythread.so > >> or any other lib, although sources are fine, probably some bug in the > >> build system), but dynamic linker does not complain on my machine. > > > > No, I did not resolve this problem. When I try to run ./java by itself I > > see the following: > > > > ../java: relocation error: > > /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt..so > > : symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so > > with link time reference > > The error DRLVM's version of libhythr.so in fact does not define > hythread_exit(), > I've heard that Artem is currently preparing a patch to fix the problem > by adding hythread_exit() definition. hm, looks stange to me. I see a def of hythread_exit() in hythread.c:1530. Why it is not in libhythr.so is a mystery ;) > From what I've seen, hythread_exit() is not used by launcher in a "normal" > code path, > and this message is only shown when running java without parameters > (or if the VM loading failed for some reason). -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
On the 0x1F1 day of Apache Harmony Xiao-Feng Li wrote: > Thanks. Yes, this is supposed to be review by JIT person. On the other > hand, if JIT person has better solution, GCv5 would like to use. > Anyway we hope write barrier is to be functioning in the DRLVM soon. As a JIT-oriented guy, I looked through the patch. Looks good. The write barrier does NOT push an M2N frame before invoking gc_heap_slot_write_ref(), but it's OK since there will be no stack unwinding from here. I am curious about the switch VM_Global_State::loader_env->use_lil_stubs. Does everything work in both true and false? What do we need this switch for? Doesn't it induce unnecessary complication/duplication? > On 9/27/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > It would probably be best if a JIT person committed this patch. Maybe > > Stephan Mishura? > > > > If its not committed soon, bug me and I will do it. > > > > > > On 9/26/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > > > > Hi, the patch attached in JIRA 1580 (submitted by YuNan) is a write > > > barrier implementation for JET that GCv5 is going to use (it doesn't > > > impact anything else). It would be great if some commiter can help to > > > review and commit it. Thanks. -xiaofeng > > > > > > http://issues.apache.org/jira/browse/HARMONY-1580?page=all > > > > > > The patch is against revision revision 442796. > > > > > > Repeat the desciption of the patch: > > > "Attached patch is an implementation of write barrier for JET compiler > > > of DRLVM. The patch lets JET to call "gc_requires_barriers()" of GC to > > > determine if it needs to insert the write barrier code into the jitted > > > code, so it doesn't impact current DRLVM/GC at all. It calls > > > gc_heap_slot_write_ref( ) of GC module, which takes three parameters. > > > The signature is "void gc_heap_slot_write_ref (Managed_Object_Handle > > > p_obj_holding_ref,Managed_Object_Handle *p_slot, Managed_Object_Handle > > > p_target)". > > > > > > The patch is based on revision 442796. We hope it can be committed to > > > Harmony soon because GCv5 will be depending on it. We don't use > > > existing getaddress__gc_write_barrier_fastcall () in DRLVM because it > > > only remembers object rather than the slot, and the name is not > > > descriptive. But we may use it later. Thanks." > > > > > > - > > > 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] > > -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM
On 9/27/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: On Tuesday 26 September 2006 17:25 Geir Magnusson Jr. wrote: > Wanted to start a new thread with better subject line. I want to take part in this thread too. 1. As Tim has mentioned in a separate thread the multiVM support requires that we don't use global and static variables in native code. One global variable used often in drlvm across all of the code is Global_Env::loader_env. I didn't find it in the patch code so I want to ask you, did you move this pointer into TLS? Not exactly. You are right I tried to write the code which supports multi VM. But that was not my main goal at this moment. So what I did in that direction is 1) I added JNIEnv * into VM_thread structure. So you can always get a Global_Env having JNIEnv. Probably it makes sense to use VM local storage to keep Global_Env as well. I consider it as another tasknot InvocationAPI 2) Localized thread library instance for each VM. 3) Fixed those places where Global_Env can be extracted from JNI_Env *. see jni_get_vm_env function. 2. Can we get avoid all of the CR-LF EOLs introduced in this patch? I will do my best in the future. I promise :-) Evgueni -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] [launcher] Executable hangs
Armand Navabi wrote: >> What is the kernel version BTW? There could be some issues with >> 2.4.x, currently everybody works with 2.6.x > > The kernel version is 2.6.17.8. > >> concerning hythread_exit .. Did you resolve it already? I see the >> symbol _undefined_ too (and no definition of the symbol in hythread.so >> or any other lib, although sources are fine, probably some bug in the >> build system), but dynamic linker does not complain on my machine. > > No, I did not resolve this problem. When I try to run ./java by itself I > see the following: > > ../java: relocation error: > /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt..so > : symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so > with link time reference The error DRLVM's version of libhythr.so in fact does not define hythread_exit(), I've heard that Artem is currently preparing a patch to fix the problem by adding hythread_exit() definition. >From what I've seen, hythread_exit() is not used by launcher in a "normal" >code path, and this message is only shown when running java without parameters (or if the VM loading failed for some reason). - 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][test] "fail" statements omitted in many exception catching test cases
Hi Robert,
Nice work! I've checked the entries for classes from the beans module.
It seems you found at least three bugs in tests for beans:
Bugs:
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextServicesSupportTest.java:739
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextSupportTest.java:1388
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLEncoderTest.java:449
Valid:
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextSupportTest.java:234\251
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\IntrospectorTest.java:1266\1304
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\StatementTest.java:93
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLDecoderTest.java:92
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLEncoderTest.java:334
Thank you for this. I will file corresponding JIRA.
Regards,
2006/9/27, Robert Hu <[EMAIL PROTECTED]>:
Hi All,
In our unit test of classlib, there are huge number of test cases about
exception catching. The typical style of those cases is like that:
try {
someStatementShouldThrowAnException;
* fail("Expected an exception");*
} catch (SomeException e){
// Expected
}
If we omit the "fail" statement, the test case is wrong because the
exception-throwing checking is disabled.
I've found that the "fail" statement is omitted in many test cases of our
Harmony classlib. So I set some rules to find out all lines of code related with it. If a
line of code comform all the 5 rules, it may be a bug:
1.in a "*Test.java" file
2.does not start with "//"
3.contains "catch"
4.its previous line does not contains "fail"
5.its next line contains "//" or "}"
Then I found out 1711 lines of code in 309 files comform all the 5 rules in
r450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are not of above
style.
And I also find out some real bugs, we can fix them easilly:
trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:652\658\664\670\676\685\698\704\711(line
number)
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTest.java:57
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileInputStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileOutputStreamTest.java:35
..
*I must say frankly that it's hard to find out all bugs of this kind without any
"victims" automatically, we must find out real bugs ourselves.*
Hope the result in attachment file can help us to find out more bugs.
Anybody has better search rules or better solution to find out those bugs? Pls.
share with us, thanks a lot.
--
Robert Hu
China Software Development Lab, IBM
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarFileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\DeflaterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\DeflaterTest.java:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\1099\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipFileTest.java:67\291
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipInputStreamTest.java:200
.\auth\src\test\java\common\javax\security\auth\callback\ConfirmationCallbackTest.java:60\147
.\auth\src\test\java\common\javax\security\auth\callback\LanguageCallbackTest.java:60
.\auth\src\test\java\common\javax\security\auth\kerberos\ServicePermissionTest.java:302
.\auth\src\test\java\common\javax\security\auth\PolicyTest.java:132
.\auth\src\test\java\common\javax\security\auth\PrivateCredentialPermissionTest.java:267\386
.\auth\src\test\java\common\javax\security\auth\SubjectTest.java:239\248\257\269\992\1109\1301\1314\1423\1851\2049\2061\2089\2101\2127\2139
.\auth\src\test\java\common\javax\security\auth\x500\X500PrincipalTest.java:2404
.\auth\src\test\java\common\javax\security\auth\x500\X500PrivateCredentialTest.java:169\179\189
.\auth\src\test\java\common\org\apache\harmony\auth\internal\SecurityTest.java:807\855\950\971\987\995\1003\1011\1065\1089\1090\1101\1116\1125\1133\1141\1142\1151\1152\1161\1162
.\auth\src\test\java\common\org\apache\harmony\auth\login\DefaultConfigParserTest.java:79\182
.\awt\src\test\api\java\common\java\awt\color\ICC_ProfileRTest.java:37
.\awt\src\test\api\java\common\java\awt\ComponentTest.java:751
.\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:652\658\664\670\676\685\698\704\711
.\awt\src\test\api\java\windows\org\apache\harmony\awt\tests\java\awt\WinFontTest.java:427
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext
Re: [classlib][math]three tests fail, anyone else see this?
Yep, seems now this the problem is fixed.
The issue was exactly related to the internationalization and I'd provided
patch to fix tests for HARMONY-1323 (which probably hadn't been applied)
However Paulex have fixed message itself (It's also appropriate) and
now tests should be fine.
Thanks,
Ilya.
On 9/27/06, Richard Liang <[EMAIL PROTECTED]> wrote:
On 9/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Let me take a look -- I applied that patch.
>
It seems that Paulex had fixed this issue. ;-)
Best regards,
Richard
> Regards,
> Tim
>
> Stepan Mishura wrote:
> > Yes, is see failures. I guess that a cause may be math module
> > internalization.
> >
> > Thanks,
> > Stepan.
> >
> >
> > On 9/27/06, Paulex Yang wrote:
> >>
> >> Anyone else see these test errors of BigDecimalConstructorsTest?
> >>
> >> testConstrDoubleNaNFailureImproper exception message
> >> expected:<...e...> but was:<...y...>
> >> testConstrDoublePosInfinityFailureImproper exception message
> >> expected:<...e...> but was:<...y...>
> >> testConstrDoubleNegInfinityFailureImproper exception message
> >> expected:<...e...> but was:<...y...>
> >>
> >>
> >> I believe it is caused by the patch of i18n message properties, it
> >> returns "Infinity or NaN", I've updated it at revision r450333, but
is
> >> it necessary to verify exception message so strictly like this?
> >>
> >>
> >>try {
> >>new BigDecimal(a);
> >>fail("NumberFormatException has not been caught");
> >>} catch (NumberFormatException e) {
> >>assertEquals("Improper exception message", "Infinite or
NaN",
> >>e.getMessage());
> >>}
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> 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]
> >
>
> --
>
> 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]
>
>
--
Richard Liang
China Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
--
Ilya Okomin
Intel Middleware Products Division
Re: [classlib][math]three tests fail, anyone else see this?
On 9/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Let me take a look -- I applied that patch.
It seems that Paulex had fixed this issue. ;-)
Best regards,
Richard
Regards,
Tim
Stepan Mishura wrote:
> Yes, is see failures. I guess that a cause may be math module
> internalization.
>
> Thanks,
> Stepan.
>
>
> On 9/27/06, Paulex Yang wrote:
>>
>> Anyone else see these test errors of BigDecimalConstructorsTest?
>>
>> testConstrDoubleNaNFailureImproper exception message
>> expected:<...e...> but was:<...y...>
>> testConstrDoublePosInfinityFailureImproper exception message
>> expected:<...e...> but was:<...y...>
>> testConstrDoubleNegInfinityFailureImproper exception message
>> expected:<...e...> but was:<...y...>
>>
>>
>> I believe it is caused by the patch of i18n message properties, it
>> returns "Infinity or NaN", I've updated it at revision r450333, but is
>> it necessary to verify exception message so strictly like this?
>>
>>
>>try {
>>new BigDecimal(a);
>>fail("NumberFormatException has not been caught");
>>} catch (NumberFormatException e) {
>>assertEquals("Improper exception message", "Infinite or NaN",
>>e.getMessage());
>>}
>>
>>
>>
>>
>>
>>
>> --
>> 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]
>
--
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]
--
Richard Liang
China Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Wonka, Mika, and Apache
Hello guys, To introduce myself: I'm one of the original developers of the Wonka embedded VM, and my company sells both support for Wonka and our own derivative which we call Mika. Recently we made Mika available under the same BSD-style licence as Wonka. My question is whether Apache would be interested in adopting Wonka/Mika as a project, either within Harmony or as an embedded counterpart thereto. Currently ownership of the code is divided between Punch Telematix, who acquired the assets of my former employer Acunia, and my own company. Punch have no interest in the VM beyond the fact that it is an essential component of a product (the CarCube) which they inherited from Acunia. I believe they would have no objection to granting rights to the AF, beyond the sheer effort of doing so. They can probably be persuaded, but first I'd like to know if there is sufficient interest within the AF. Best regards, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][math]three tests fail, anyone else see this?
Let me take a look -- I applied that patch.
Regards,
Tim
Stepan Mishura wrote:
> Yes, is see failures. I guess that a cause may be math module
> internalization.
>
> Thanks,
> Stepan.
>
>
> On 9/27/06, Paulex Yang wrote:
>>
>> Anyone else see these test errors of BigDecimalConstructorsTest?
>>
>> testConstrDoubleNaNFailureImproper exception message
>> expected:<...e...> but was:<...y...>
>> testConstrDoublePosInfinityFailureImproper exception message
>> expected:<...e...> but was:<...y...>
>> testConstrDoubleNegInfinityFailureImproper exception message
>> expected:<...e...> but was:<...y...>
>>
>>
>> I believe it is caused by the patch of i18n message properties, it
>> returns "Infinity or NaN", I've updated it at revision r450333, but is
>> it necessary to verify exception message so strictly like this?
>>
>>
>>try {
>>new BigDecimal(a);
>>fail("NumberFormatException has not been caught");
>>} catch (NumberFormatException e) {
>>assertEquals("Improper exception message", "Infinite or NaN",
>>e.getMessage());
>>}
>>
>>
>>
>>
>>
>>
>> --
>> 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]
>
--
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][test] "fail" statements omitted in many exception catching test cases
This perl script does a marginally better job by being slightly stricter
on matching context around 'catch'/'fail', by handling comments slightly
better and by handling 'catch (...) { }' appearing on a single line.
It also finds a few more hits such as:
sql/src/test/java/org/apache/harmony/sql/tests/java/sql/TimeTest.java +208
which is a false positive but which uses "assertTrue(false);" which
should be fixed anyway.
-Mark.
#!/usr/bin/perl -w
use strict;
my $previous_line = "";
my $possible_line_number;
while (<>) {
next if (/^\s*$/); # skip blank lines
if ($possible_line_number) {
if (m!^\s*(//|/\*|})!) {
print $ARGV, ' +', $possible_line_number, "\n";
}
undef $possible_line_number;
}
if (!m!^\s*(/?\*|//)! && /\bcatch\s*\(/ && $previous_line !~ /\bfail\s*\(/) {
$possible_line_number = $.;
if (/catch\s*\([^\)]+\)\s*{\s*}/) {
print $ARGV, ' +', $possible_line_number, "\n";
undef $possible_line_number;
}
}
$previous_line = $_;
}
On 27 September 2006 at 15:02, Robert Hu <[EMAIL PROTECTED]> wrote:
> --090601000506020908060004
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain; charset=GB2312
>
> Hi All,
>
> In our unit test of classlib, there are huge number of test cases about excep
> tion catching. The typical style of those cases is like that:
>
> try {
> someStatementShouldThrowAnException;
> * fail("Expected an exception");*
> } catch (SomeException e){
> // Expected
> }
>
> If we omit the "fail" statement, the test case is wrong because the exception
> -throwing checking is disabled.
>
> I've found that the "fail" statement is omitted in many test cases of our Har
> mony classlib. So I set some rules to find out all lines of code related with
> it. If a line of code comform all the 5 rules, it may be a bug:
> 1.in a "*Test.java" file
> 2.does not start with "//"
> 3.contains "catch"
> 4.its previous line does not contains "fail"
> 5.its next line contains "//" or "}"
>
>
> Then I found out 1711 lines of code in 309 files comform all the 5 rules in r
> 450321. (Attachment file is the result.)
> Of course not all of them are bug, because some test cases are not of above s
> tyle.
>
> And I also find out some real bugs, we can fix them easilly:
> trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:
> 652\658\664\670\676\685\698\704\711(line number)
> trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTest.
> java:57
> trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileIn
> putStreamTest.java:36
> trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileOu
> tputStreamTest.java:35
> ..
>
> *I must say frankly that it's hard to find out all bugs of this kind without
> any "victims" automatically, we must find out real bugs ourselves.*
>
> Hope the result in attachment file can help us to find out more bugs.
>
> Anybody has better search rules or better solution to find out those bugs? Pl
> s. share with us, thanks a lot.
>
> --
> Robert Hu
> China Software Development Lab, IBM
>
>
> --090601000506020908060004
> Content-Type: text/plain;
> name="result.txt"
> Content-Disposition: inline;
> filename="result.txt"
> Content-Transfer-Encoding: quoted-printable
>
> current position is trunk\modules
> .\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarF=
> ileTest.java:66\79\190
> .\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl=
> aterOutputStreamTest.java:220\230
> .\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl=
> aterTest.java:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\10=
> 99\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
> .\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipF=
> ileTest.java:67\291
> .\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipI=
> nputStreamTest.java:200
> .\auth\src\test\java\common\javax\security\auth\callback\ConfirmationCallba=
> ckTest.java:60\147
> .\auth\src\test\java\common\javax\security\auth\callback\LanguageCallbackTe=
> st.java:60
> .\auth\src\test\java\common\javax\security\auth\kerberos\ServicePermissionT=
> est.java:302
> .\auth\src\test\java\common\javax\security\auth\PolicyTest.java:132
> .\auth\src\test\java\common\javax\security\auth\PrivateCredentialPermission=
> Test.java:267\386
> .\auth\src\test\java\common\javax\security\auth\SubjectTest.java:239\248\25=
> 7\269\992\1109\1301\1314\1423\1851\2049\2061\2089\2101\2127\2139
> .\auth\src\test\java\common\javax\security\auth\x500\X500PrincipalTest.java=
> :2404
> .\auth\src\test\java\common\javax\security\auth\x500\X500PrivateCredentialT=
> est.java:169\179\189
> .\auth\src\test\java\common\org\apache\harmony\auth\internal\SecurityTest.j=
> ava:807\855\950\971\987\995\1003\1011\1065\1089\1090\1101\1116\112
Re: [classlib][test] "fail" statements omitted in many exception catching test cases
Maybe we have to review the tests one by one. ;-)
On 9/27/06, Robert Hu <[EMAIL PROTECTED]> wrote:
Hi All,
In our unit test of classlib, there are huge number of test cases about
exception catching. The typical style of those cases is like that:
try {
someStatementShouldThrowAnException;
* fail("Expected an exception");*
} catch (SomeException e){
// Expected
}
If we omit the "fail" statement, the test case is wrong because the
exception-throwing checking is disabled.
I've found that the "fail" statement is omitted in many test cases of our
Harmony classlib. So I set some rules to find out all lines of code related with it. If a
line of code comform all the 5 rules, it may be a bug:
1.in a "*Test.java" file
2.does not start with "//"
3.contains "catch"
4.its previous line does not contains "fail"
5.its next line contains "//" or "}"
Then I found out 1711 lines of code in 309 files comform all the 5 rules in
r450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are not of above
style.
And I also find out some real bugs, we can fix them easilly:
trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:652\658\664\670\676\685\698\704\711(line
number)
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTest.java:57
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileInputStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileOutputStreamTest.java:35
..
*I must say frankly that it's hard to find out all bugs of this kind without any
"victims" automatically, we must find out real bugs ourselves.*
Hope the result in attachment file can help us to find out more bugs.
Anybody has better search rules or better solution to find out those bugs? Pls.
share with us, thanks a lot.
--
Robert Hu
China Software Development Lab, IBM
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarFileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\DeflaterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\DeflaterTest.java:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\1099\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipFileTest.java:67\291
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipInputStreamTest.java:200
.\auth\src\test\java\common\javax\security\auth\callback\ConfirmationCallbackTest.java:60\147
.\auth\src\test\java\common\javax\security\auth\callback\LanguageCallbackTest.java:60
.\auth\src\test\java\common\javax\security\auth\kerberos\ServicePermissionTest.java:302
.\auth\src\test\java\common\javax\security\auth\PolicyTest.java:132
.\auth\src\test\java\common\javax\security\auth\PrivateCredentialPermissionTest.java:267\386
.\auth\src\test\java\common\javax\security\auth\SubjectTest.java:239\248\257\269\992\1109\1301\1314\1423\1851\2049\2061\2089\2101\2127\2139
.\auth\src\test\java\common\javax\security\auth\x500\X500PrincipalTest.java:2404
.\auth\src\test\java\common\javax\security\auth\x500\X500PrivateCredentialTest.java:169\179\189
.\auth\src\test\java\common\org\apache\harmony\auth\internal\SecurityTest.java:807\855\950\971\987\995\1003\1011\1065\1089\1090\1101\1116\1125\1133\1141\1142\1151\1152\1161\1162
.\auth\src\test\java\common\org\apache\harmony\auth\login\DefaultConfigParserTest.java:79\182
.\awt\src\test\api\java\common\java\awt\color\ICC_ProfileRTest.java:37
.\awt\src\test\api\java\common\java\awt\ComponentTest.java:751
.\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:652\658\664\670\676\685\698\704\711
.\awt\src\test\api\java\windows\org\apache\harmony\awt\tests\java\awt\WinFontTest.java:427
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextServicesSupportTest.java:739
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextSupportTest.java:234\251\1388
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\IntrospectorTest.java:1266\1304
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\StatementTest.java:93
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLDecoderTest.java:92
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLEncoderTest.java:334
.\concurrent\standard\src\test\java\AbstractExecutorServiceTest.java:215\235\253\306\311\340\341\353\389\403\418\436\454\473\488\521\541\562\578\595\610\628\646\665\680\697\730\750\771
.\concurrent\standard\src\test\java\AbstractQueuedSynchronizerTest.java:76\92\162\365\514\531\631\645\660\677\692\709\724\741\756\976\1007\1039\1236\1260
.\concurrent\standard\src\test\java\AbstractQueueTest.java:62\74\94\115\128\140\154\169
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM
Ok here is some details on threading library changes. Most of changes in TM affects two files thread_native_basic.c and thread_java_basic.c. Lets start with the first one. Main cause of all modification in that file comes from refactoring hythread_attach_to_group and hythread_detach functions. 1) hythread_attach_to_group a) new hythread_library_t parameter was added to the function signature. What for? For multi VM :-) When you attaches a thread to a thread library you need to specify to which particular library because each VM has its own. b) I've changed initialization/allocation of HyThread structure for attaching thread. Why? Bug in the current implementation. Input parameter (handle) is processed incorrectly. New instance of HyThread structure is created each time instead of using *handle one. This is expected behaviour according to specification of hythread_atach. So it is the bug. c) Setting TLS and changing thread status to alive and runnable is encapsulated in one place register_to_group. I will talk about it later. 2)hythread_detach a) originally there were two functions public hythread_detach and private destroy_thread. Each of them did its part of job when thread is not needed any more. I just merged them into one to make it easy to use and understand. Why? If you look closer to original hythread_detach it calls thread_destroy. So thread_destroy is a part of detaching. Fine. Lets jump to thread_start_proc. Look at shutdown sequence. It calls thread_destroy and sets TLS to NULL. Hmm this sequence does exactly the same as hythread_detach. Lets call hythread_detach instead. OK. Then what is the reason to have thread_destroy? When should we use thread_destroy instead of hythread_detach. I suspect never. If we do so we are asking for troubles. What I did? I concentrate all that stuff in one place. It is much linear I believe. 3) reset_thread, init_thread. There is a common problem with these two functions. They both add HyThread strucure to the specified thread group. It really bad. There are use cases when reset_thread called several times before a real thread is forked. In that case the same thread will be added to the group several times. Moreover reset_thread adds the thread to the same group each time what if I want to reuse HyThread structure but register it to another group. Ups doesn't work. So I moved group processing out of these functions. The last thing here is changing function name from init_thread to allocate_thread because it really allocates new HyThread structure. I don't insist on renaming but it seems new name reflects things better. 4) allocate_thread. I'm really confused by such names. There is init_thread that allocates new HyThread structure. And allocate_thread which adds allocated thread to the group. Sorry but I renamed it to allocate_thread and register_to_group correspondingly. In the current implementation code which deals with registering a thread to thread group is spread among three functions reset_thread, init_thread, allocate_thread... I put all that code in one place register_to_group and call when necessary. Seems to be easy That's all about hythread_native_basic.c. I need to leave my computer for a couple hours. I will come back with the second part Evgueni On 9/27/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: On 9/27/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote: > On 9/26/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: > > >Alexey Varlamov [26/Sep/06 05:11 AM] > > >Evgueni, thank you, quite impressive work! > > >Unfortunately patch is so huge it is hard to understand at once. > > > > I understand your concern (about reformatting)... I feel very-very > > uncomfortable when I study purely formatted code. It always hard to > > understand some one's code especially if it is hard to read. That was > > not my intention to fix indenting I just can't study such code and > > reformat it on the fly Sorry, I don't know how to switch my patch > > to the original formatting. > > > > >And what really bothers, is that about half of it is just reformatting :( > > >Can't we really go without white space changes and renaming of > > >parameters\local vars??? > > Its definitely much less than the half of the patch. > > > > > > > >Kind request: could you please describe shortly what is done in TM - > > which >essential changes & enhancements? > > > > I think a lot of people are interested in answer to this question. Do > > you? Let me get a break and I will come up with details > > Right, it seems like invocation API patch does extensive changes to > the TM design and interfaces. Hopefully you can provide us with a > summary why it was done > so. Sure! > In the meantime, there are a few things I'd like to understand > first (I didn't > look through the whole patch yet though): > > (1) > Why did you have to add JavaVM to jthread_create and jthread_attach > functions? I couldn't see the use for JavaVM in the TM code, except putting it > into TLS which c
Re: [general] jre and hdk snapshots posted to general snapshot site
Some times ago we discussed (and agreed?) that the HDK should include tests (also as support.jar which already included) and issue 984 was filed to build test.jar. It will nice if test.jar will be added to the new version of HDK :) Thanks, Vladimir On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: They are at the regular place http://people.apache.org/dist/incubator/harmony/snapshots I moved all the old classlib snapshots into /old and I'll update the website accordingly. I'll be automating this. Also, lets not make much noise about this for a little while so we can test to make sure there's no major errors. Things seem good. I have a list of more things to fix, but I realized today that I was obsessing over the snapshot contents - it's not a release, and it's "good enough". I'd like to ditch both /old and the remaining classlib snapshots, as 1) they are snapshots - history doesn't matter 2) the classlib is now in the HDK, so we just need to adjust the docs to match. I'll do the latter, but wanted to see if anyone has a problem w/ me removing /old and the last classlib snapshot. I'll do this if I don't hear any protest, so either positively acknowledge this action if you support it, dont' do a thing if you support or dont' care, or say why we shouldn't :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][test] "fail" statements omitted in many exception catching test cases
Hi All,
In our unit test of classlib, there are huge number of test cases about
exception catching. The typical style of those cases is like that:
try {
someStatementShouldThrowAnException;
* fail("Expected an exception");*
} catch (SomeException e){
// Expected
}
If we omit the "fail" statement, the test case is wrong because the
exception-throwing checking is disabled.
I've found that the "fail" statement is omitted in many test cases of our
Harmony classlib. So I set some rules to find out all lines of code related
with it. If a line of code comform all the 5 rules, it may be a bug:
1.in a "*Test.java" file
2.does not start with "//"
3.contains "catch"
4.its previous line does not contains "fail"
5.its next line contains "//" or "}"
Then I found out 1711 lines of code in 309 files comform all the 5 rules in
r450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are not of above
style.
And I also find out some real bugs, we can fix them easilly:
trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:652\658\664\670\676\685\698\704\711(line
number)
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTest.java:57
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileInputStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileOutputStreamTest.java:35
..
*I must say frankly that it's hard to find out all bugs of this kind without
any "victims" automatically, we must find out real bugs ourselves.*
Hope the result in attachment file can help us to find out more bugs.
Anybody has better search rules or better solution to find out those bugs? Pls.
share with us, thanks a lot.
--
Robert Hu
China Software Development Lab, IBM
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarFileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\DeflaterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\DeflaterTest.java:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\1099\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipFileTest.java:67\291
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipInputStreamTest.java:200
.\auth\src\test\java\common\javax\security\auth\callback\ConfirmationCallbackTest.java:60\147
.\auth\src\test\java\common\javax\security\auth\callback\LanguageCallbackTest.java:60
.\auth\src\test\java\common\javax\security\auth\kerberos\ServicePermissionTest.java:302
.\auth\src\test\java\common\javax\security\auth\PolicyTest.java:132
.\auth\src\test\java\common\javax\security\auth\PrivateCredentialPermissionTest.java:267\386
.\auth\src\test\java\common\javax\security\auth\SubjectTest.java:239\248\257\269\992\1109\1301\1314\1423\1851\2049\2061\2089\2101\2127\2139
.\auth\src\test\java\common\javax\security\auth\x500\X500PrincipalTest.java:2404
.\auth\src\test\java\common\javax\security\auth\x500\X500PrivateCredentialTest.java:169\179\189
.\auth\src\test\java\common\org\apache\harmony\auth\internal\SecurityTest.java:807\855\950\971\987\995\1003\1011\1065\1089\1090\1101\1116\1125\1133\1141\1142\1151\1152\1161\1162
.\auth\src\test\java\common\org\apache\harmony\auth\login\DefaultConfigParserTest.java:79\182
.\awt\src\test\api\java\common\java\awt\color\ICC_ProfileRTest.java:37
.\awt\src\test\api\java\common\java\awt\ComponentTest.java:751
.\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:652\658\664\670\676\685\698\704\711
.\awt\src\test\api\java\windows\org\apache\harmony\awt\tests\java\awt\WinFontTest.java:427
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextServicesSupportTest.java:739
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextSupportTest.java:234\251\1388
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\IntrospectorTest.java:1266\1304
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\StatementTest.java:93
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLDecoderTest.java:92
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLEncoderTest.java:334
.\concurrent\standard\src\test\java\AbstractExecutorServiceTest.java:215\235\253\306\311\340\341\353\389\403\418\436\454\473\488\521\541\562\578\595\610\628\646\665\680\697\730\750\771
.\concurrent\standard\src\test\java\AbstractQueuedSynchronizerTest.java:76\92\162\365\514\531\631\645\660\677\692\709\724\741\756\976\1007\1039\1236\1260
.\concurrent\standard\src\test\java\AbstractQueueTest.java:62\74\94\115\128\140\154\169\183
.\concurrent\standard\src\test\java\ArrayBlockingQueueTest.java:53\64\76\90\104\162\173\196\209\22
