Re: [drlvm] [launcher] Executable hangs
What is the kernel version BTW? There could be some issues with 2.4.x, currently everybody works with 2.6.x 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. hm, gdb .. did you 'export' LD_LIBRARY_PATH? (sorry for the dummy question:) 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/enhanced/drlvm/trunk/build/deploy/jre > > > > I am using Gentoo Linux. Any ideas? > > > Thanks, > > Armand > > > > Gregory Shimansky wrote: > >> On Friday 22 September 2006 14:31 Egor Pasko wrote: > >> > >>> what makes me really nervous is that I cannot debug in GDB on Linux > >>> (!) > >>> > >>> When GDB starts, it becomes broken right after the start: > >>> [New Thread 1080397952 (LWP 13879)] > >>> [New Thread 1083603888 (LWP 13882)] > >>> Cannot find user-level thread for LWP 13879: generic error > >>> > >>> Did anybody come across this problem recently? I googled a > >>> little, but > >>> could not find any valuable comments. I remember, there was no such > >>> problem in older days!! Is that our new ThreadManager that does > >>> things > >>> like this? or is it something else? > >>> > >> > >> I've seen in another thread. The problem with gdb is caused > >> because process > >> reexecs itself with new environment (there is no other way known > >> to tell > >> dynamic linker to use a library path). This is new launcher > >> feature necessary > >> to get rid of java shell script and use a real executable. > >> > >> Ivan Volosyuk investigated the conditions when launcher performs > >> execing > >> itself to set LD_LIBRARY_PATH and it appears (unless fixed > >> recently) that you > >> need to set LD_LIBRARY_PATH=/bin/:/bin/ > >> default. Don't > >> forget a tailing slash in the first path :) > >> > >> Anyway, to get the correct LD_LIBRARY_PATH which launcher wants > >> you can get it > >> from /proc/`pidof java`/environ if you launch a simple java > >> program and catch > >> its reexeced environment. If LD_LIBRARY_PATH contents is equal to > >> what > >> launcher wants, reexecing doesn't happen and this allows normal > >> debugging. > >> > >> I think we should document this since it is going to stay for a > >> long time and > >> is really required for development on Linux. > >> > >> > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Egor Pasko, Intel Managed Runtime Division --
Re: [drlvm] my latest round of patches broke something
OK. It looks like somebody already added the directories. My apologies for wasting 2 hours of Rana and Evgueni's time on IM on this... On 9/25/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: I am able to add thread.c but able to commit it. I get: Adding APR\threadproc svn: Commit failed (details follow): svn: MKCOL of '/repos/asf/!svn/wrk/bbfafe9d-10ff-d74c-b9e0-85d8767d721d/incubato r/harmony/enhanced/drlvm/trunk/build/patches/win/APR/threadproc': 405 Method Not Allowed (https://svn.apache.org) Does anyone know why svn is rejecting this commit? On 9/25/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: > > On 9/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > > > > Vladimir Gorr wrote: > > > On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: > > >> > > >> > > >> > > >> On 9/25/06, Geir Magnusson Jr. < [EMAIL PROTECTED]> wrote: > > >> > > > >> > Under what platfrom, what build? > > >> > > >> > > >> On Windows for build I've built from the latest sources (at 449592 > > >> revision). > > >> > > > > > > Sorry I was mistaken :-(. JAVA_HOME refers to RI and therefore all > works. > > > > So just to make this perfectly clear : > > > > 1) the code in SVN is ok > Geir, any simple application fails for me on Windows as well. It seems > we really miss patches/win/APR/threadproc/win32/thread.c. Could you > put it in? > > > 2) the problem was because JAVA_HOME was pointing to the RI > I believe when Vladimir was talking about JAVA_HOME it was related to > ActiveMQ application only. > > Evgueni > > > 3) we should ignore the patch you inlined in the message before this > one > > > > geir > > > > > > > > Thanks, > > > Vladimir. > > > > > > Thanks, > > >> Vladimir. > > >> > > >> On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: > > >> > > > >> > > BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. > > >> > > > > >> > > Thanks, > > >> > > Vladimir. > > >> > > > > >> > > On 9/25/06, Vladimir Gorr < [EMAIL PROTECTED]> wrote: > > >> > >> > > >> > >> As for me (and other people) a lot of tests fail for the > latest > > >> > >> sources > > >> > >> (revision 449592). > > >> > >> I've run the *build.bat clean; build.bat update; build.bat* > > >> > >> command in > > >> > >> compliance with comments for *H-1457*. > > >> > >> It's very strange for me it mentions here all C-unit tests > work > > >> fine. > > >> > > > >> > >> Sorry I cannot confirm this. > > >> > >> The detailed investigation showed the patch for *H-1457* is > > >> > >> incorrect. > > >> > >> I've attached a patch fixing this issue. > > >> > >> Thanks Evgueni Brevnov for preparing this patch. After > applying > > >> these > > >> > > > >> > >> changes the issue disappeared. > > >> > >> > > >> > >> Geir, could you please look at this patch and apply it if > there > > >> > >> are no > > >> > >> objections? > > >> > >> > > >> > >> Thanks in advance, > > >> > >> Vladimir. > > >> > >> > > >> > >> On 9/24/06, Geir Magnusson Jr. < [EMAIL PROTECTED]> wrote: > > >> > >> > > > >> > >> > Ok, I'm not as worried - I went back a few days to r447025 > and > > >> > >> still > > >> > >> > have the problem, so it's not from this morning. I guess > this has > > >> > >> > been masked all along by the logger problem. Noted in JIRA > > >> > >> HARMONY-1560 > > >> > >> > > > >> > >> > geir > > >> > >> > > > >> > >> > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: > > >> > >> > > > >> > >> > > This is completely my fault. > > >> > >> > > > > >> > >> > > The latest round of patches, while I dutifully do smoke, > c- > > >> > >> unit and > > >> > >> > > kernel tests for each patch, I didn't do any app testing. > > >> > >> > > > > >> > >> > > I tried to run ActiveMQ, and it breaks with an asset in > > >> > >> > > object_handles.cpp : 99 > > >> > >> > > > > >> > >> > > I'm going to back out the two GC patches I applied and > hope > > >> > >> for the > > >> > >> > > best. > > >> > >> > > > > >> > >> > > 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: >
Re: [testing] HARMONY-995: adding new target to builds for automatic testing
On 9/26/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Sep 25, 2006, at 6:49 AM, Vladimir Ivanov wrote: > On 9/25/06, Geir Magnusson Jr. < [EMAIL PROTECTED]> wrote: >> >> >> On Sep 25, 2006, at 5:05 AM, Vladimir Ivanov wrote: >> > Actually, now 3 targets should be called one-by-one (4 in case of > vm) to > reproduce development cycle. > Of cause, "external tool" can do it but it is seems more reasonable > to have > this command in the build. I see what you mean. I don't agree. The nice thing about having the external tool, is that the external tool can report on which phase broke. By calling an "ubertarget" that does everything, all it knows is that the ubertarget failed. For example, if you know that the tests failed, the system could examine the svn log between the time that the tests passed, and the time they failed, and send a note to developers giving them a hint of what changed to help find out what went wrong. If sophisticated enough, it could just figure it out from stack trace, and mail the responsible developer directly :) In the case when we have one target the building strategy defined by build. It just do step-by-step and report failure if any step failed (and stop to wait fix). So we have one 'event' for one module - "ws updated" and after it we should test these changes (that includes update, build and test). If any phase failed no need to do other. It works for each project while project and tests placed in the one ws. The external tool may implement some build sequences but seems it should be defined be build itself. 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: http://www.atlassian.com/ >> > software/jira >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: 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] Trouble Building DRLVM
On the 0x1F0 day of Apache Harmony Geir Magnusson, Jr. wrote: > On Sep 25, 2006, at 11:16 PM, Egor Pasko wrote: > > > On the 0x1F0 day of Apache Harmony Gregory Shimansky wrote: > >> On Friday 22 September 2006 14:31 Egor Pasko wrote: > >>> what makes me really nervous is that I cannot debug in GDB on Linux > >>> (!) > >>> > >>> When GDB starts, it becomes broken right after the start: > >>> [New Thread 1080397952 (LWP 13879)] > >>> [New Thread 1083603888 (LWP 13882)] > >>> Cannot find user-level thread for LWP 13879: generic error > >>> > >>> Did anybody come across this problem recently? I googled a > >>> little, but > >>> could not find any valuable comments. I remember, there was no such > >>> problem in older days!! Is that our new ThreadManager that does > >>> things > >>> like this? or is it something else? > >> > >> I've seen in another thread. The problem with gdb is caused > >> because process > >> reexecs itself with new environment (there is no other way known > >> to tell > >> dynamic linker to use a library path). This is new launcher > >> feature necessary > >> to get rid of java shell script and use a real executable. > >> > >> Ivan Volosyuk investigated the conditions when launcher performs > >> execing > >> itself to set LD_LIBRARY_PATH and it appears (unless fixed > >> recently) that you > >> need to set LD_LIBRARY_PATH=/bin/:/bin/ > >> default. Don't > >> forget a tailing slash in the first path :) > >> > >> Anyway, to get the correct LD_LIBRARY_PATH which launcher wants > >> you can get it > >> from /proc/`pidof java`/environ if you launch a simple java > >> program and catch > >> its reexeced environment. If LD_LIBRARY_PATH contents is equal to > >> what > >> launcher wants, reexecing doesn't happen and this allows normal > >> debugging. > > > > Thanks, Gregory! I saw Ivan's resolution and appreciate his work. > > Tried > > that yesterday, and it worked. Great! > > > >> I think we should document this since it is going to stay for a > >> long time and > >> is really required for development on Linux. > > > > +1 (!!) we need to document this. BTW, I have my own collection of GDB > > tricks that could be useful when debugging. Some of them significantly > > help me from time to time. I would like to contribute them to Harmony. > > > > I would suggest to make a special HOWTO or "Getting Started" for > > DRLVM's Linux debugging. It might seem too specific, but we have a lot > > to tell here, and, IMHO, this is a strong reason to make a separate > > doc. > > > > How to document? My ideas: > > * start from Wiki, when it matures, move to the website > > * make a JIRA with a patch introducing a new, text-only documentation > > file, like README > > * start JIRA with exact patch to the website (probably, it is not the > > easiest way, though, Nadya has a HOWTO for that) > > > > Any suggestions? > > JIRAs or Wiki - either one so we can capture and put on website. It > think that FAQs are useful for this - we can organize by topic... FAQ is a good idea. I'll try it. -- 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] my latest round of patches broke something
I am able to add thread.c but able to commit it. I get: Adding APR\threadproc svn: Commit failed (details follow): svn: MKCOL of '/repos/asf/!svn/wrk/bbfafe9d-10ff-d74c-b9e0-85d8767d721d/incubato r/harmony/enhanced/drlvm/trunk/build/patches/win/APR/threadproc': 405 Method Not Allowed (https://svn.apache.org) Does anyone know why svn is rejecting this commit? On 9/25/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: On 9/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > Vladimir Gorr wrote: > > On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: > >> > >> > >> > >> On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> > > >> > Under what platfrom, what build? > >> > >> > >> On Windows for build I've built from the latest sources (at 449592 > >> revision). > >> > > > > Sorry I was mistaken :-(. JAVA_HOME refers to RI and therefore all works. > > So just to make this perfectly clear : > > 1) the code in SVN is ok Geir, any simple application fails for me on Windows as well. It seems we really miss patches/win/APR/threadproc/win32/thread.c. Could you put it in? > 2) the problem was because JAVA_HOME was pointing to the RI I believe when Vladimir was talking about JAVA_HOME it was related to ActiveMQ application only. Evgueni > 3) we should ignore the patch you inlined in the message before this one > > geir > > > > > Thanks, > > Vladimir. > > > > Thanks, > >> Vladimir. > >> > >> On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: > >> > > >> > > BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. > >> > > > >> > > Thanks, > >> > > Vladimir. > >> > > > >> > > On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: > >> > >> > >> > >> As for me (and other people) a lot of tests fail for the latest > >> > >> sources > >> > >> (revision 449592). > >> > >> I've run the *build.bat clean; build.bat update; build.bat* > >> > >> command in > >> > >> compliance with comments for *H-1457*. > >> > >> It's very strange for me it mentions here all C-unit tests work > >> fine. > >> > > >> > >> Sorry I cannot confirm this. > >> > >> The detailed investigation showed the patch for *H-1457* is > >> > >> incorrect. > >> > >> I've attached a patch fixing this issue. > >> > >> Thanks Evgueni Brevnov for preparing this patch. After applying > >> these > >> > > >> > >> changes the issue disappeared. > >> > >> > >> > >> Geir, could you please look at this patch and apply it if there > >> > >> are no > >> > >> objections? > >> > >> > >> > >> Thanks in advance, > >> > >> Vladimir. > >> > >> > >> > >> On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> > >> > > >> > >> > Ok, I'm not as worried - I went back a few days to r447025 and > >> > >> still > >> > >> > have the problem, so it's not from this morning. I guess this has > >> > >> > been masked all along by the logger problem. Noted in JIRA > >> > >> HARMONY-1560 > >> > >> > > >> > >> > geir > >> > >> > > >> > >> > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: > >> > >> > > >> > >> > > This is completely my fault. > >> > >> > > > >> > >> > > The latest round of patches, while I dutifully do smoke, c- > >> > >> unit and > >> > >> > > kernel tests for each patch, I didn't do any app testing. > >> > >> > > > >> > >> > > I tried to run ActiveMQ, and it breaks with an asset in > >> > >> > > object_handles.cpp : 99 > >> > >> > > > >> > >> > > I'm going to back out the two GC patches I applied and hope > >> > >> for the > >> > >> > > best. > >> > >> > > > >> > >> > > 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: [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-
Re: [drlvm] my latest round of patches broke something
[snip] > H-1519 may be > needed ( I suspect it is ), but we can look at it after the first > two fixes > have gone in? Look away The H-1519 spotted major issue, committed patch to APR thread_cond* certainly has holes. I believe we have to fix it anyway. And the last fix suggested by Artem Aliev looks far more mature. -- Alexey [snip] - 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
> 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/enhanced/drlvm/trunk/build/deploy/jre > > I am using Gentoo Linux. Any ideas? > Thanks, > Armand > > Gregory Shimansky wrote: >> On Friday 22 September 2006 14:31 Egor Pasko wrote: >> >>> what makes me really nervous is that I cannot debug in GDB on Linux >>> (!) >>> >>> When GDB starts, it becomes broken right after the start: >>> [New Thread 1080397952 (LWP 13879)] >>> [New Thread 1083603888 (LWP 13882)] >>> Cannot find user-level thread for LWP 13879: generic error >>> >>> Did anybody come across this problem recently? I googled a >>> little, but >>> could not find any valuable comments. I remember, there was no such >>> problem in older days!! Is that our new ThreadManager that does >>> things >>> like this? or is it something else? >>> >> >> I've seen in another thread. The problem with gdb is caused >> because process >> reexecs itself with new environment (there is no other way known >> to tell >> dynamic linker to use a library path). This is new launcher >> feature necessary >> to get rid of java shell script and use a real executable. >> >> Ivan Volosyuk investigated the conditions when launcher performs >> execing >> itself to set LD_LIBRARY_PATH and it appears (unless fixed >> recently) that you >> need to set LD_LIBRARY_PATH=/bin/:/bin/ >> default. Don't >> forget a tailing slash in the first path :) >> >> Anyway, to get the correct LD_LIBRARY_PATH which launcher wants >> you can get it >> from /proc/`pidof java`/environ if you launch a simple java >> program and catch >> its reexeced environment. If LD_LIBRARY_PATH contents is equal to >> what >> launcher wants, reexecing doesn't happen and this allows normal >> debugging. >> >> I think we should document this since it is going to stay for a >> long time and >> is really required for development on Linux. >> >> > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] new "Getting Started" guides
Geir, At http://incubator.apache.org/harmony/quickhelp_users.html, There is a "download page" link to, http://incubator.apache.org/harmony/download.html which should be, http://incubator.apache.org/harmony/downloads.html -Jordan On 9/21/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]
Re: [testing] HARMONY-995: adding new target to builds for automatic testing
On Sep 25, 2006, at 6:49 AM, Vladimir Ivanov wrote: On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Sep 25, 2006, at 5:05 AM, Vladimir Ivanov wrote: > Seems, it will be convenient for automatic (or nightly) building > and testing > Harmony and, may be, newbie who want to look to "what is Harmony > today" > without documentation readingJ. > > If nobody objects I'll prepare patch. That's fine, I think, but I'm just surprised it doesn't do that now... what does it do now? Actually, now 3 targets should be called one-by-one (4 in case of vm) to reproduce development cycle. Of cause, "external tool" can do it but it is seems more reasonable to have this command in the build. I see what you mean. I don't agree. The nice thing about having the external tool, is that the external tool can report on which phase broke. By calling an "ubertarget" that does everything, all it knows is that the ubertarget failed. For example, if you know that the tests failed, the system could examine the svn log between the time that the tests passed, and the time they failed, and send a note to developers giving them a hint of what changed to help find out what went wrong. If sophisticated enough, it could just figure it out from stack trace, and mail the responsible developer directly :) 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: http://www.atlassian.com/ > software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: 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] Trouble Building DRLVM
On Sep 25, 2006, at 11:16 PM, Egor Pasko wrote: On the 0x1F0 day of Apache Harmony Gregory Shimansky wrote: On Friday 22 September 2006 14:31 Egor Pasko wrote: what makes me really nervous is that I cannot debug in GDB on Linux (!) When GDB starts, it becomes broken right after the start: [New Thread 1080397952 (LWP 13879)] [New Thread 1083603888 (LWP 13882)] Cannot find user-level thread for LWP 13879: generic error Did anybody come across this problem recently? I googled a little, but could not find any valuable comments. I remember, there was no such problem in older days!! Is that our new ThreadManager that does things like this? or is it something else? I've seen in another thread. The problem with gdb is caused because process reexecs itself with new environment (there is no other way known to tell dynamic linker to use a library path). This is new launcher feature necessary to get rid of java shell script and use a real executable. Ivan Volosyuk investigated the conditions when launcher performs execing itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you need to set LD_LIBRARY_PATH=/bin/:/bin/ default. Don't forget a tailing slash in the first path :) Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get it from /proc/`pidof java`/environ if you launch a simple java program and catch its reexeced environment. If LD_LIBRARY_PATH contents is equal to what launcher wants, reexecing doesn't happen and this allows normal debugging. Thanks, Gregory! I saw Ivan's resolution and appreciate his work. Tried that yesterday, and it worked. Great! I think we should document this since it is going to stay for a long time and is really required for development on Linux. +1 (!!) we need to document this. BTW, I have my own collection of GDB tricks that could be useful when debugging. Some of them significantly help me from time to time. I would like to contribute them to Harmony. I would suggest to make a special HOWTO or "Getting Started" for DRLVM's Linux debugging. It might seem too specific, but we have a lot to tell here, and, IMHO, this is a strong reason to make a separate doc. How to document? My ideas: * start from Wiki, when it matures, move to the website * make a JIRA with a patch introducing a new, text-only documentation file, like README * start JIRA with exact patch to the website (probably, it is not the easiest way, though, Nadya has a HOWTO for that) Any suggestions? JIRAs or Wiki - either one so we can capture and put on website. It think that FAQs are useful for this - we can organize by topic... -- 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] - 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] Trouble Building DRLVM
On Sep 25, 2006, at 9:05 PM, Armand Navabi wrote: I have been trying to follow this thread as best as possible. I apologize if this has already been addressed. Does anyone else have the problem of the executable just hanging? I know some people had this problem before, but I wasn't sure what the fix ended up being (if there was one). Here is the problem I am seeing: When I run ./java it runs fine (after I comment out the assertion on line 183 of thread_native_fat_monitor.c). That's fixed now. 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/enhanced/drlvm/trunk/build/deploy/jre I am using Gentoo Linux. Any ideas? Can you start a new thread with this - this one is getting stale Thanks, Armand Gregory Shimansky wrote: On Friday 22 September 2006 14:31 Egor Pasko wrote: what makes me really nervous is that I cannot debug in GDB on Linux (!) When GDB starts, it becomes broken right after the start: [New Thread 1080397952 (LWP 13879)] [New Thread 1083603888 (LWP 13882)] Cannot find user-level thread for LWP 13879: generic error Did anybody come across this problem recently? I googled a little, but could not find any valuable comments. I remember, there was no such problem in older days!! Is that our new ThreadManager that does things like this? or is it something else? I've seen in another thread. The problem with gdb is caused because process reexecs itself with new environment (there is no other way known to tell dynamic linker to use a library path). This is new launcher feature necessary to get rid of java shell script and use a real executable. Ivan Volosyuk investigated the conditions when launcher performs execing itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you need to set LD_LIBRARY_PATH=/bin/:/bin/ default. Don't forget a tailing slash in the first path :) Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get it from /proc/`pidof java`/environ if you launch a simple java program and catch its reexeced environment. If LD_LIBRARY_PATH contents is equal to what launcher wants, reexecing doesn't happen and this allows normal debugging. I think we should document this since it is going to stay for a long time and is really required for development on Linux. - 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] Trouble Building DRLVM
submit a FAQ patch to JIRA under "website". Just put a question and answer in the body of the JIRA, and we'll do the rest. geir On Sep 25, 2006, at 7:27 PM, Gregory Shimansky wrote: On Friday 22 September 2006 14:31 Egor Pasko wrote: what makes me really nervous is that I cannot debug in GDB on Linux (!) When GDB starts, it becomes broken right after the start: [New Thread 1080397952 (LWP 13879)] [New Thread 1083603888 (LWP 13882)] Cannot find user-level thread for LWP 13879: generic error Did anybody come across this problem recently? I googled a little, but could not find any valuable comments. I remember, there was no such problem in older days!! Is that our new ThreadManager that does things like this? or is it something else? I've seen in another thread. The problem with gdb is caused because process reexecs itself with new environment (there is no other way known to tell dynamic linker to use a library path). This is new launcher feature necessary to get rid of java shell script and use a real executable. Ivan Volosyuk investigated the conditions when launcher performs execing itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you need to set LD_LIBRARY_PATH=/bin/:/bin/default. Don't forget a tailing slash in the first path :) Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get it from /proc/`pidof java`/environ if you launch a simple java program and catch its reexeced environment. If LD_LIBRARY_PATH contents is equal to what launcher wants, reexecing doesn't happen and this allows normal debugging. I think we should document this since it is going to stay for a long time and is really required for development on Linux. -- 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] my latest round of patches broke something
On Sep 26, 2006, at 12:25 AM, Vladimir Gorr wrote: On 9/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Vladimir Gorr wrote: > On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: >> >> >> >> On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> > >> > Under what platfrom, what build? >> >> >> On Windows for build I've built from the latest sources (at 449592 >> revision). >> > > Sorry I was mistaken :-(. JAVA_HOME refers to RI and therefore all works. So just to make this perfectly clear : 1) the code in SVN is ok What about *patches/win/APR/threadproc/win32/thread.c* file? Done 2) the problem was because JAVA_HOME was pointing to the RI Absolutely. 3) we should ignore the patch you inlined in the message before this one I'm not sure. This patch eliminates a lot of test failures as I mentioned before (BTW you also commented on same issue into H-1457). Do we want to live with this? And one more note is our patch is not related with eliminating the ActiveMQ crash. It's another story. I wasn't arguing, I was trying to figure out what you were saying, because it seemed like once you did a clean rebuild, all was ok. Now I'll assume that all was *not* ok. I just added thread.c. My fault - I overlooked it. Sorry. Thanks, Vladimir. geir > > Thanks, > Vladimir. > > Thanks, >> Vladimir. >> >> On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: >> > >> > > BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. >> > > >> > > Thanks, >> > > Vladimir. >> > > >> > > On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: >> > >> >> > >> As for me (and other people) a lot of tests fail for the latest >> > >> sources >> > >> (revision 449592). >> > >> I've run the *build.bat clean; build.bat update; build.bat* >> > >> command in >> > >> compliance with comments for *H-1457*. >> > >> It's very strange for me it mentions here all C-unit tests work >> fine. >> > >> > >> Sorry I cannot confirm this. >> > >> The detailed investigation showed the patch for *H-1457* is >> > >> incorrect. >> > >> I've attached a patch fixing this issue. >> > >> Thanks Evgueni Brevnov for preparing this patch. After applying >> these >> > >> > >> changes the issue disappeared. >> > >> >> > >> Geir, could you please look at this patch and apply it if there >> > >> are no >> > >> objections? >> > >> >> > >> Thanks in advance, >> > >> Vladimir. >> > >> >> > >> On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> > >> > >> > >> > Ok, I'm not as worried - I went back a few days to r447025 and >> > >> still >> > >> > have the problem, so it's not from this morning. I guess this has >> > >> > been masked all along by the logger problem. Noted in JIRA >> > >> HARMONY-1560 >> > >> > >> > >> > geir >> > >> > >> > >> > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: >> > >> > >> > >> > > This is completely my fault. >> > >> > > >> > >> > > The latest round of patches, while I dutifully do smoke, c- >> > >> unit and >> > >> > > kernel tests for each patch, I didn't do any app testing. >> > >> > > >> > >> > > I tried to run ActiveMQ, and it breaks with an asset in >> > >> > > object_handles.cpp : 99 >> > >> > > >> > >> > > I'm going to back out the two GC patches I applied and hope >> > >> for the >> > >> > > best. >> > >> > > >> > >> > > 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: [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: [drlvm] my latest round of patches broke something
On Sep 25, 2006, at 5:07 PM, Rana Dasgupta wrote: Hi Weldon/Geir, Looks like we have quite a few Windows failures. Could one of you folks please add in the the new file: patches/win/APR/threadproc/win32/thread.c that is in 1457, but possibly got dropped from the commit? Possibly? Most definitely! So sorry. I was a bonehead. We also need H-1340 to fix the assert in the fat monitor. Done H-1519 may be needed ( I suspect it is ), but we can look at it after the first two fixes have gone in? Look away Thanks, Rana On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: On 9/25/06, Ilya Berezhniuk < [EMAIL PROTECTED]> wrote: > > Geir, Vladimir, > > I've returned from vacation today, so my 2 cents to this discussion... > > I guess the problem have appeared because in r449399 the changes for > win/apr_thread_ext.c > were committed, but new file patches/win/APR/threadproc/win32/ thread.c was > not committed. These changes are work together. > > The patch suggested by Vladimir will not fix issue completely. Maybe you are right. However I'd advise not to ignore our changes. In our opinion they are also useful. I see this patch eliminates a lot of test failures we have now on Windows. BTW Rana mentions about this as well. Thanks, Vladimir. I cannot provide a test for issue I have fixed (I can't understand how to > create it), > but it's quite enough to uncomment debug printing in > apr_thread_yield_other() > function to view differences on any simple Java application. > > 2006/9/25, Vladimir Gorr <[EMAIL PROTECTED] >: > > > > On 9/25/06, Geir Magnusson Jr. < [EMAIL PROTECTED]> wrote: > > > > > > > > > On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: > > > > > > > As for me (and other people) a lot of tests fail for the latest > > > > sources (revision 449592). > > > > I've run the build.bat clean; build.bat update; build.bat command > > > > in compliance with comments for H-1457. > > > > It's very strange for me it mentions here all C-unit tests work > > > > fine. Sorry I cannot confirm this. > > > > > > It certainly did on my machine after a clean - update build, and then > > > hung on gc.LOS. > > > > > > Under what platform? This problem exists only for Windows. > > > > Thanks, > > Vladimir. > > > > > The detailed investigation showed the patch for H-1457 is > > > > incorrect. I've attached a patch fixing this issue. > > > > Thanks Evgueni Brevnov for preparing this patch. After applying > > > > these changes the issue disappeared. > > > > > > Where is that patch? it didn't make it through to list - can you > > > just re-open 1457 and attach there? > > > > > > > > > > > Geir, could you please look at this patch and apply it if there are > > > > no objections? > > > > > > > > Thanks in advance, > > > > Vladimir. > > > > > > > > On 9/24/06, Geir Magnusson Jr. < [EMAIL PROTECTED]> wrote: Ok, I'm not > > > > as worried - I went back a few days to r447025 and still > > > > have the problem, so it's not from this morning. I guess this has > > > > been masked all along by the logger problem. Noted in JIRA > > > > HARMONY-1560 > > > > > > > > geir > > > > > > > > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: > > > > > > > > > This is completely my fault. > > > > > > > > > > The latest round of patches, while I dutifully do smoke, c-unit > and > > > > > kernel tests for each patch, I didn't do any app testing. > > > > > > > > > > I tried to run ActiveMQ, and it breaks with an asset in > > > > > object_handles.cpp : 99 > > > > > > > > > > I'm going to back out the two GC patches I applied and hope for > the > > > > > best. > > > > > > > > > > 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] > > > > > > > > > > > > > - > > > > 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: harmony-dev- [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > - Terms of use : http://incu
Re: [drlvm] Please integrate HARMONY -1340.
Done On Sep 25, 2006, at 12:40 PM, Artem Aliev wrote: Committers, Could you please integrate fix from: HARMONY -1340 Fix invalid assertion in thread_native_fat_monitor.c The patch is trivial. The assertion in the current code is incorrect, it check that monitor is entered not more then once (recursion_count < 1) It was left in the code by mistake. The monitor recursion count could be any positive number (the number of nested monitorEnter calls). This assert happend quite often: in self hosting mode, and always on EM64T. Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
On 9/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Vladimir Gorr wrote: > On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: >> >> >> >> On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> > >> > Under what platfrom, what build? >> >> >> On Windows for build I've built from the latest sources (at 449592 >> revision). >> > > Sorry I was mistaken :-(. JAVA_HOME refers to RI and therefore all works. So just to make this perfectly clear : 1) the code in SVN is ok What about *patches/win/APR/threadproc/win32/thread.c* file? 2) the problem was because JAVA_HOME was pointing to the RI Absolutely. 3) we should ignore the patch you inlined in the message before this one I'm not sure. This patch eliminates a lot of test failures as I mentioned before (BTW you also commented on same issue into H-1457). Do we want to live with this? And one more note is our patch is not related with eliminating the ActiveMQ crash. It's another story. Thanks, Vladimir. geir > > Thanks, > Vladimir. > > Thanks, >> Vladimir. >> >> On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: >> > >> > > BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. >> > > >> > > Thanks, >> > > Vladimir. >> > > >> > > On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: >> > >> >> > >> As for me (and other people) a lot of tests fail for the latest >> > >> sources >> > >> (revision 449592). >> > >> I've run the *build.bat clean; build.bat update; build.bat* >> > >> command in >> > >> compliance with comments for *H-1457*. >> > >> It's very strange for me it mentions here all C-unit tests work >> fine. >> > >> > >> Sorry I cannot confirm this. >> > >> The detailed investigation showed the patch for *H-1457* is >> > >> incorrect. >> > >> I've attached a patch fixing this issue. >> > >> Thanks Evgueni Brevnov for preparing this patch. After applying >> these >> > >> > >> changes the issue disappeared. >> > >> >> > >> Geir, could you please look at this patch and apply it if there >> > >> are no >> > >> objections? >> > >> >> > >> Thanks in advance, >> > >> Vladimir. >> > >> >> > >> On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> > >> > >> > >> > Ok, I'm not as worried - I went back a few days to r447025 and >> > >> still >> > >> > have the problem, so it's not from this morning. I guess this has >> > >> > been masked all along by the logger problem. Noted in JIRA >> > >> HARMONY-1560 >> > >> > >> > >> > geir >> > >> > >> > >> > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: >> > >> > >> > >> > > This is completely my fault. >> > >> > > >> > >> > > The latest round of patches, while I dutifully do smoke, c- >> > >> unit and >> > >> > > kernel tests for each patch, I didn't do any app testing. >> > >> > > >> > >> > > I tried to run ActiveMQ, and it breaks with an asset in >> > >> > > object_handles.cpp : 99 >> > >> > > >> > >> > > I'm going to back out the two GC patches I applied and hope >> > >> for the >> > >> > > best. >> > >> > > >> > >> > > 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: [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] my latest round of patches broke something
On 9/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Vladimir Gorr wrote: > On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: >> >> >> >> On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> > >> > Under what platfrom, what build? >> >> >> On Windows for build I've built from the latest sources (at 449592 >> revision). >> > > Sorry I was mistaken :-(. JAVA_HOME refers to RI and therefore all works. So just to make this perfectly clear : 1) the code in SVN is ok Geir, any simple application fails for me on Windows as well. It seems we really miss patches/win/APR/threadproc/win32/thread.c. Could you put it in? 2) the problem was because JAVA_HOME was pointing to the RI I believe when Vladimir was talking about JAVA_HOME it was related to ActiveMQ application only. Evgueni 3) we should ignore the patch you inlined in the message before this one geir > > Thanks, > Vladimir. > > Thanks, >> Vladimir. >> >> On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: >> > >> > > BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. >> > > >> > > Thanks, >> > > Vladimir. >> > > >> > > On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: >> > >> >> > >> As for me (and other people) a lot of tests fail for the latest >> > >> sources >> > >> (revision 449592). >> > >> I've run the *build.bat clean; build.bat update; build.bat* >> > >> command in >> > >> compliance with comments for *H-1457*. >> > >> It's very strange for me it mentions here all C-unit tests work >> fine. >> > >> > >> Sorry I cannot confirm this. >> > >> The detailed investigation showed the patch for *H-1457* is >> > >> incorrect. >> > >> I've attached a patch fixing this issue. >> > >> Thanks Evgueni Brevnov for preparing this patch. After applying >> these >> > >> > >> changes the issue disappeared. >> > >> >> > >> Geir, could you please look at this patch and apply it if there >> > >> are no >> > >> objections? >> > >> >> > >> Thanks in advance, >> > >> Vladimir. >> > >> >> > >> On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> > >> > >> > >> > Ok, I'm not as worried - I went back a few days to r447025 and >> > >> still >> > >> > have the problem, so it's not from this morning. I guess this has >> > >> > been masked all along by the logger problem. Noted in JIRA >> > >> HARMONY-1560 >> > >> > >> > >> > geir >> > >> > >> > >> > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: >> > >> > >> > >> > > This is completely my fault. >> > >> > > >> > >> > > The latest round of patches, while I dutifully do smoke, c- >> > >> unit and >> > >> > > kernel tests for each patch, I didn't do any app testing. >> > >> > > >> > >> > > I tried to run ActiveMQ, and it breaks with an asset in >> > >> > > object_handles.cpp : 99 >> > >> > > >> > >> > > I'm going to back out the two GC patches I applied and hope >> > >> for the >> > >> > > best. >> > >> > > >> > >> > > 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: [EMAIL PROTECTED] >> > >> > >> > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On the 0x1F0 day of Apache Harmony Gregory Shimansky wrote: > On Friday 22 September 2006 14:31 Egor Pasko wrote: > > what makes me really nervous is that I cannot debug in GDB on Linux > > (!) > > > > When GDB starts, it becomes broken right after the start: > > [New Thread 1080397952 (LWP 13879)] > > [New Thread 1083603888 (LWP 13882)] > > Cannot find user-level thread for LWP 13879: generic error > > > > Did anybody come across this problem recently? I googled a little, but > > could not find any valuable comments. I remember, there was no such > > problem in older days!! Is that our new ThreadManager that does things > > like this? or is it something else? > > I've seen in another thread. The problem with gdb is caused because process > reexecs itself with new environment (there is no other way known to tell > dynamic linker to use a library path). This is new launcher feature necessary > to get rid of java shell script and use a real executable. > > Ivan Volosyuk investigated the conditions when launcher performs execing > itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you > need to set LD_LIBRARY_PATH=/bin/:/bin/default. Don't > forget a tailing slash in the first path :) > > Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get > it > from /proc/`pidof java`/environ if you launch a simple java program and catch > its reexeced environment. If LD_LIBRARY_PATH contents is equal to what > launcher wants, reexecing doesn't happen and this allows normal debugging. Thanks, Gregory! I saw Ivan's resolution and appreciate his work. Tried that yesterday, and it worked. Great! > I think we should document this since it is going to stay for a long time and > is really required for development on Linux. +1 (!!) we need to document this. BTW, I have my own collection of GDB tricks that could be useful when debugging. Some of them significantly help me from time to time. I would like to contribute them to Harmony. I would suggest to make a special HOWTO or "Getting Started" for DRLVM's Linux debugging. It might seem too specific, but we have a lot to tell here, and, IMHO, this is a strong reason to make a separate doc. How to document? My ideas: * start from Wiki, when it matures, move to the website * make a JIRA with a patch introducing a new, text-only documentation file, like README * start JIRA with exact patch to the website (probably, it is not the easiest way, though, Nadya has a HOWTO for that) Any suggestions? -- 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: [classlib][awt] Fonts with negative size.
Agree. We may follow Java 6.0 Spec. Richard. On 9/25/06, Ilya Okomin <[EMAIL PROTECTED]> wrote: Guys, I found something in the Java 6.0 documentation. If you look at the TextAttribute spec there is a note for the SIZE field, attribute key for the font size: "Attribute key for the font size. Values are instances of *Number*. The default value is 12pt. This corresponds to the size parameter to the Font constructor. Very large or small sizes will impact rendering performance, and the rendering system might not render text at these sizes. *Negative sizes are illegal and result in the default size*." For this reason I suggest to use default size (12pt) if font has negative size parameter. Any thoughts? I believe negative-sized fonts support was erroneous in Java 5.0 and in the earlier versions of Java. Regards, Ilya. On 9/25/06, Oleg Khaschansky <[EMAIL PROTECTED]> wrote: > > It seems like returning negative metrics is somewhat logical. If the > font is rotated by -Pi then all offsets becomes negative, but their > absolute values are equal to the positive ones. > > I'll try to give an example. E.g. if descent was, say, 10 and one > needed to offset 10 pt from the origin (baseline) to the bottom of the > black box then if -pi rotation is applied to the font, one need to > offset -10 pt from the baseline since black box is upside down. > > Yes, RI failed to be consistent with this on heavyweight components as > it was noted in the evaluation. But is this bug still there in the RI? > And if RI is inconsistent with the drawing of negative-sized fonts it > is still consistent with the negative metrics, right? > > IMHO, the ideal behavior in all situations would be the following: > If the font has negative size we assume that it has all the same > metrics as the positive font, but the metrics which has a direction > (like ascent, descent, etc.) are with the different sign. The font is > drawn as it was rotated by -pi angle. > > Personaly my opinion is that this is a bug, not non-bug diff. > I'd suggest to choose between these options: > 1. Fix metrics and rendering, close this issue. > 2. Fix metrics, open a new jira for the rendering of the negative-sized > fonts. > 3. Fix nothing, open a new jira or add an evaluation to this one > both for the rendering and for the metrics. This means that we want to > have them together. > > For the rendering part, why not just add a transform if the size of > the font is negative? > > On 9/25/06, Ilya Okomin <[EMAIL PROTECTED]> wrote: > > On 9/25/06, Oleg Khaschansky <[EMAIL PROTECTED] > wrote: > > > > > It was evaluated as "not a bug". But it is clear from its evaluation > > > that negative-sized fonts are treated as positive sized but rotated > > > around their origin, say with implicit transform. I'd suggest to > > > follow this behavior. > > > > > > I agree, that the behavior of the negative-sized fonts on RI is looks > like > > the behavior of positive ones with -Pi rotation. However, if we look at > the > > font metrics, bounds - we can see negative values for height, width > > values...I'm not sure they have any sence without additional > documentation > > that we can't find in the spec. > > Moreover bug evaluation says that RI handles negative-sized fonts for > > components in different ways depending on the platform. And it's > behavior > > unlike the drawing on the frame surface. What is to add - metrics for > all > > these various cases are the same, it means that RI has erroneous > behavior in > > some way. > > > > I would suggest not to follow the RI and mark it as "non-bug difference" > as > > the RI hasn't any clear documentation on this problem and it's > > behavior erroneous and depends on the platform or component type. > > > > Thanks, > > Ilya. > > > > > > > > > > > On 9/23/06, Richard Liang < [EMAIL PROTECTED]> wrote: > > > > On 9/23/06, Alexey Varlamov <[EMAIL PROTECTED] > wrote: > > > > > Google said this is the bug of RI in progress [1]. However there > is no > > > > > distinct resolution yet... > > > > > > > > > > > > > It's reported again Java 1.1.8 more than 3 years agao. I don't think > > > > RI will fix this bug. > > > > > > > > Richard. > > > > > > > > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825 > > > > > > > > > > > > > > > 2006/9/23, Richard Liang < [EMAIL PROTECTED]>: > > > > > > On 9/22/06, Ilya Okomin < [EMAIL PROTECTED]> wrote: > > > > > > > Hi, all! > > > > > > > > > > > > > > I was playing with fonts and found that Font with negative > size > > > can be > > > > > > > created on RI. > > > > > > > Unfortunately spec keep silence about fonts with negative > sizes. > > > > > > > On Harmony if font size is negative then it is set to zero. > > > > > > > > > > > > > > test.java--- > > > > > > > import java.awt.*; > > > > > > > import java.awt.font.FontRenderContext; > > > > > > > > > > > > > > public class NegativeFontTest { > > > > > > > > > > > > > > public static void main(String[] args)
please, integrate issues 1565 and 1569
Committers, please, integrate issues 1565 and 1569. These improvements are trivial but important for 'B&T infrastructure'. Thanks, Vladimir
Re: [classlib][html] Differences with RI
Miguel Montes wrote: Hi, I fllled several JIRA issues more than three weeks ago, but they are still unassigned. (HARMONY-1272, 1349, 1350, 1395). We are working in the parser, and there are some issues that should be solved, such as the structure of ContentModel. I'd like to look at patches for 1349 and 1350 today, but 1395 is a contribution, so probably it needs Geir to raise a voting on it. And anyone interests to provide a patch for 1272? I would like to hear other people thoughts about this, particularly those from the developers of the existing javax.swing.text.html.parser code Regards Miguel Montes On 8/23/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote: I think that filing JIRA issue is right way :) 2006/8/23, Miguel Montes <[EMAIL PROTECTED]>: > Hi: > We have found several differences between Harmony's implementation of > j.s.t.h.parser and the RI. I'm not sure if these should be reported > individually as JIRA issues, or should be discussed here. > > For instance, in j.s.t.h.p.Entity, the RI. encodes isParameter and isGeneral > in the type, which is a public field, while the current implementation in > Harmony uses two boolean fields. So, the value of a public field is > different in both implementations. > > Another case: > ContentModel: > > The method first() should return the element that must be the first element > to appear in a ContentModel. If it's not unique, the RI returns null. For > instance, for the following ContentModel: > > TITLE & ISINDEX? & BASE? > > Any of those elements could appear at the beggining of a valid matching > expression. So, the method first should return null, because there is not a > single element that could be considered as the unique one that can appear at > the head of a matching expression. Nevertheless, for this example (as for > some others), HARMONY-948 returned a value. For this example, a BASE value > was obtained. > > There are several more. Should we post them as separate JIRA issues, o as > one big issue, with the suggeste patches? > > > -- > Miguel Montes > > -- 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] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
I have been trying to follow this thread as best as possible. I apologize if this has already been addressed. Does anyone else have the problem of the executable just hanging? I know some people had this problem before, but I wasn't sure what the fix ended up being (if there was one). Here is the problem I am seeing: When I run ./java it runs fine (after I comment out the assertion on line 183 of thread_native_fat_monitor.c). 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/enhanced/drlvm/trunk/build/deploy/jre I am using Gentoo Linux. Any ideas? Thanks, Armand Gregory Shimansky wrote: > On Friday 22 September 2006 14:31 Egor Pasko wrote: > >> what makes me really nervous is that I cannot debug in GDB on Linux >> (!) >> >> When GDB starts, it becomes broken right after the start: >> [New Thread 1080397952 (LWP 13879)] >> [New Thread 1083603888 (LWP 13882)] >> Cannot find user-level thread for LWP 13879: generic error >> >> Did anybody come across this problem recently? I googled a little, but >> could not find any valuable comments. I remember, there was no such >> problem in older days!! Is that our new ThreadManager that does things >> like this? or is it something else? >> > > I've seen in another thread. The problem with gdb is caused because process > reexecs itself with new environment (there is no other way known to tell > dynamic linker to use a library path). This is new launcher feature necessary > to get rid of java shell script and use a real executable. > > Ivan Volosyuk investigated the conditions when launcher performs execing > itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you > need to set LD_LIBRARY_PATH=/bin/:/bin/default. Don't > forget a tailing slash in the first path :) > > Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get > it > from /proc/`pidof java`/environ if you launch a simple java program and catch > its reexeced environment. If LD_LIBRARY_PATH contents is equal to what > launcher wants, reexecing doesn't happen and this allows normal debugging. > > I think we should document this since it is going to stay for a long time and > is really required for development on Linux. > > - 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] Trouble Building DRLVM
On Friday 22 September 2006 14:31 Egor Pasko wrote: > what makes me really nervous is that I cannot debug in GDB on Linux > (!) > > When GDB starts, it becomes broken right after the start: > [New Thread 1080397952 (LWP 13879)] > [New Thread 1083603888 (LWP 13882)] > Cannot find user-level thread for LWP 13879: generic error > > Did anybody come across this problem recently? I googled a little, but > could not find any valuable comments. I remember, there was no such > problem in older days!! Is that our new ThreadManager that does things > like this? or is it something else? I've seen in another thread. The problem with gdb is caused because process reexecs itself with new environment (there is no other way known to tell dynamic linker to use a library path). This is new launcher feature necessary to get rid of java shell script and use a real executable. Ivan Volosyuk investigated the conditions when launcher performs execing itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you need to set LD_LIBRARY_PATH=/bin/:/bin/default. Don't forget a tailing slash in the first path :) Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get it from /proc/`pidof java`/environ if you launch a simple java program and catch its reexeced environment. If LD_LIBRARY_PATH contents is equal to what launcher wants, reexecing doesn't happen and this allows normal debugging. I think we should document this since it is going to stay for a long time and is really required for development on Linux. -- 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] invoking non-trivial jars results in IllegalAccessError
We desperately need tests for this. Anyone want to volunteer, to even make simple ones? We can stuff into the smoke or other frameworks... geir Pavel Pervov wrote: > Chris, > > As far as I understant, this is responsibility of a class loader to parse > Class-Path attribute of any jar file it has in its class path. > System class loader for DRLVM (which is URLClassLoader) does this. > > Any objections? > > Regards, >Pavel Pervov. > Intel Middleware Products Division. > > On 9/25/06, Chris Gray <[EMAIL PROTECTED]> wrote: >> >> As I understand it, the classpath of the jarred application should >> include >> the >> jar file itself and the contents of its Class-Path attribute (if any). >> You >> probably need to create a special class loader for the application and >> use >> that whenever the application (or a library loaded by it) is the >> initiator. >> -- >> Chris Gray/k/ Embedded Java Solutions BE0503765045 >> Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ >> [EMAIL PROTECTED] +32 3 216 0369 >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
Egor Pasko wrote: >> >> If invoked with the option "-Xtrace:em", DRLVM prints compilation >> events as soon as they occur. What makes real fun is that one method >> starts compilation several times (without success) and receives >> SEGFAULT after not so many attempts. The bug may be in OPT or in >> recompilation, not clear now. Will investigate (first, I'll try to >> compile some methods with JET selectively) > > the bug is caused by OPT's incorrect compilation of method > test_getPackages_V if I move the compilation to JET, the test > passes. Investigating... > > Moving compilation of _one_ method to JET, while _others_ are compiled > with OPT *is easy*. All you have to do is put debug.emconf file to > .../jre/bin/default and run with the option -Xem:debug This is *really* cool. (Of course, I assume a patch is forthcoming to fix OPT :) We should capture this in a FAQ... geir > > debug.emconf is as follows: > > chains=chain1,chain2 > chain1.jits=JET_DEBUG > chain2.jits=CD_OPT > > chain1.filter=+::test_getPackages_V > chain1.filter=- > > JET_DEBUG.file=jitrino > CD_OPT.file=jitrino > > # Options to be passed to JIT > > -Djit.JET_DEBUG.path= > > -Djit.CD_OPT.path=opt_init,translator,optimizer,hir2lir,codegen > > -Djit.CD_OPT.path.optimizer=ssa,devirt,inline,purge,simplify,uce,dce,lazyexc,memopt,simplify,uce,dce,lower,dessa,statprof,markglobals > -Djit.CD_OPT.path.codegen=lock_method,bbp,gcpoints,cafl,dce1,i8l,early_prop,itrace-,native,constraints,dce2,regalloc,spillgen,layout,copy,rce+,stack,break-,iprof-,emitter!,si_insts,gcmap,info,unlock_method > -Djit.CD_OPT.path.dce1=cg_dce > -Djit.CD_OPT.path.dce2=cg_dce > -Djit.CD_OPT.path.regalloc=bp_regalloc1,bp_regalloc2 > -Djit.CD_OPT.path.bp_regalloc1=bp_regalloc > -Djit.CD_OPT.path.bp_regalloc2=bp_regalloc > > #inliner configuration > -Djit.CD_OPT.CD_OPT_inliner_pipeline.filter=- > -Djit.CD_OPT.CD_OPT_inliner_pipeline.path=ssa,devirt > -Djit.CD_OPT.arg.optimizer.inline.pipeline=CD_OPT_inliner_pipeline > > -Djit.CD_OPT.arg.codegen.dce1.early=yes > -Djit.CD_OPT.arg.codegen.regalloc.bp_regalloc1.regs=ALL_GP > -Djit.CD_OPT.arg.codegen.regalloc.bp_regalloc2.regs=ALL_XMM > > - 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
Salikh Zakirov wrote: >> http://incubator.apache.org/harmony/quickhelp_contributors.html > > I have a couple of comments on the contents: > > > 1. >> $ ant fetch-depends > > As I am sitting behind the firewall, I have to use > > $ ANT_OPTS='-Dhttp.proxyHost= -Dhttp.proxyPort= port>' ant fetch-depends > > to make sure ant can download dependencies using HTTP proxy. Excellent point. We'll add that. > > 2. >> As of now, you cannot build from a Cygwin or other alternative shell. > > This is not exactly the case. > - DRLVM has provisions in 'build.bat' > to set up environment using Visual Studio environment file 'vsvars32.bat' > (and friends). > > - if Visual Studio configured system environment during installation, then > both DRLVM and Classlib > can be built from any place. Have you built classlib successfully with cygwin? - 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] my latest round of patches broke something
Vladimir Gorr wrote: > On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: >> >> >> >> On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> > >> > Under what platfrom, what build? >> >> >> On Windows for build I've built from the latest sources (at 449592 >> revision). >> > > Sorry I was mistaken :-(. JAVA_HOME refers to RI and therefore all works. So just to make this perfectly clear : 1) the code in SVN is ok 2) the problem was because JAVA_HOME was pointing to the RI 3) we should ignore the patch you inlined in the message before this one geir > > Thanks, > Vladimir. > > Thanks, >> Vladimir. >> >> On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: >> > >> > > BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. >> > > >> > > Thanks, >> > > Vladimir. >> > > >> > > On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: >> > >> >> > >> As for me (and other people) a lot of tests fail for the latest >> > >> sources >> > >> (revision 449592). >> > >> I've run the *build.bat clean; build.bat update; build.bat* >> > >> command in >> > >> compliance with comments for *H-1457*. >> > >> It's very strange for me it mentions here all C-unit tests work >> fine. >> > >> > >> Sorry I cannot confirm this. >> > >> The detailed investigation showed the patch for *H-1457* is >> > >> incorrect. >> > >> I've attached a patch fixing this issue. >> > >> Thanks Evgueni Brevnov for preparing this patch. After applying >> these >> > >> > >> changes the issue disappeared. >> > >> >> > >> Geir, could you please look at this patch and apply it if there >> > >> are no >> > >> objections? >> > >> >> > >> Thanks in advance, >> > >> Vladimir. >> > >> >> > >> On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> > >> > >> > >> > Ok, I'm not as worried - I went back a few days to r447025 and >> > >> still >> > >> > have the problem, so it's not from this morning. I guess this has >> > >> > been masked all along by the logger problem. Noted in JIRA >> > >> HARMONY-1560 >> > >> > >> > >> > geir >> > >> > >> > >> > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: >> > >> > >> > >> > > This is completely my fault. >> > >> > > >> > >> > > The latest round of patches, while I dutifully do smoke, c- >> > >> unit and >> > >> > > kernel tests for each patch, I didn't do any app testing. >> > >> > > >> > >> > > I tried to run ActiveMQ, and it breaks with an asset in >> > >> > > object_handles.cpp : 99 >> > >> > > >> > >> > > I'm going to back out the two GC patches I applied and hope >> > >> for the >> > >> > > best. >> > >> > > >> > >> > > 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: [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] my latest round of patches broke something
Vladimir Gorr wrote: > On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: >> >> > As for me (and other people) a lot of tests fail for the latest >> > sources (revision 449592). >> > I've run the build.bat clean; build.bat update; build.bat command >> > in compliance with comments for H-1457. >> > It's very strange for me it mentions here all C-unit tests work >> > fine. Sorry I cannot confirm this. >> >> It certainly did on my machine after a clean - update build, and then >> hung on gc.LOS. > > > Under what platform? This problem exists only for Windows. Right - that patch was only for windows too. On WinXP, MSVC .NET 2003 geir > > Thanks, > Vladimir. > >> The detailed investigation showed the patch for H-1457 is >> > incorrect. I've attached a patch fixing this issue. >> > Thanks Evgueni Brevnov for preparing this patch. After applying >> > these changes the issue disappeared. >> >> Where is that patch? it didn't make it through to list - can you >> just re-open 1457 and attach there? >> >> > >> > Geir, could you please look at this patch and apply it if there are >> > no objections? >> > >> > Thanks in advance, >> > Vladimir. >> > >> > On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Ok, I'm not >> > as worried - I went back a few days to r447025 and still >> > have the problem, so it's not from this morning. I guess this has >> > been masked all along by the logger problem. Noted in JIRA >> > HARMONY-1560 >> > >> > geir >> > >> > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: >> > >> > > This is completely my fault. >> > > >> > > The latest round of patches, while I dutifully do smoke, c-unit and >> > > kernel tests for each patch, I didn't do any app testing. >> > > >> > > I tried to run ActiveMQ, and it breaks with an asset in >> > > object_handles.cpp : 99 >> > > >> > > I'm going to back out the two GC patches I applied and hope for the >> > > best. >> > > >> > > 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] >> > >> > >> > - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
Hi Weldon/Geir, Looks like we have quite a few Windows failures. Could one of you folks please add in the the new file: patches/win/APR/threadproc/win32/thread.c that is in 1457, but possibly got dropped from the commit? We also need H-1340 to fix the assert in the fat monitor. H-1519 may be needed ( I suspect it is ), but we can look at it after the first two fixes have gone in? Thanks, Rana On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: On 9/25/06, Ilya Berezhniuk < [EMAIL PROTECTED]> wrote: > > Geir, Vladimir, > > I've returned from vacation today, so my 2 cents to this discussion... > > I guess the problem have appeared because in r449399 the changes for > win/apr_thread_ext.c > were committed, but new file patches/win/APR/threadproc/win32/thread.c was > not committed. These changes are work together. > > The patch suggested by Vladimir will not fix issue completely. Maybe you are right. However I'd advise not to ignore our changes. In our opinion they are also useful. I see this patch eliminates a lot of test failures we have now on Windows. BTW Rana mentions about this as well. Thanks, Vladimir. I cannot provide a test for issue I have fixed (I can't understand how to > create it), > but it's quite enough to uncomment debug printing in > apr_thread_yield_other() > function to view differences on any simple Java application. > > 2006/9/25, Vladimir Gorr <[EMAIL PROTECTED] >: > > > > On 9/25/06, Geir Magnusson Jr. < [EMAIL PROTECTED]> wrote: > > > > > > > > > On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: > > > > > > > As for me (and other people) a lot of tests fail for the latest > > > > sources (revision 449592). > > > > I've run the build.bat clean; build.bat update; build.bat command > > > > in compliance with comments for H-1457. > > > > It's very strange for me it mentions here all C-unit tests work > > > > fine. Sorry I cannot confirm this. > > > > > > It certainly did on my machine after a clean - update build, and then > > > hung on gc.LOS. > > > > > > Under what platform? This problem exists only for Windows. > > > > Thanks, > > Vladimir. > > > > > The detailed investigation showed the patch for H-1457 is > > > > incorrect. I've attached a patch fixing this issue. > > > > Thanks Evgueni Brevnov for preparing this patch. After applying > > > > these changes the issue disappeared. > > > > > > Where is that patch? it didn't make it through to list - can you > > > just re-open 1457 and attach there? > > > > > > > > > > > Geir, could you please look at this patch and apply it if there are > > > > no objections? > > > > > > > > Thanks in advance, > > > > Vladimir. > > > > > > > > On 9/24/06, Geir Magnusson Jr. < [EMAIL PROTECTED]> wrote: Ok, I'm not > > > > as worried - I went back a few days to r447025 and still > > > > have the problem, so it's not from this morning. I guess this has > > > > been masked all along by the logger problem. Noted in JIRA > > > > HARMONY-1560 > > > > > > > > geir > > > > > > > > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: > > > > > > > > > This is completely my fault. > > > > > > > > > > The latest round of patches, while I dutifully do smoke, c-unit > and > > > > > kernel tests for each patch, I didn't do any app testing. > > > > > > > > > > I tried to run ActiveMQ, and it breaks with an asset in > > > > > object_handles.cpp : 99 > > > > > > > > > > I'm going to back out the two GC patches I applied and hope for > the > > > > > best. > > > > > > > > > > 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] > > > > > > > > > > > > > - > > > > 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] my latest round of patches broke something
On 9/25/06, Ilya Berezhniuk <[EMAIL PROTECTED]> wrote: Geir, Vladimir, I've returned from vacation today, so my 2 cents to this discussion... I guess the problem have appeared because in r449399 the changes for win/apr_thread_ext.c were committed, but new file patches/win/APR/threadproc/win32/thread.c was not committed. These changes are work together. The patch suggested by Vladimir will not fix issue completely. Maybe you are right. However I'd advise not to ignore our changes. In our opinion they are also useful. I see this patch eliminates a lot of test failures we have now on Windows. BTW Rana mentions about this as well. Thanks, Vladimir. I cannot provide a test for issue I have fixed (I can't understand how to create it), but it's quite enough to uncomment debug printing in apr_thread_yield_other() function to view differences on any simple Java application. 2006/9/25, Vladimir Gorr <[EMAIL PROTECTED]>: > > On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > > > On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: > > > > > As for me (and other people) a lot of tests fail for the latest > > > sources (revision 449592). > > > I've run the build.bat clean; build.bat update; build.bat command > > > in compliance with comments for H-1457. > > > It's very strange for me it mentions here all C-unit tests work > > > fine. Sorry I cannot confirm this. > > > > It certainly did on my machine after a clean - update build, and then > > hung on gc.LOS. > > > Under what platform? This problem exists only for Windows. > > Thanks, > Vladimir. > > > The detailed investigation showed the patch for H-1457 is > > > incorrect. I've attached a patch fixing this issue. > > > Thanks Evgueni Brevnov for preparing this patch. After applying > > > these changes the issue disappeared. > > > > Where is that patch? it didn't make it through to list - can you > > just re-open 1457 and attach there? > > > > > > > > Geir, could you please look at this patch and apply it if there are > > > no objections? > > > > > > Thanks in advance, > > > Vladimir. > > > > > > On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Ok, I'm not > > > as worried - I went back a few days to r447025 and still > > > have the problem, so it's not from this morning. I guess this has > > > been masked all along by the logger problem. Noted in JIRA > > > HARMONY-1560 > > > > > > geir > > > > > > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: > > > > > > > This is completely my fault. > > > > > > > > The latest round of patches, while I dutifully do smoke, c-unit and > > > > kernel tests for each patch, I didn't do any app testing. > > > > > > > > I tried to run ActiveMQ, and it breaks with an asset in > > > > object_handles.cpp : 99 > > > > > > > > I'm going to back out the two GC patches I applied and hope for the > > > > best. > > > > > > > > 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] > > > > > > > > > - > > > 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][apr] APR fails to load a JIT library when using a fully qualified path
On Monday 25 September 2006 22:38 Mikhail Fursov wrote: > Ok, I will create a new JIRA issue tomorrow (or even today, it's 2am here:) > ) and add MSVC projects for some DRLVM components. BTW absence of up to date VS.NET projects for VM is one of the reasons I don't use it for development :) Another one is that VS.NET 2003 sometimes goes into infinite loop in the source editor. This is not the case with VS.NET 2005, it also has a better debugger, but building with it is not possible ATM due to lots of changes introduced by Microsoft in 8.0. They should be fixed some day. > On 9/26/06, Gregory Shimansky <[EMAIL PROTECTED]> 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. -- 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][apr] APR fails to load a JIT library when using a fully qualified path
Ok, I will create a new JIRA issue tomorrow (or even today, it's 2am here:) ) and add MSVC projects for some DRLVM components. On 9/26/06, Gregory Shimansky <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] -- Mikhail Fursov
Re: [drlvm][apr] APR fails to load a JIT library when using a fully qualified path
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: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
I looked at it( gc.LOS hang ) for a while and my findings are somewhat similar to Alexey's. The problem occurs for me all the time irrespective of where the trace statement apprears( ref: Weldon's comment ). On breaking in, the call stack at hang is: ntdll.dll!7c90eb94() ntdll.dll!7c90ea53() kernel32.dll!7c81e956() hythr.dll!apr_winapi_SwitchToThread() Line 219 + 0x2b C hythr.dll!apr_thread_yield() Line 195 C hythr.dll!hythread_yield() Line 297 C hythr.dll!wait_safe_region_event(HyThread * thread=0x0e80d408) Line 227 C hythr.dll!hythread_suspend_all(HyThread * * t=0x036af7b0, HyThreadGroup * group=0x) Line 401 + 0x9 C harmonyvm.dll!stop_the_world_root_set_enumeration() Line 89 + 0xb C++ harmonyvm.dll!vm_enumerate_root_set_all_threads() Line 143 C++ gc.dll!enumerate_universe() Line 127 + 0x8 C++ gc.dll!copy_gc(int size=4108) Line 326 + 0x16 C++ gc.dll!select_gc(int size=4108) Line 96 + 0x9 C++ gc.dll!gc_alloc(unsigned int in_size=4108, unsigned int ah=21234656, void * thread_pointer=0x0102c4cc) Line 238 + 0x9 C++ harmonyvm.dll!vm_new_vector_using_vtable_and_thread_pointer(int length=4096, unsigned int vector_handle=21234656, void * tp=0x0102c4cc) Line 233 + 0x14 C++ harmonyvm.dll!vm_rt_new_vector_using_vtable_and_thread_pointer(int length=4096, unsigned int vector_handle=21234656, void * tp=0x0102c4cc) Line 111 + 0x11 C++ 01341775() harmonyvm.dll!set_unwindable(bool unwindable=true) Line 140 + 0xd C++ ntdll.dll!7c90e591() ntdll.dll!7c90110a() hythr.dll!apr_thread_mutex_unlock(apr_thread_mutex_t * mutex=0x014ddba6) Line 117 C gc.dll!GC_VTable_Info::is_finalizible() Line 121 + 0x16 C++ 207ea704() jitrino.dll!Jitrino::Jet::rt_h_i64_a(__int64 v1=502568517412, __int64 v2=0, JavaByteCodes op=OPCODE_NOP) Line 211 + 0x2f C++ ntdll.dll!7c9106eb() ntdll.dll!7c9011a7() ntdll.dll!7c96cde9() ntdll.dll!7c918e94() ntdll.dll!7c918f87() ntdll.dll!7c90e591() ntdll.dll!7c926abe() ntdll.dll!7c96cde9() ntdll.dll!7c96e0f0() ntdll.dll!7c96e0d4() ntdll.dll!7c918dfa() ntdll.dll!7c90d625() harmonyvm.dll!initialize_arg_list_iterator(const char * descr=0x0057c530) Line 52 + 0x7 C++ harmonyvm.dll!Method::get_argument_list() Line 237 + 0x11 C++ 036afd5c() harmonyvm.dll!JIT_execute_method_default(void * jit=0x, _jmethodID * methodID=0x02686c40, jvalue * return_value=0x, jvalue * args=0x036afeac) Line 199 C++ em.dll!DrlEMImpl::executeMethod(_jmethodID * meth=0x02686c40, jvalue * return_value=0x, jvalue * args=0x036afeac) Line 488 + 0x16 C++ em.dll!ExecuteMethod(_jmethodID * meth=0x02686c40, jvalue * return_value=0x, jvalue * args=0x036afeac) Line 42 + 0x21 C++ harmonyvm.dll!vm_execute_java_method_array(_jmethodID * method=0x02686c40, jvalue * result=0x, jvalue * args=0x036afeac) Line 58 + 0x1c C++ harmonyvm.dll!call_method_no_ref_result(JNIEnv_External * env=0x0084e958, _jobject * obj=0x02d7e1a0, _jmethodID * methodID=0x02686c40, jvalue * args=0x, jvalue * result=0x, int non_virtual=0) Line 164 + 0x11 C++ harmonyvm.dll!CallVoidMethodA(JNIEnv_External * env=0x0084e958, _jobject * obj=0x02d7e1a0, _jmethodID * methodID=0x02686c40, jvalue * args=0x) Line 199 + 0x19 C++ harmonyvm.dll!wrapper_proc(void * arg=0x02d74078) Line 98 + 0x27 C hythr.dll!thread_start_proc(apr_thread_t * thd=0x0042c180, void * p_args=0x0042c0d8) Line 704 + 0xf C hythr.dll!dummy_worker(void * opaque=0x0042c180) Line 79 + 0x13 C hythr.dll!_threadstartex(void * ptd=0x0039f3a8) Line 241 + 0xd C kernel32.dll!7c80b50b() gc.dll!Partial_Reveal_Object::obj_info() Line 148 + 0x3d C++ kernel32.dll!7c8399f3() There seems to be some kind of endless loop in apr_winapi_switchtothread() ,and I suspect that the problem may be quite similar to Alexey's findings. I plan to investigate, but at this moment I am too broken with several tests failing before I can even get to this point. Thanks, Rana On 9/25/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > Folks, > > You may find interesting investigations in HARMONY-1519 [1] of bugs in > patched APR condition variables on Win32, which affect wait() > behavior. > > [1]http://issues.apache.org/jira/browse/HARMONY-1519?page=all > >
Re: [drlvm][apr] APR fails to load a JIT library when using a fully qualified path
2006/9/25, Mikhail Fursov <[EMAIL PROTECTED]>: 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. It would be really nice, projects are convenient for browsing/editing native sources on Windows. OTOH using them for compilation may be a concern, just like the one above - someone have to keep them in sync with common build system. But I suppose you are not alone in the way you work with MSVC anyway - so let's try. +1 from me. -- Alexey On 9/22/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > APR gurus! > I have a question I can't answer by myself. > > Usually to develop and test new JIT features I use custom EM configuration > file to move problem methods to a separate JIT instance. > Now I can't use this feature, because APR is unable to load a JIT library > with a fully specied path. > > So the problem is: > 1) I ask EM to use custom JIT library: > C:/users/mfursov/harmony_trace2/drlvm/trunk/vm/jitrino/bin/debug/jitrino.dll > 2) EM asks VM (APR) to load this module > 3) In dso.c, line 77 I see that 'wpath' variable is valid, but > LoadLibraryExW is failed. > > The error message is : Failure to open JIT dll file://C:/users/mfursov/harmony_trace2/drlvm/trunk/vm/jitrino/bin/debug/jitrino.dll720126 > > I know that there is nothing wrong with my DLL because if I copy it to the > default jitrino.dll location and do not use any paths everything works > fine. > > The simplest way to reproduce the bug is to use -Dem.jitPath= jitrino.dll> option. > Once is just 'jitrino.dll' APR loads DLL, but if > you change it to the full path to the same dll, APR fails to load it. > > ? > > -- > Mikhail Fursov -- Mikhail Fursov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
Folks, You may find interesting investigations in HARMONY-1519 [1] of bugs in patched APR condition variables on Win32, which affect wait() behavior. [1]http://issues.apache.org/jira/browse/HARMONY-1519?page=all 2006/9/25, Weldon Washburn <[EMAIL PROTECTED]>: The hang on gc.LOS on windows has been present for at least one week. I broke into the hung DRLVM with microsoft debugger. Its running jitted code that loops. The loop seems to involve synchronization primitives (see email chain "[drlvm] gc.LOS hangs on win32") I still suspect a bug that is somehow associated with Object.wait(). Its interesting to note what recently changed that might have an impact: - new thread manager - launcher was integrated The launcher starts out in the context of classlib's portlib . The classlib portlib context is later on partially replaced with PORTLIB, a C struct where all the members are nulled out. Apparently signals run in the context of classlib's portlib and the new thread manager runs in its own (appropriate) context. In any case, both classlib portlib and the new threading manager have implementations of monitor_wait(). There may some conflict on when and where each version of monitor wait is called. On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: > > On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > > > On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: > > > > > As for me (and other people) a lot of tests fail for the latest > > > sources (revision 449592). > > > I've run the build.bat clean; build.bat update; build.bat command > > > in compliance with comments for H-1457. > > > It's very strange for me it mentions here all C-unit tests work > > > fine. Sorry I cannot confirm this. > > > > It certainly did on my machine after a clean - update build, and then > > hung on gc.LOS. > > > Under what platform? This problem exists only for Windows. > > Thanks, > Vladimir. > > > The detailed investigation showed the patch for H-1457 is > > > incorrect. I've attached a patch fixing this issue. > > > Thanks Evgueni Brevnov for preparing this patch. After applying > > > these changes the issue disappeared. > > > > Where is that patch? it didn't make it through to list - can you > > just re-open 1457 and attach there? > > > > > > > > Geir, could you please look at this patch and apply it if there are > > > no objections? > > > > > > Thanks in advance, > > > Vladimir. > > > > > > On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Ok, I'm not > > > as worried - I went back a few days to r447025 and still > > > have the problem, so it's not from this morning. I guess this has > > > been masked all along by the logger problem. Noted in JIRA > > > HARMONY-1560 > > > > > > geir > > > > > > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: > > > > > > > This is completely my fault. > > > > > > > > The latest round of patches, while I dutifully do smoke, c-unit and > > > > kernel tests for each patch, I didn't do any app testing. > > > > > > > > I tried to run ActiveMQ, and it breaks with an asset in > > > > object_handles.cpp : 99 > > > > > > > > I'm going to back out the two GC patches I applied and hope for the > > > > best. > > > > > > > > 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] > > > > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
Pavel, Thanks for the links - I found smth interesting in the last one. Note, however: all of them mention that the application or extension class loader should use the Class-Path attribute, not arbitrary URLClassLoader. Moreover, this depends on the context - e.g. the extension CL should ignore it. And the URLClassLoader does not provide any API to control this. Though our URLClassLoader is aware of the Class-Path attribute and current JarRunner impl works, we may need to revisit this issue in sometime... -- Regards, Alexey 2006/9/25, Pavel Pervov <[EMAIL PROTECTED]>: Ha! I discovered interesting article [1] about java launcher and class loading. Pavel. [1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/findingclasses.html On 9/25/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > Pavel, > > Just to be clear, could you please point to some documentation which > declares such responsibility? > This seems logical and now I recall why I let it to be forgotten ;) > > 2006/9/25, Pavel Pervov <[EMAIL PROTECTED]>: > > Chris, > > > > As far as I understant, this is responsibility of a class loader to > parse > > Class-Path attribute of any jar file it has in its class path. > > System class loader for DRLVM (which is URLClassLoader) does this. > > > > Any objections? > > > > Regards, > >Pavel Pervov. > > Intel Middleware Products Division. > > > > On 9/25/06, Chris Gray <[EMAIL PROTECTED]> wrote: > > > > > > As I understand it, the classpath of the jarred application should > include > > > the > > > jar file itself and the contents of its Class-Path attribute (if any). > You > > > probably need to create a special class loader for the application and > use > > > that whenever the application (or a library loaded by it) is the > > > initiator. > > > -- > > > Chris Gray/k/ Embedded Java Solutions BE0503765045 > > > Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ > > > [EMAIL PROTECTED] +32 3 216 0369 > > > > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] Please integrate HARMONY -1340.
Committers, Could you please integrate fix from: HARMONY -1340 Fix invalid assertion in thread_native_fat_monitor.c The patch is trivial. The assertion in the current code is incorrect, it check that monitor is entered not more then once (recursion_count < 1) It was left in the code by mistake. The monitor recursion count could be any positive number (the number of nested monitorEnter calls). This assert happend quite often: in self hosting mode, and always on EM64T. Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][jit] possible ABCD bug
Hello Egor, I'm glad to hear the bug is real. It is a sign that I have learned how the ABCD code works. As you pointed out, this was no easy feat! :-) I wanted to do exactly what you seem to have already started. The fact that the existing ABCD pass does not build an inequality graph was very surprising to me. The pass tries to use SSA use-def chains as a substitute, which they certainly are not. The reason is subtle, but it has very severe implications on the effectiveness of the pass. It is sad, because this decision is central to the algorithm and means that much of the existing ABCD code is not useful to work with. I would definitely like to improve jitrino's ABCD, and would be happy to help you in your efforts. Thanks, Naveen On Sep 25, 2006, at 2:11 AM, Egor Pasko wrote: On the 0x1EE day of Apache Harmony Naveen Neelakantam wrote: I've been reading through the ABCD implementation in jitrino, and if I understand it correctly, I found a bug. I've attached a patch to fix it. Someone who actually understands the code should verify this. Naveen, you found a secret :) Recently, I spent some time understanding Jitrino's ABCD code too. Now it seems pretty clear, you pinpointed a bug. I did not try the patch on a strong benchmark such as DaCapo, and cannot estimate how much it can give in terms of performance. (Although, it is both a performance and correctness related fix) As you pointed out recently, checking both bounds assumes one comparison in CG. So, we won't get any performance benefit on IA-32 if we remove only one (lower or upper) bound of a 'chkbounds'. Also, did anyone ever test this ABCD pass? That's a long story. And here is the secret: Jitrino ABCD removes *only* lower bounds checks. Thus, it is useless currently. Well, this is not 100% true :) Sometimes, I saw it removing upper checks, but, probably, very obvious checks. I should have looked into the problem more thoroughly. This is a very sad story, so I decided to look what is happening. The algorithm is *not* easy to read, but what I can say for sure: * it is not the algorithm as in the original paper * it's algorithm applies some more advanced techniques (i.e. analysis of bounds of the kind A*x+B, where A and B are constants, x is a variable) and lacks them * "inequality graph" is not built, thus uncovering some extra limitations * the algorithm assumes all constants to be zero, when proving a check to eliminate. So, I cannot find any evidence for the algorithm to remove an upper check :( I tried the original ABCD example from the paper. And was upset almost like you :) I tried to trigger various switches, but they gave no clue, except a lot of assertions out of the blue. I ask because I've tried running it on a bidirectional bubble sort as mentioned in the original paper. The paper mentions that the pass should be able to prove all of the bounds checks in the sort method as redundant/ unnecessary. However, when I try running the abcd pass on a bidirectional bubble sort (attached), none of the bounds checks are eliminated. well, some actually are: bash$ grep "We can eliminate " naveen.sort.log We can eliminate LB check of I43:chkbounds g195.16 .lt. g8.8 -) g25:tau !!! We can eliminate LB check of I43:chkbounds g195.16 .lt. g8.8 -) g25:tau We can eliminate LB check of I54:chkbounds g32 .lt. g8.18 -) g36:tau !!! We can eliminate LB check of I54:chkbounds g32 .lt. g8.18 -) g36:tau We can eliminate LB check of I64:chkbounds g180 .lt. g8.8 -) g45:tau !!! We can eliminate LB check of I64:chkbounds g180 .lt. g8.8 -) g45:tau We can eliminate LB check of I74:chkbounds g194 .lt. g8.12 -) g55:tau !!! We can eliminate LB check of I74:chkbounds g194 .lt. g8.12 -) g55:tau We can eliminate LB check of I118:chkbounds g82.27 .lt. g8.1 -) g92:tau !!! We can eliminate LB check of I118:chkbounds g82.27 .lt. g8.1 -) g92:tau We can eliminate LB check of I129:chkbounds g80.31 .lt. g8.32 -) g103:tau !!! We can eliminate LB check of I129:chkbounds g80.31 .lt. g8.32 -) g103:tau We can eliminate LB check of I314:chkbounds g196 .lt. g8.5 -) g199:tau !!! We can eliminate LB check of I314:chkbounds g196 .lt. g8.5 -) g199:tau We can eliminate LB check of I294:chkbounds g218.3 .lt. g8.1 -) g185:tau !!! We can eliminate LB check of I294:chkbounds g218.3 .lt. g8.1 -) g185:tau but, you see, only lower bounds! (BTW, I applied your fix, it had no influence on your specific test) ...The code was so buggy and not easy to read, so I decided to implement the original algorithm by myself :) Well, I implemented the algorithm on a given inequality graph. Tested it a bit, and became satisfied on how it works. Now I am working on the IR-to-InequalityGraph transformer. And almost implemented it. At this point there is not a lot to do there to make the code working and eliminating. But, hey, you are the first to talk about ABCD on this list! I am so glad, someone found it too. If you a
Re: [jira] Created: (HARMONY-1538) [classlib][awt] Successor of CubicCurve2D throws NPE in contains() if getBounds2D() returns null
On 9/25/06, Denis Kishenko <[EMAIL PROTECTED]> wrote: Hi all I think this is non-bug difference. If successor of CubicCurve2D returns null instead of bounds then Harmony throws NPE in contains() method while RI doesn't. It seems like RI doesn't use getBounds2D() to implement contains() method while Harmony does. I see three possibilities 1. Exclude using of getBounds2D() from contains(). In this case algorithm efficiency will slow down because it's part of optimization. 2. Add at contains() method an additional bounds calculation. In this case we will get strange code duplication. 3. Stay as non-bug difference. It's very strange situation if shape returns null bounds but such shapes are drawn well (run the test). Comments? To follow RI I would suggest to add check (if the bounds2D is null) to the contains() method, in this case just to return false. Regards, Ilya. 2006/9/22, Denis Kishenko (JIRA) <[EMAIL PROTECTED]>: > [classlib][awt] Successor of CubicCurve2D throws NPE in contains() if getBounds2D() returns null > - > > Key: HARMONY-1538 > URL: http://issues.apache.org/jira/browse/HARMONY-1538 > Project: Harmony > Issue Type: Bug > Components: Classlib >Reporter: Denis Kishenko > > > If successor of CubicCurve2D returns null instead of bounds then Harmony throws NPE while RI doesn't. Harmony use shape bounds getBounds2D() to implement contains() and intersects() methods but It seems like RI doesn't use bounds for this. > > == Test.java = > > import java.awt.Frame; > import java.awt.Graphics; > import java.awt.Graphics2D; > import java.awt.geom.*; > > public class Test { >static public void main(String[] args) { > final CubicCurve2DImpl obj = new CubicCurve2DImpl(100, 100, 200, 200, 200, 100, 100, 200); > > Frame f = new Frame("Test") { > public void paint(Graphics g) { > ((Graphics2D)g).draw(obj); > } > }; > f.setSize(600, 400); > f.show(); > > System.out.println("obj.contains="+obj.contains(0, 0)); >} > } > > class CubicCurve2DImpl extends java.awt.geom.CubicCurve2D.Double { >public CubicCurve2DImpl(double x1, double y1, double x2, double y2, double x3, double y3, double x4, double y4) { >super(x1, y1, x2, y2, x3, y3, x4, y4); >} > >public Rectangle2D getBounds2D() { >return null; >} >} > > = RI Output = > obj.contains=false > > Harmony output = > java.lang.NullPointerException >at org.apache.harmony.awt.gl.Crossing.crossShape(Crossing.java:506) >at java.awt.geom.CubicCurve2D.contains(CubicCurve2D.java:537) > > > -- > 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] -- -- Ilya Okomin Intel Middleware Products Division
Re: [drlvm] my latest round of patches broke something
The hang on gc.LOS on windows has been present for at least one week. I broke into the hung DRLVM with microsoft debugger. Its running jitted code that loops. The loop seems to involve synchronization primitives (see email chain "[drlvm] gc.LOS hangs on win32") I still suspect a bug that is somehow associated with Object.wait(). Its interesting to note what recently changed that might have an impact: - new thread manager - launcher was integrated The launcher starts out in the context of classlib's portlib . The classlib portlib context is later on partially replaced with PORTLIB, a C struct where all the members are nulled out. Apparently signals run in the context of classlib's portlib and the new thread manager runs in its own (appropriate) context. In any case, both classlib portlib and the new threading manager have implementations of monitor_wait(). There may some conflict on when and where each version of monitor wait is called. On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: > > > As for me (and other people) a lot of tests fail for the latest > > sources (revision 449592). > > I've run the build.bat clean; build.bat update; build.bat command > > in compliance with comments for H-1457. > > It's very strange for me it mentions here all C-unit tests work > > fine. Sorry I cannot confirm this. > > It certainly did on my machine after a clean - update build, and then > hung on gc.LOS. Under what platform? This problem exists only for Windows. Thanks, Vladimir. > The detailed investigation showed the patch for H-1457 is > > incorrect. I've attached a patch fixing this issue. > > Thanks Evgueni Brevnov for preparing this patch. After applying > > these changes the issue disappeared. > > Where is that patch? it didn't make it through to list - can you > just re-open 1457 and attach there? > > > > > Geir, could you please look at this patch and apply it if there are > > no objections? > > > > Thanks in advance, > > Vladimir. > > > > On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Ok, I'm not > > as worried - I went back a few days to r447025 and still > > have the problem, so it's not from this morning. I guess this has > > been masked all along by the logger problem. Noted in JIRA > > HARMONY-1560 > > > > geir > > > > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: > > > > > This is completely my fault. > > > > > > The latest round of patches, while I dutifully do smoke, c-unit and > > > kernel tests for each patch, I didn't do any app testing. > > > > > > I tried to run ActiveMQ, and it breaks with an asset in > > > object_handles.cpp : 99 > > > > > > I'm going to back out the two GC patches I applied and hope for the > > > best. > > > > > > 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] > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Weldon Washburn Intel Middleware Products Division
Re: [classlib][awt] Fonts with negative size.
+1 I also think that it is better to follow 6.0 spec in this situation and to suggest that all the words said about TextAttribute are applicable to the Font itself. Actually, using default font size is definitely more reasonable behavior then playing with those negative values and the only concern was compatibility. But if 6.0 spec goes this way then, I think, we must do the same. Still there's a question what would be the metrics for the explicitely transformed font? On 9/25/06, Ilya Okomin <[EMAIL PROTECTED]> wrote: Guys, I found something in the Java 6.0 documentation. If you look at the TextAttribute spec there is a note for the SIZE field, attribute key for the font size: "Attribute key for the font size. Values are instances of *Number*. The default value is 12pt. This corresponds to the size parameter to the Font constructor. Very large or small sizes will impact rendering performance, and the rendering system might not render text at these sizes. *Negative sizes are illegal and result in the default size*." For this reason I suggest to use default size (12pt) if font has negative size parameter. Any thoughts? I believe negative-sized fonts support was erroneous in Java 5.0 and in the earlier versions of Java. Regards, Ilya. On 9/25/06, Oleg Khaschansky <[EMAIL PROTECTED]> wrote: > > It seems like returning negative metrics is somewhat logical. If the > font is rotated by -Pi then all offsets becomes negative, but their > absolute values are equal to the positive ones. > > I'll try to give an example. E.g. if descent was, say, 10 and one > needed to offset 10 pt from the origin (baseline) to the bottom of the > black box then if -pi rotation is applied to the font, one need to > offset -10 pt from the baseline since black box is upside down. > > Yes, RI failed to be consistent with this on heavyweight components as > it was noted in the evaluation. But is this bug still there in the RI? > And if RI is inconsistent with the drawing of negative-sized fonts it > is still consistent with the negative metrics, right? > > IMHO, the ideal behavior in all situations would be the following: > If the font has negative size we assume that it has all the same > metrics as the positive font, but the metrics which has a direction > (like ascent, descent, etc.) are with the different sign. The font is > drawn as it was rotated by -pi angle. > > Personaly my opinion is that this is a bug, not non-bug diff. > I'd suggest to choose between these options: > 1. Fix metrics and rendering, close this issue. > 2. Fix metrics, open a new jira for the rendering of the negative-sized > fonts. > 3. Fix nothing, open a new jira or add an evaluation to this one > both for the rendering and for the metrics. This means that we want to > have them together. > > For the rendering part, why not just add a transform if the size of > the font is negative? > > On 9/25/06, Ilya Okomin <[EMAIL PROTECTED]> wrote: > > On 9/25/06, Oleg Khaschansky <[EMAIL PROTECTED] > wrote: > > > > > It was evaluated as "not a bug". But it is clear from its evaluation > > > that negative-sized fonts are treated as positive sized but rotated > > > around their origin, say with implicit transform. I'd suggest to > > > follow this behavior. > > > > > > I agree, that the behavior of the negative-sized fonts on RI is looks > like > > the behavior of positive ones with -Pi rotation. However, if we look at > the > > font metrics, bounds - we can see negative values for height, width > > values...I'm not sure they have any sence without additional > documentation > > that we can't find in the spec. > > Moreover bug evaluation says that RI handles negative-sized fonts for > > components in different ways depending on the platform. And it's > behavior > > unlike the drawing on the frame surface. What is to add - metrics for > all > > these various cases are the same, it means that RI has erroneous > behavior in > > some way. > > > > I would suggest not to follow the RI and mark it as "non-bug difference" > as > > the RI hasn't any clear documentation on this problem and it's > > behavior erroneous and depends on the platform or component type. > > > > Thanks, > > Ilya. > > > > > > > > > > > On 9/23/06, Richard Liang < [EMAIL PROTECTED]> wrote: > > > > On 9/23/06, Alexey Varlamov <[EMAIL PROTECTED] > wrote: > > > > > Google said this is the bug of RI in progress [1]. However there > is no > > > > > distinct resolution yet... > > > > > > > > > > > > > It's reported again Java 1.1.8 more than 3 years agao. I don't think > > > > RI will fix this bug. > > > > > > > > Richard. > > > > > > > > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825 > > > > > > > > > > > > > > > 2006/9/23, Richard Liang < [EMAIL PROTECTED]>: > > > > > > On 9/22/06, Ilya Okomin < [EMAIL PROTECTED]> wrote: > > > > > > > Hi, all! > > > > > > > > > > > > > > I was playing with fonts and found that Font with negative > size > > > can be > > > > > > > created on RI. > > > > >
Re: [VOTE] HARMONY-1217 : JNI-style C header file generator (aka 'javah')
I've worked with it, nice tool! +1 On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: +1 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] -- -- Ilya Okomin Intel Middleware Products Division
Re: [classlib][awt] Fonts with negative size.
Guys, I found something in the Java 6.0 documentation. If you look at the TextAttribute spec there is a note for the SIZE field, attribute key for the font size: "Attribute key for the font size. Values are instances of *Number*. The default value is 12pt. This corresponds to the size parameter to the Font constructor. Very large or small sizes will impact rendering performance, and the rendering system might not render text at these sizes. *Negative sizes are illegal and result in the default size*." For this reason I suggest to use default size (12pt) if font has negative size parameter. Any thoughts? I believe negative-sized fonts support was erroneous in Java 5.0 and in the earlier versions of Java. Regards, Ilya. On 9/25/06, Oleg Khaschansky <[EMAIL PROTECTED]> wrote: It seems like returning negative metrics is somewhat logical. If the font is rotated by -Pi then all offsets becomes negative, but their absolute values are equal to the positive ones. I'll try to give an example. E.g. if descent was, say, 10 and one needed to offset 10 pt from the origin (baseline) to the bottom of the black box then if -pi rotation is applied to the font, one need to offset -10 pt from the baseline since black box is upside down. Yes, RI failed to be consistent with this on heavyweight components as it was noted in the evaluation. But is this bug still there in the RI? And if RI is inconsistent with the drawing of negative-sized fonts it is still consistent with the negative metrics, right? IMHO, the ideal behavior in all situations would be the following: If the font has negative size we assume that it has all the same metrics as the positive font, but the metrics which has a direction (like ascent, descent, etc.) are with the different sign. The font is drawn as it was rotated by -pi angle. Personaly my opinion is that this is a bug, not non-bug diff. I'd suggest to choose between these options: 1. Fix metrics and rendering, close this issue. 2. Fix metrics, open a new jira for the rendering of the negative-sized fonts. 3. Fix nothing, open a new jira or add an evaluation to this one both for the rendering and for the metrics. This means that we want to have them together. For the rendering part, why not just add a transform if the size of the font is negative? On 9/25/06, Ilya Okomin <[EMAIL PROTECTED]> wrote: > On 9/25/06, Oleg Khaschansky <[EMAIL PROTECTED] > wrote: > > > It was evaluated as "not a bug". But it is clear from its evaluation > > that negative-sized fonts are treated as positive sized but rotated > > around their origin, say with implicit transform. I'd suggest to > > follow this behavior. > > > I agree, that the behavior of the negative-sized fonts on RI is looks like > the behavior of positive ones with -Pi rotation. However, if we look at the > font metrics, bounds - we can see negative values for height, width > values...I'm not sure they have any sence without additional documentation > that we can't find in the spec. > Moreover bug evaluation says that RI handles negative-sized fonts for > components in different ways depending on the platform. And it's behavior > unlike the drawing on the frame surface. What is to add - metrics for all > these various cases are the same, it means that RI has erroneous behavior in > some way. > > I would suggest not to follow the RI and mark it as "non-bug difference" as > the RI hasn't any clear documentation on this problem and it's > behavior erroneous and depends on the platform or component type. > > Thanks, > Ilya. > > > > > > On 9/23/06, Richard Liang < [EMAIL PROTECTED]> wrote: > > > On 9/23/06, Alexey Varlamov <[EMAIL PROTECTED] > wrote: > > > > Google said this is the bug of RI in progress [1]. However there is no > > > > distinct resolution yet... > > > > > > > > > > It's reported again Java 1.1.8 more than 3 years agao. I don't think > > > RI will fix this bug. > > > > > > Richard. > > > > > > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825 > > > > > > > > > > > > 2006/9/23, Richard Liang < [EMAIL PROTECTED]>: > > > > > On 9/22/06, Ilya Okomin < [EMAIL PROTECTED]> wrote: > > > > > > Hi, all! > > > > > > > > > > > > I was playing with fonts and found that Font with negative size > > can be > > > > > > created on RI. > > > > > > Unfortunately spec keep silence about fonts with negative sizes. > > > > > > On Harmony if font size is negative then it is set to zero. > > > > > > > > > > > > test.java--- > > > > > > import java.awt.*; > > > > > > import java.awt.font.FontRenderContext; > > > > > > > > > > > > public class NegativeFontTest { > > > > > > > > > > > > public static void main(String[] args) { > > > > > > int fontsize=-5; > > > > > > Font localFont = new Font("Arial", 2, fontsize); > > > > > > System.out.println("Size = " + localFont.getSize2D()); > > > > > > > > > > > > System.out.println("Height = " + localFont.getLineMetrics("", > > new > > > > > > F
Re: [drlvm][launcher] performance issue when loading property (was Re: [launcher] Patch is available for "harmonyvm.properties" parsing)
Sure. I just hope Evgueni will submit complete Invocation API very soon - so we would not interfere in initialization code. If not - I'm going to fix this in a day. 2006/9/25, Ivan Volosyuk <[EMAIL PROTECTED]>: Alexey, would you create JIRA for this? Looks you have more information about the problem? -- Ivan On 9/23/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > Please... > > On Sep 23, 2006, at 7:58 AM, Alexey Varlamov wrote: > > > Ha! This is apr_file_gets() who does this! > > > > So this is DRLVM specific and duplicates classlib's efforts. We should > > get rid of this. > > > > 2006/9/23, Ivan Volosyuk <[EMAIL PROTECTED]>: > >> You are right. It is different property file: > >> $JRE/lib/boot/bootclasspath.properties (6kbyte) > >> > >> The strace looks like following. Not quite effective. > >> The number of syscalls is greater then all others at the startup of > >> VM. I would like to file a performance JIRA for the issue, but I > >> don't > >> quite understand if it DRLVM specific or classlib? > >> -- > >> Ivan > >> > >> read(3, "#", 1) = 1 > >> read(3, " ", 1) = 1 > >> read(3, "C", 1) = 1 > >> read(3, "o", 1) = 1 > >> read(3, "p", 1) = 1 > >> read(3, "y", 1) = 1 > >> read(3, "r", 1) = 1 > >> read(3, "i", 1) = 1 > >> read(3, "g", 1) = 1 > >> read(3, "h", 1) = 1 > >> read(3, "t", 1) = 1 - 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][apr] APR fails to load a JIT library when using a fully qualified path
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. On 9/22/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: APR gurus! I have a question I can't answer by myself. Usually to develop and test new JIT features I use custom EM configuration file to move problem methods to a separate JIT instance. Now I can't use this feature, because APR is unable to load a JIT library with a fully specied path. So the problem is: 1) I ask EM to use custom JIT library: C:/users/mfursov/harmony_trace2/drlvm/trunk/vm/jitrino/bin/debug/jitrino.dll 2) EM asks VM (APR) to load this module 3) In dso.c, line 77 I see that 'wpath' variable is valid, but LoadLibraryExW is failed. The error message is : Failure to open JIT dll file://C:/users/mfursov/harmony_trace2/drlvm/trunk/vm/jitrino/bin/debug/jitrino.dll720126 I know that there is nothing wrong with my DLL because if I copy it to the default jitrino.dll location and do not use any paths everything works fine. The simplest way to reproduce the bug is to use -Dem.jitPath= option. Once is just 'jitrino.dll' APR loads DLL, but if you change it to the full path to the same dll, APR fails to load it. ? -- Mikhail Fursov -- Mikhail Fursov
Re: [drlvm] my latest round of patches broke something
Geir, Vladimir, I've returned from vacation today, so my 2 cents to this discussion... I guess the problem have appeared because in r449399 the changes for win/apr_thread_ext.c were committed, but new file patches/win/APR/threadproc/win32/thread.c was not committed. These changes are work together. The patch suggested by Vladimir will not fix issue completely. I cannot provide a test for issue I have fixed (I can't understand how to create it), but it's quite enough to uncomment debug printing in apr_thread_yield_other() function to view differences on any simple Java application. 2006/9/25, Vladimir Gorr <[EMAIL PROTECTED]>: On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: > > > As for me (and other people) a lot of tests fail for the latest > > sources (revision 449592). > > I've run the build.bat clean; build.bat update; build.bat command > > in compliance with comments for H-1457. > > It's very strange for me it mentions here all C-unit tests work > > fine. Sorry I cannot confirm this. > > It certainly did on my machine after a clean - update build, and then > hung on gc.LOS. Under what platform? This problem exists only for Windows. Thanks, Vladimir. > The detailed investigation showed the patch for H-1457 is > > incorrect. I've attached a patch fixing this issue. > > Thanks Evgueni Brevnov for preparing this patch. After applying > > these changes the issue disappeared. > > Where is that patch? it didn't make it through to list - can you > just re-open 1457 and attach there? > > > > > Geir, could you please look at this patch and apply it if there are > > no objections? > > > > Thanks in advance, > > Vladimir. > > > > On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Ok, I'm not > > as worried - I went back a few days to r447025 and still > > have the problem, so it's not from this morning. I guess this has > > been masked all along by the logger problem. Noted in JIRA > > HARMONY-1560 > > > > geir > > > > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: > > > > > This is completely my fault. > > > > > > The latest round of patches, while I dutifully do smoke, c-unit and > > > kernel tests for each patch, I didn't do any app testing. > > > > > > I tried to run ActiveMQ, and it breaks with an asset in > > > object_handles.cpp : 99 > > > > > > I'm going to back out the two GC patches I applied and hope for the > > > best. > > > > > > 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] > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
Ha! I discovered interesting article [1] about java launcher and class loading. Pavel. [1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/findingclasses.html On 9/25/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: Pavel, Just to be clear, could you please point to some documentation which declares such responsibility? This seems logical and now I recall why I let it to be forgotten ;) 2006/9/25, Pavel Pervov <[EMAIL PROTECTED]>: > Chris, > > As far as I understant, this is responsibility of a class loader to parse > Class-Path attribute of any jar file it has in its class path. > System class loader for DRLVM (which is URLClassLoader) does this. > > Any objections? > > Regards, >Pavel Pervov. > Intel Middleware Products Division. > > On 9/25/06, Chris Gray <[EMAIL PROTECTED]> wrote: > > > > As I understand it, the classpath of the jarred application should include > > the > > jar file itself and the contents of its Class-Path attribute (if any). You > > probably need to create a special class loader for the application and use > > that whenever the application (or a library loaded by it) is the > > initiator. > > -- > > Chris Gray/k/ Embedded Java Solutions BE0503765045 > > Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ > > [EMAIL PROTECTED] +32 3 216 0369 > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
Alexey, There numerous sources. [1] is jar file specification - look for Class-Path attribute description, [2] is from "Java tutorials" series - read through first paragraph. I'm sure that more direct statement can be found at java.sun.com. [1] http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html [2] http://java.sun.com/docs/books/tutorial/ext/basics/load.html On 9/25/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: Pavel, Just to be clear, could you please point to some documentation which declares such responsibility? This seems logical and now I recall why I let it to be forgotten ;) 2006/9/25, Pavel Pervov <[EMAIL PROTECTED]>: > Chris, > > As far as I understant, this is responsibility of a class loader to parse > Class-Path attribute of any jar file it has in its class path. > System class loader for DRLVM (which is URLClassLoader) does this. > > Any objections? > > Regards, >Pavel Pervov. > Intel Middleware Products Division. > > On 9/25/06, Chris Gray <[EMAIL PROTECTED]> wrote: > > > > As I understand it, the classpath of the jarred application should include > > the > > jar file itself and the contents of its Class-Path attribute (if any). You > > probably need to create a special class loader for the application and use > > that whenever the application (or a library loaded by it) is the > > initiator. > > -- > > Chris Gray/k/ Embedded Java Solutions BE0503765045 > > Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ > > [EMAIL PROTECTED] +32 3 216 0369 > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}
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
Re: [classlib][awt] Fonts with negative size.
It seems like returning negative metrics is somewhat logical. If the font is rotated by -Pi then all offsets becomes negative, but their absolute values are equal to the positive ones. I'll try to give an example. E.g. if descent was, say, 10 and one needed to offset 10 pt from the origin (baseline) to the bottom of the black box then if -pi rotation is applied to the font, one need to offset -10 pt from the baseline since black box is upside down. Yes, RI failed to be consistent with this on heavyweight components as it was noted in the evaluation. But is this bug still there in the RI? And if RI is inconsistent with the drawing of negative-sized fonts it is still consistent with the negative metrics, right? IMHO, the ideal behavior in all situations would be the following: If the font has negative size we assume that it has all the same metrics as the positive font, but the metrics which has a direction (like ascent, descent, etc.) are with the different sign. The font is drawn as it was rotated by -pi angle. Personaly my opinion is that this is a bug, not non-bug diff. I'd suggest to choose between these options: 1. Fix metrics and rendering, close this issue. 2. Fix metrics, open a new jira for the rendering of the negative-sized fonts. 3. Fix nothing, open a new jira or add an evaluation to this one both for the rendering and for the metrics. This means that we want to have them together. For the rendering part, why not just add a transform if the size of the font is negative? On 9/25/06, Ilya Okomin <[EMAIL PROTECTED]> wrote: On 9/25/06, Oleg Khaschansky <[EMAIL PROTECTED] > wrote: > It was evaluated as "not a bug". But it is clear from its evaluation > that negative-sized fonts are treated as positive sized but rotated > around their origin, say with implicit transform. I'd suggest to > follow this behavior. I agree, that the behavior of the negative-sized fonts on RI is looks like the behavior of positive ones with -Pi rotation. However, if we look at the font metrics, bounds - we can see negative values for height, width values...I'm not sure they have any sence without additional documentation that we can't find in the spec. Moreover bug evaluation says that RI handles negative-sized fonts for components in different ways depending on the platform. And it's behavior unlike the drawing on the frame surface. What is to add - metrics for all these various cases are the same, it means that RI has erroneous behavior in some way. I would suggest not to follow the RI and mark it as "non-bug difference" as the RI hasn't any clear documentation on this problem and it's behavior erroneous and depends on the platform or component type. Thanks, Ilya. > On 9/23/06, Richard Liang < [EMAIL PROTECTED]> wrote: > > On 9/23/06, Alexey Varlamov <[EMAIL PROTECTED] > wrote: > > > Google said this is the bug of RI in progress [1]. However there is no > > > distinct resolution yet... > > > > > > > It's reported again Java 1.1.8 more than 3 years agao. I don't think > > RI will fix this bug. > > > > Richard. > > > > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825 > > > > > > > > > 2006/9/23, Richard Liang < [EMAIL PROTECTED]>: > > > > On 9/22/06, Ilya Okomin < [EMAIL PROTECTED]> wrote: > > > > > Hi, all! > > > > > > > > > > I was playing with fonts and found that Font with negative size > can be > > > > > created on RI. > > > > > Unfortunately spec keep silence about fonts with negative sizes. > > > > > On Harmony if font size is negative then it is set to zero. > > > > > > > > > > test.java--- > > > > > import java.awt.*; > > > > > import java.awt.font.FontRenderContext; > > > > > > > > > > public class NegativeFontTest { > > > > > > > > > > public static void main(String[] args) { > > > > > int fontsize=-5; > > > > > Font localFont = new Font("Arial", 2, fontsize); > > > > > System.out.println("Size = " + localFont.getSize2D()); > > > > > > > > > > System.out.println("Height = " + localFont.getLineMetrics("", > new > > > > > FontRenderContext(null, false, false)).getHeight()); > > > > > System.out.println("MaxCharBounds = " + > localFont.getMaxCharBounds(new > > > > > FontRenderContext(null, false, false))); > > > > > } > > > > > > > > > > } > > > > > > > > > > If you run this test case on RI you can see that output looks > quite strange: > > > > > > > > > > Size = -5.0 > > > > > Height = -5.7495117 > > > > > MaxCharBounds = java.awt.geom.Rectangle2D$Float[x=0.0,y=4.6081543 > ,w=-5.46875 > > > > > ,h=- 5.7495117] > > > > > > > > > > > > > > > Actually, I dont see any sence in negative height and width > metrics and > > > > > I think it is an RI bug. > > > > > If you try to draw text with such font on RI - nothing is happen, > you can't > > > > > see any text on the component. > > > > > I've ran 'xfontsel' tool on Linux and there was suggested to > choose only > > > > >
Re: [jira] Created: (HARMONY-1570) [classlibl][awt] RI considers that negative rectangle is contained inside empty GeneralPath
Hi all I have found strange behaviour of RI implementation of java.awt.geom.GeneralPath. RI returns TRUE for following code while Harmony returns FALSE new GeneralPath().contains(0, 0, -10, -10)) Actually TRUE result is absolutely illogical because of 1. GeneralPath is empty 2. Negative width and height meen that rectangle is empty too I have marked this issue as non-bug difference. Any comments? 2006/9/25, Denis Kishenko (JIRA) <[EMAIL PROTECTED]>: [classlibl][awt] RI considers that negative rectangle is contained inside empty GeneralPath --- Key: HARMONY-1570 URL: http://issues.apache.org/jira/browse/HARMONY-1570 Project: Harmony Issue Type: Bug Components: Non-bug differences from RI Reporter: Denis Kishenko RI implementation of GeneralPath.contains(x, y, width, height) returns true if input width and height are negative and GeneralPath is empty. It's absolutely illogical. === Test.java === import junit.framework.TestCase; import junit.textui.TestRunner; import java.awt.geom.GeneralPath; public class Test extends TestCase { public void testcase0() { GeneralPath p = new GeneralPath(); assertTrue(p.contains(0, 0, -10, -10)); } static public void main(String[] args) { TestRunner.run(Test.class); } } = RI ===. Time: 0,031 OK (1 test) === Harmony === Time: 0.328 There was 1 failure: 1) testcase0(Test)junit.framework.AssertionFailedError at Test.testcase0(Test.java:10) at java.lang.reflect.VMReflection.invokeMethod() FAILURES!!! Tests run: 1, Failures: 1, Errors: 0 */ -- 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: [classlib][awt] Fonts with negative size.
On 9/25/06, Oleg Khaschansky <[EMAIL PROTECTED] > wrote: It was evaluated as "not a bug". But it is clear from its evaluation that negative-sized fonts are treated as positive sized but rotated around their origin, say with implicit transform. I'd suggest to follow this behavior. I agree, that the behavior of the negative-sized fonts on RI is looks like the behavior of positive ones with -Pi rotation. However, if we look at the font metrics, bounds - we can see negative values for height, width values...I'm not sure they have any sence without additional documentation that we can't find in the spec. Moreover bug evaluation says that RI handles negative-sized fonts for components in different ways depending on the platform. And it's behavior unlike the drawing on the frame surface. What is to add - metrics for all these various cases are the same, it means that RI has erroneous behavior in some way. I would suggest not to follow the RI and mark it as "non-bug difference" as the RI hasn't any clear documentation on this problem and it's behavior erroneous and depends on the platform or component type. Thanks, Ilya. On 9/23/06, Richard Liang < [EMAIL PROTECTED]> wrote: > On 9/23/06, Alexey Varlamov <[EMAIL PROTECTED] > wrote: > > Google said this is the bug of RI in progress [1]. However there is no > > distinct resolution yet... > > > > It's reported again Java 1.1.8 more than 3 years agao. I don't think > RI will fix this bug. > > Richard. > > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825 > > > > > > 2006/9/23, Richard Liang < [EMAIL PROTECTED]>: > > > On 9/22/06, Ilya Okomin < [EMAIL PROTECTED]> wrote: > > > > Hi, all! > > > > > > > > I was playing with fonts and found that Font with negative size can be > > > > created on RI. > > > > Unfortunately spec keep silence about fonts with negative sizes. > > > > On Harmony if font size is negative then it is set to zero. > > > > > > > > test.java--- > > > > import java.awt.*; > > > > import java.awt.font.FontRenderContext; > > > > > > > > public class NegativeFontTest { > > > > > > > > public static void main(String[] args) { > > > > int fontsize=-5; > > > > Font localFont = new Font("Arial", 2, fontsize); > > > > System.out.println("Size = " + localFont.getSize2D()); > > > > > > > > System.out.println("Height = " + localFont.getLineMetrics("", new > > > > FontRenderContext(null, false, false)).getHeight()); > > > > System.out.println("MaxCharBounds = " + localFont.getMaxCharBounds(new > > > > FontRenderContext(null, false, false))); > > > > } > > > > > > > > } > > > > > > > > If you run this test case on RI you can see that output looks quite strange: > > > > > > > > Size = -5.0 > > > > Height = -5.7495117 > > > > MaxCharBounds = java.awt.geom.Rectangle2D$Float[x=0.0,y=4.6081543 ,w=-5.46875 > > > > ,h=- 5.7495117] > > > > > > > > > > > > Actually, I dont see any sence in negative height and width metrics and > > > > I think it is an RI bug. > > > > If you try to draw text with such font on RI - nothing is happen, you can't > > > > see any text on the component. > > > > I've ran 'xfontsel' tool on Linux and there was suggested to choose only > > > > positive sized fonts. Also I've looked on the GDI LOGFONT structure > > > > description in MSDN and I've seen there again that we deal with absolute > > > > height values. > > > > > > > > Any thoughts on this issue, is it RI bug or not? > > > > > > We cannot say it's a bug of RI, because the spec does not explicitly > > > describe the requirement of font size. > > > > > > I suggest we follow RI. > > > > > > Best regards, > > > Richard > > > > > > > > > > > Thanks, > > > > Ilya. > > > > > > > > -- > > > > -- > > > > Ilya Okomin > > > > Intel Middleware Products Division > > > > > > > > > > > > > > > > > -- > > > Richard Liang > > > China Development Lab, IBM > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Richard Liang > China Development Lab, IBM > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
[jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run
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
[drlvm][launcher] performance issue when loading property (was Re: [launcher] Patch is available for "harmonyvm.properties" parsing)
Alexey, would you create JIRA for this? Looks you have more information about the problem? -- Ivan On 9/23/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Please... On Sep 23, 2006, at 7:58 AM, Alexey Varlamov wrote: > Ha! This is apr_file_gets() who does this! > > So this is DRLVM specific and duplicates classlib's efforts. We should > get rid of this. > > 2006/9/23, Ivan Volosyuk <[EMAIL PROTECTED]>: >> You are right. It is different property file: >> $JRE/lib/boot/bootclasspath.properties (6kbyte) >> >> The strace looks like following. Not quite effective. >> The number of syscalls is greater then all others at the startup of >> VM. I would like to file a performance JIRA for the issue, but I >> don't >> quite understand if it DRLVM specific or classlib? >> -- >> Ivan >> >> read(3, "#", 1) = 1 >> read(3, " ", 1) = 1 >> read(3, "C", 1) = 1 >> read(3, "o", 1) = 1 >> read(3, "p", 1) = 1 >> read(3, "y", 1) = 1 >> read(3, "r", 1) = 1 >> read(3, "i", 1) = 1 >> read(3, "g", 1) = 1 >> read(3, "h", 1) = 1 >> read(3, "t", 1) = 1 - 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] Trouble Building DRLVM
On the 0x1EC day of Apache Harmony Egor Pasko wrote: > On the 0x1EB day of Apache Harmony Egor Pasko wrote: > > On the 0x1EB day of Apache Harmony Geir Magnusson, Jr. wrote: > > > I modified the launcher to include both the vm directory as well as > > > the launcher directory on the PATH/LD_LIBRARY_PATH. > > > > I am not catching .. the launcher directory is known without > > PATH/LD_LIBRARY_PATH. Why should we look at PATH? > > > > > Can those that have been having troubles with shared lib loading give > > > it a try, and report back, and please mention the platform you are > > > running on... > > > > SUSE 9: > > * HelloWorld works without complaining, cool! > > * JAVA_HOME crash is gone, great! > > (but are we not ignoring JAVA_HOME yet?) > > * tests: > > * ThreadTest failed on JET (looks like a known issue:) > > * ~4 tests failed on OPT (ThreadTest too), I'll look at them > > I picked the ClassLoaderTest. It passes on JET and failes on OPT. > Looks like it is time to open a JIRA... If nobody objects, :) I'll > put some words here as an example how to investigate JIT compiler > problems. I hope, it might be useful for people. > > I ran it as a single test like this: > .../jre/bin/java -Xem:opt > -Xbootclasspath/a:$HARMONY/working_classlib/depends/jars/junit_3.8.2/junit.jar:$HARMONY/working_vm/build/lnx_ia32_gcc_debug/semis/kernel.tests/classes > junit.textui.TestRunner java.lang.ClassLoaderTest > > If invoked with the option "-Xtrace:em", DRLVM prints compilation > events as soon as they occur. What makes real fun is that one method > starts compilation several times (without success) and receives > SEGFAULT after not so many attempts. The bug may be in OPT or in > recompilation, not clear now. Will investigate (first, I'll try to > compile some methods with JET selectively) the bug is caused by OPT's incorrect compilation of method test_getPackages_V if I move the compilation to JET, the test passes. Investigating... Moving compilation of _one_ method to JET, while _others_ are compiled with OPT *is easy*. All you have to do is put debug.emconf file to .../jre/bin/default and run with the option -Xem:debug debug.emconf is as follows: chains=chain1,chain2 chain1.jits=JET_DEBUG chain2.jits=CD_OPT chain1.filter=+::test_getPackages_V chain1.filter=- JET_DEBUG.file=jitrino CD_OPT.file=jitrino # Options to be passed to JIT -Djit.JET_DEBUG.path= -Djit.CD_OPT.path=opt_init,translator,optimizer,hir2lir,codegen -Djit.CD_OPT.path.optimizer=ssa,devirt,inline,purge,simplify,uce,dce,lazyexc,memopt,simplify,uce,dce,lower,dessa,statprof,markglobals -Djit.CD_OPT.path.codegen=lock_method,bbp,gcpoints,cafl,dce1,i8l,early_prop,itrace-,native,constraints,dce2,regalloc,spillgen,layout,copy,rce+,stack,break-,iprof-,emitter!,si_insts,gcmap,info,unlock_method -Djit.CD_OPT.path.dce1=cg_dce -Djit.CD_OPT.path.dce2=cg_dce -Djit.CD_OPT.path.regalloc=bp_regalloc1,bp_regalloc2 -Djit.CD_OPT.path.bp_regalloc1=bp_regalloc -Djit.CD_OPT.path.bp_regalloc2=bp_regalloc #inliner configuration -Djit.CD_OPT.CD_OPT_inliner_pipeline.filter=- -Djit.CD_OPT.CD_OPT_inliner_pipeline.path=ssa,devirt -Djit.CD_OPT.arg.optimizer.inline.pipeline=CD_OPT_inliner_pipeline -Djit.CD_OPT.arg.codegen.dce1.early=yes -Djit.CD_OPT.arg.codegen.regalloc.bp_regalloc1.regs=ALL_GP -Djit.CD_OPT.arg.codegen.regalloc.bp_regalloc2.regs=ALL_XMM -- 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: [doc] new "Getting Started" guides
> http://incubator.apache.org/harmony/quickhelp_contributors.html I have a couple of comments on the contents: 1. > $ ant fetch-depends As I am sitting behind the firewall, I have to use $ ANT_OPTS='-Dhttp.proxyHost= -Dhttp.proxyPort=' ant fetch-depends to make sure ant can download dependencies using HTTP proxy. 2. > As of now, you cannot build from a Cygwin or other alternative shell. This is not exactly the case. - DRLVM has provisions in 'build.bat' to set up environment using Visual Studio environment file 'vsvars32.bat' (and friends). - if Visual Studio configured system environment during installation, then both DRLVM and Classlib can be built from any place. - 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-1538) [classlib][awt] Successor of CubicCurve2D throws NPE in contains() if getBounds2D() returns null
Hi all I think this is non-bug difference. If successor of CubicCurve2D returns null instead of bounds then Harmony throws NPE in contains() method while RI doesn't. It seems like RI doesn't use getBounds2D() to implement contains() method while Harmony does. I see three possibilities 1. Exclude using of getBounds2D() from contains(). In this case algorithm efficiency will slow down because it's part of optimization. 2. Add at contains() method an additional bounds calculation. In this case we will get strange code duplication. 3. Stay as non-bug difference. It's very strange situation if shape returns null bounds but such shapes are drawn well (run the test). Comments? 2006/9/22, Denis Kishenko (JIRA) <[EMAIL PROTECTED]>: [classlib][awt] Successor of CubicCurve2D throws NPE in contains() if getBounds2D() returns null - Key: HARMONY-1538 URL: http://issues.apache.org/jira/browse/HARMONY-1538 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Denis Kishenko If successor of CubicCurve2D returns null instead of bounds then Harmony throws NPE while RI doesn't. Harmony use shape bounds getBounds2D() to implement contains() and intersects() methods but It seems like RI doesn't use bounds for this. == Test.java = import java.awt.Frame; import java.awt.Graphics; import java.awt.Graphics2D; import java.awt.geom.*; public class Test { static public void main(String[] args) { final CubicCurve2DImpl obj = new CubicCurve2DImpl(100, 100, 200, 200, 200, 100, 100, 200); Frame f = new Frame("Test") { public void paint(Graphics g) { ((Graphics2D)g).draw(obj); } }; f.setSize(600, 400); f.show(); System.out.println("obj.contains="+obj.contains(0, 0)); } } class CubicCurve2DImpl extends java.awt.geom.CubicCurve2D.Double { public CubicCurve2DImpl(double x1, double y1, double x2, double y2, double x3, double y3, double x4, double y4) { super(x1, y1, x2, y2, x3, y3, x4, y4); } public Rectangle2D getBounds2D() { return null; } } = RI Output = obj.contains=false Harmony output = java.lang.NullPointerException at org.apache.harmony.awt.gl.Crossing.crossShape(Crossing.java:506) at java.awt.geom.CubicCurve2D.contains(CubicCurve2D.java:537) -- 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] my latest round of patches broke something
On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: > As for me (and other people) a lot of tests fail for the latest > sources (revision 449592). > I've run the build.bat clean; build.bat update; build.bat command > in compliance with comments for H-1457. > It's very strange for me it mentions here all C-unit tests work > fine. Sorry I cannot confirm this. It certainly did on my machine after a clean - update build, and then hung on gc.LOS. Under what platform? This problem exists only for Windows. Thanks, Vladimir. The detailed investigation showed the patch for H-1457 is > incorrect. I've attached a patch fixing this issue. > Thanks Evgueni Brevnov for preparing this patch. After applying > these changes the issue disappeared. Where is that patch? it didn't make it through to list - can you just re-open 1457 and attach there? > > Geir, could you please look at this patch and apply it if there are > no objections? > > Thanks in advance, > Vladimir. > > On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Ok, I'm not > as worried - I went back a few days to r447025 and still > have the problem, so it's not from this morning. I guess this has > been masked all along by the logger problem. Noted in JIRA > HARMONY-1560 > > geir > > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: > > > This is completely my fault. > > > > The latest round of patches, while I dutifully do smoke, c-unit and > > kernel tests for each patch, I didn't do any app testing. > > > > I tried to run ActiveMQ, and it breaks with an asset in > > object_handles.cpp : 99 > > > > I'm going to back out the two GC patches I applied and hope for the > > best. > > > > 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] > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
Pavel, Just to be clear, could you please point to some documentation which declares such responsibility? This seems logical and now I recall why I let it to be forgotten ;) 2006/9/25, Pavel Pervov <[EMAIL PROTECTED]>: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray <[EMAIL PROTECTED]> wrote: > > As I understand it, the classpath of the jarred application should include > the > jar file itself and the contents of its Class-Path attribute (if any). You > probably need to create a special class loader for the application and use > that whenever the application (or a library loaded by it) is the > initiator. > -- > Chris Gray/k/ Embedded Java Solutions BE0503765045 > Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ > [EMAIL PROTECTED] +32 3 216 0369 > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testing] HARMONY-995: adding new target to builds for automatic testing
On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Sep 25, 2006, at 5:05 AM, Vladimir Ivanov wrote: > Seems, it will be convenient for automatic (or nightly) building > and testing > Harmony and, may be, newbie who want to look to "what is Harmony > today" > without documentation readingJ. > > If nobody objects I'll prepare patch. That's fine, I think, but I'm just surprised it doesn't do that now... what does it do now? Actually, now 3 targets should be called one-by-one (4 in case of vm) to reproduce development cycle. Of cause, "external tool" can do it but it is seems more reasonable to have this command in the build. Issue http://issues.apache.org/jira/browse/HARMONY-1565 with trivial update was created. 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: http://www.atlassian.com/ > software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray <[EMAIL PROTECTED]> wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > Under what platfrom, what build? On Windows for build I've built from the latest sources (at 449592 revision). Sorry I was mistaken :-(. JAVA_HOME refers to RI and therefore all works. Thanks, Vladimir. Thanks, Vladimir. On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: > > > BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. > > > > Thanks, > > Vladimir. > > > > On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: > >> > >> As for me (and other people) a lot of tests fail for the latest > >> sources > >> (revision 449592). > >> I've run the *build.bat clean; build.bat update; build.bat* > >> command in > >> compliance with comments for *H-1457*. > >> It's very strange for me it mentions here all C-unit tests work fine. > > >> Sorry I cannot confirm this. > >> The detailed investigation showed the patch for *H-1457* is > >> incorrect. > >> I've attached a patch fixing this issue. > >> Thanks Evgueni Brevnov for preparing this patch. After applying these > > >> changes the issue disappeared. > >> > >> Geir, could you please look at this patch and apply it if there > >> are no > >> objections? > >> > >> Thanks in advance, > >> Vladimir. > >> > >> On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> > > >> > Ok, I'm not as worried - I went back a few days to r447025 and > >> still > >> > have the problem, so it's not from this morning. I guess this has > >> > been masked all along by the logger problem. Noted in JIRA > >> HARMONY-1560 > >> > > >> > geir > >> > > >> > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: > >> > > >> > > This is completely my fault. > >> > > > >> > > The latest round of patches, while I dutifully do smoke, c- > >> unit and > >> > > kernel tests for each patch, I didn't do any app testing. > >> > > > >> > > I tried to run ActiveMQ, and it breaks with an asset in > >> > > object_handles.cpp : 99 > >> > > > >> > > I'm going to back out the two GC patches I applied and hope > >> for the > >> > > best. > >> > > > >> > > 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: [EMAIL PROTECTED] > >
Re: [drlvm][gc] HARMONY-1371 applied incompletely
Salikh, this change was reverted back, as it leads to crashes on some smoke tests. Look at the harmony-1371 comments. -- Ivan On 9/25/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: Geir, Ivan, just a heads-up: the patch from HARMONY-1371 was applied incompletely. The below hunk was left out (i.e. it exists in HARMONY-1371, but was not committed to SVN). Is this okay? --- vm/gc/src/init.cpp +++ vm/gc/src/init.cpp @@ -51,7 +51,7 @@ int HEAP_SIZE_DEFAULT = 256 MB; unsigned int prev_mark_phase; bool cleaning_needed = false; -int gc_algorithm = 0; +int gc_algorithm = 30; int gc_adaptive = true; int64 timer_start; int64 timer_dt; -- Ivan 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] my latest round of patches broke something
On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: > As for me (and other people) a lot of tests fail for the latest > sources (revision 449592). > I've run the build.bat clean; build.bat update; build.bat command > in compliance with comments for H-1457. > It's very strange for me it mentions here all C-unit tests work > fine. Sorry I cannot confirm this. It certainly did on my machine after a clean - update build, and then hung on gc.LOS. > The detailed investigation showed the patch for H-1457 is > incorrect. I've attached a patch fixing this issue. > Thanks Evgueni Brevnov for preparing this patch. After applying > these changes the issue disappeared. Where is that patch? it didn't make it through to list - can you just re-open 1457 and attach there? Not I cannot due to I have no permissions for this. Our patch looks like this: Index: apr_thread_ext.c === --- apr_thread_ext.c (revision 449604) +++ apr_thread_ext.c (working copy) @@ -28,14 +28,14 @@ APR_DECLARE(apr_status_t) apr_thread_set_priority(apr_thread_t *thread, apr_int32_t priority) { -HANDLE *os_thread; +apr_os_thread_t * os_thread; apr_status_t status; -if (status = apr_os_thread_get(&((apr_os_thread_t *)os_thread), thread)) { +if (status = apr_os_thread_get(&os_thread, thread)) { return status; } -if (SetThreadPriority(*os_thread, (int)convert_priority(priority))) { +if (SetThreadPriority((HANDLE)os_thread, (int)convert_priority(priority))) { return APR_SUCCESS; } else { return apr_get_os_error(); @@ -50,23 +50,24 @@ // touch thread to flash memory APR_DECLARE(apr_status_t) apr_thread_yield_other(apr_thread_t* thread) { -HANDLE *os_thread = NULL; +apr_os_thread_t * os_thread = NULL; apr_status_t status; -if (status = apr_os_thread_get(&((apr_os_thread_t *)os_thread), thread)) { +if (status = apr_os_thread_get(&os_thread, thread)) { return status; } -if(!os_thread) { -//printf ("detached thread\n"); - return status; -} - //printf("suspending %d\n", *os_thread); -if(-1!=SuspendThread(*os_thread)) { - ResumeThread(*os_thread); - // printf("resuming %d\n", *os_thread); -} else { - //printf("fail to suspend %d\n", *os_thread); -} - return APR_SUCCESS; +if(!os_thread) { +// printf ("detached thread\n"); +return status; +} + +// printf("suspending %d\n", *os_thread); +if(SuspendThread((HANDLE)os_thread) != -1) { +ResumeThread((HANDLE)os_thread); +// printf("resuming %d\n", *os_thread); +} else { +// printf("fail to suspend %d\n", *os_thread); +} +return APR_SUCCESS; } APR_DECLARE(void) apr_memory_rw_barrier() { @@ -79,19 +80,19 @@ FILETIME exitTime; FILETIME kernelTime; FILETIME userTime; -HANDLE *hThread; +apr_os_thread_t * os_thread; SYSTEMTIME sysTime; int res; __int64 xx; __int32 * pp; apr_status_t status; -if (status = apr_os_thread_get(&((apr_os_thread_t *)hThread), thread)) { +if (status = apr_os_thread_get(&os_thread, thread)) { return status; } res = GetThreadTimes( -*hThread, +(HANDLE)os_thread, &creationTime, &exitTime, &kernelTime, @@ -125,13 +126,15 @@ APR_DECLARE(apr_status_t) apr_get_thread_time(apr_thread_t *thread, apr_int64_t* nanos_ptr) { -HANDLE *os_thread; +apr_os_thread_t * os_thread; apr_status_t status; FILETIME creation_time, exit_time, kernel_time, user_time; -if (status = apr_os_thread_get(&((apr_os_thread_t *)os_thread), thread)!=APR_SUCCESS) { + +status = apr_os_thread_get(&os_thread, thread); +if (status != APR_SUCCESS) { return status; } -GetThreadTimes(*os_thread, &creation_time, +GetThreadTimes((HANDLE)os_thread, &creation_time, &exit_time, &kernel_time, &user_time); @@ -141,13 +144,15 @@ } APR_DECLARE(apr_status_t) apr_thread_cancel(apr_thread_t *thread) { -HANDLE *os_thread; +apr_os_thread_t * os_thread; apr_status_t status; -if (status = apr_os_thread_get(&((apr_os_thread_t *)os_thread), thread)) { + +status = apr_os_thread_get(&os_thread, thread); +if (status != APR_SUCCESS) { return status; } -if (TerminateThread(*os_thread, 0)) { +if (TerminateThread((HANDLE)os_thread, 0)) { return APR_SUCCESS; } else { return apr_get_os_error(); Thanks, Vladimir. > Geir, could you please look at this patch and apply it if there are > no objections? > > Thanks in advance, > Vladimir. > > On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Ok, I'm not > as worried - I went back a few days to r447025 and still > have the problem, so it's not from this morning. I guess this has > been
[drlvm][gc] HARMONY-1371 applied incompletely
Geir, Ivan, just a heads-up: the patch from HARMONY-1371 was applied incompletely. The below hunk was left out (i.e. it exists in HARMONY-1371, but was not committed to SVN). Is this okay? --- vm/gc/src/init.cpp +++ vm/gc/src/init.cpp @@ -51,7 +51,7 @@ int HEAP_SIZE_DEFAULT = 256 MB; unsigned int prev_mark_phase; bool cleaning_needed = false; -int gc_algorithm = 0; +int gc_algorithm = 30; int gc_adaptive = true; int64 timer_start; int64 timer_dt; - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
2006/9/25, Chris Gray <[EMAIL PROTECTED]>: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. Right! I had this in mind but forgot somehow :( -- 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: [drlvm] invoking non-trivial jars results in IllegalAccessError
As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Under what platfrom, what build? On Windows for build I've built from the latest sources (at 449592 revision). Thanks, Vladimir. On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: > BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. > > Thanks, > Vladimir. > > On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: >> >> As for me (and other people) a lot of tests fail for the latest >> sources >> (revision 449592). >> I've run the *build.bat clean; build.bat update; build.bat* >> command in >> compliance with comments for *H-1457*. >> It's very strange for me it mentions here all C-unit tests work fine. >> Sorry I cannot confirm this. >> The detailed investigation showed the patch for *H-1457* is >> incorrect. >> I've attached a patch fixing this issue. >> Thanks Evgueni Brevnov for preparing this patch. After applying these >> changes the issue disappeared. >> >> Geir, could you please look at this patch and apply it if there >> are no >> objections? >> >> Thanks in advance, >> Vladimir. >> >> On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> > >> > Ok, I'm not as worried - I went back a few days to r447025 and >> still >> > have the problem, so it's not from this morning. I guess this has >> > been masked all along by the logger problem. Noted in JIRA >> HARMONY-1560 >> > >> > geir >> > >> > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: >> > >> > > This is completely my fault. >> > > >> > > The latest round of patches, while I dutifully do smoke, c- >> unit and >> > > kernel tests for each patch, I didn't do any app testing. >> > > >> > > I tried to run ActiveMQ, and it breaks with an asset in >> > > object_handles.cpp : 99 >> > > >> > > I'm going to back out the two GC patches I applied and hope >> for the >> > > best. >> > > >> > > 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: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
Under what platfrom, what build? On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. Thanks, Vladimir. On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the *build.bat clean; build.bat update; build.bat* command in compliance with comments for *H-1457*. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. The detailed investigation showed the patch for *H-1457* is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > Ok, I'm not as worried - I went back a few days to r447025 and still > have the problem, so it's not from this morning. I guess this has > been masked all along by the logger problem. Noted in JIRA HARMONY-1560 > > geir > > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: > > > This is completely my fault. > > > > The latest round of patches, while I dutifully do smoke, c- unit and > > kernel tests for each patch, I didn't do any app testing. > > > > I tried to run ActiveMQ, and it breaks with an asset in > > object_handles.cpp : 99 > > > > I'm going to back out the two GC patches I applied and hope for the > > best. > > > > 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: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the build.bat clean; build.bat update; build.bat command in compliance with comments for H-1457. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. It certainly did on my machine after a clean - update build, and then hung on gc.LOS. The detailed investigation showed the patch for H-1457 is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Where is that patch? it didn't make it through to list - can you just re-open 1457 and attach there? Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: > This is completely my fault. > > The latest round of patches, while I dutifully do smoke, c-unit and > kernel tests for each patch, I didn't do any app testing. > > I tried to run ActiveMQ, and it breaks with an asset in > object_handles.cpp : 99 > > I'm going to back out the two GC patches I applied and hope for the > best. > > 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] - 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 25, 2006, at 5:05 AM, Vladimir Ivanov wrote: Now I install the B&T infrastructure on the 2 comp's: win and linux. It is woks (with small improvements. the readme.txt was updated to describe it), but I want to discuss adding a new top-level target to the vm/API builds (for example, 'all'). This target will do nothing but depends on - for API build: all = fetch-depends + rebuild + test - for VM build: all = update + clean + build + test Seems, it will be convenient for automatic (or nightly) building and testing Harmony and, may be, newbie who want to look to "what is Harmony today" without documentation readingJ. If nobody objects I'll prepare patch. That's fine, I think, but I'm just surprised it doesn't do that now... what does it do now? 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: http://www.atlassian.com/ software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. Thanks, Vladimir. On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the *build.bat clean; build.bat update; build.bat* command in compliance with comments for *H-1457*. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. The detailed investigation showed the patch for *H-1457* is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > Ok, I'm not as worried - I went back a few days to r447025 and still > have the problem, so it's not from this morning. I guess this has > been masked all along by the logger problem. Noted in JIRA HARMONY-1560 > > geir > > On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: > > > This is completely my fault. > > > > The latest round of patches, while I dutifully do smoke, c-unit and > > kernel tests for each patch, I didn't do any app testing. > > > > I tried to run ActiveMQ, and it breaks with an asset in > > object_handles.cpp : 99 > > > > I'm going to back out the two GC patches I applied and hope for the > > best. > > > > 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: [VOTE] HARMONY-1217 : JNI-style C header file generator (aka 'javah')
+1 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: [drlvm] invoking non-trivial jars results in IllegalAccessError
Perfect. The key was I didn't realize the launcher added the jar to the class path. Thanks geir On Sep 24, 2006, at 11:18 PM, Alexey Varlamov wrote: This is simple now :) - it's a pity a did not look at JarRunner earlier. The launcher adds -Djava.class.path=, so the system classloader become aware of that path. Due to delegation model, the system classloader has precedence over MyLoader. The root cause of problem is incorrect usage of API for MyLoader - JarRunner should call public loadClass(String) instead of protected findClass(String) for MyLoader. And the access modifiers hint this ;) Actually I see no reason to deal with MyLoader at all - system classloader would do fine. -- Alexey 2006/9/25, Geir Magnusson Jr. <[EMAIL PROTECTED]>: On Sep 24, 2006, at 8:09 PM, Gregory Shimansky wrote: > On Sunday 24 September 2006 05:46 Geir Magnusson Jr. wrote: >> On Sep 23, 2006, at 7:46 PM, Ivan Volosyuk wrote: >>> Actually... This is another bug :) >> >> Oh well :) > > I think I've found the cause of this bug. Now what to do with it... Thanks for looking into it so fast. > > 1. Class Foo is loaded by org/apache/harmony/vm/JarRunner$MyLoader > while Bar > is loaded by java/net/URLClassLoader$SubURLClassLoader. Why? I thought they would be in the same classloader, given the fact that I fed the jar to MyLoader... > > 2. The comparison in Resolve.cpp:177 fails because each class > loader in VM has > its own table of packages and thus Foo and Bar while having the > same packages > in name, have different packages in terms of class loading. This > results in > IllegalAccessError. > > I am not sure what actually is wrong, #1 or #2 or both. I think all > user > application classes should be loaded by the same system class > loader unless > user specifies another one. So #1 seems to be the candidate for me. > > -- > Gregory Shimansky, 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] - 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: [VOTE] HARMONY-1217 : JNI-style C header file generator (aka 'javah')
+1 On 9/25/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: +1 Geir Magnusson Jr. wrote: > All is in order and in SVN for Harmony-1217 wrt BCC and ACQ. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][awt] Fonts with negative size.
It was evaluated as "not a bug". But it is clear from its evaluation that negative-sized fonts are treated as positive sized but rotated around their origin, say with implicit transform. I'd suggest to follow this behavior. On 9/23/06, Richard Liang <[EMAIL PROTECTED]> wrote: On 9/23/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > Google said this is the bug of RI in progress [1]. However there is no > distinct resolution yet... > It's reported again Java 1.1.8 more than 3 years agao. I don't think RI will fix this bug. Richard. > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825 > > > 2006/9/23, Richard Liang <[EMAIL PROTECTED]>: > > On 9/22/06, Ilya Okomin <[EMAIL PROTECTED]> wrote: > > > Hi, all! > > > > > > I was playing with fonts and found that Font with negative size can be > > > created on RI. > > > Unfortunately spec keep silence about fonts with negative sizes. > > > On Harmony if font size is negative then it is set to zero. > > > > > > test.java--- > > > import java.awt.*; > > > import java.awt.font.FontRenderContext; > > > > > > public class NegativeFontTest { > > > > > > public static void main(String[] args) { > > > int fontsize=-5; > > > Font localFont = new Font("Arial", 2, fontsize); > > > System.out.println("Size = " + localFont.getSize2D()); > > > > > > System.out.println("Height = " + localFont.getLineMetrics("", new > > > FontRenderContext(null, false, false)).getHeight()); > > > System.out.println("MaxCharBounds = " + localFont.getMaxCharBounds(new > > > FontRenderContext(null, false, false))); > > > } > > > > > > } > > > > > > If you run this test case on RI you can see that output looks quite strange: > > > > > > Size = -5.0 > > > Height = -5.7495117 > > > MaxCharBounds = java.awt.geom.Rectangle2D$Float[x=0.0,y=4.6081543,w=-5.46875 > > > ,h=-5.7495117] > > > > > > > > > Actually, I dont see any sence in negative height and width metrics and > > > I think it is an RI bug. > > > If you try to draw text with such font on RI - nothing is happen, you can't > > > see any text on the component. > > > I've ran 'xfontsel' tool on Linux and there was suggested to choose only > > > positive sized fonts. Also I've looked on the GDI LOGFONT structure > > > description in MSDN and I've seen there again that we deal with absolute > > > height values. > > > > > > Any thoughts on this issue, is it RI bug or not? > > > > We cannot say it's a bug of RI, because the spec does not explicitly > > describe the requirement of font size. > > > > I suggest we follow RI. > > > > Best regards, > > Richard > > > > > > > > Thanks, > > > Ilya. > > > > > > -- > > > -- > > > Ilya Okomin > > > Intel Middleware Products Division > > > > > > > > > > > > -- > > Richard Liang > > China Development Lab, IBM > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Richard Liang China Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the build.bat clean; build.bat update; build.bat command in compliance with comments for H-1457. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. The detailed investigation showed the patch for H-1457 is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Ok, I'm not as worried - I went back a few days to r447025 and stillhave the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560geirOn Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote:> This is completely my fault.>> The latest round of patches, while I dutifully do smoke, c-unit and > kernel tests for each patch, I didn't do any app testing.>> I tried to run ActiveMQ, and it breaks with an asset in> object_handles.cpp : 99>> I'm going to back out the two GC patches I applied and hope for the > best.>> geir>>> -> Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED]> For additional commands, e-mail: [EMAIL PROTECTED]>-Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][jit] possible ABCD bug
On the 0x1EE day of Apache Harmony Naveen Neelakantam wrote: > I've been reading through the ABCD implementation in jitrino, and if > I understand it correctly, I found a bug. I've attached a patch to > fix it. Someone who actually understands the code should verify this. Naveen, you found a secret :) Recently, I spent some time understanding Jitrino's ABCD code too. Now it seems pretty clear, you pinpointed a bug. I did not try the patch on a strong benchmark such as DaCapo, and cannot estimate how much it can give in terms of performance. (Although, it is both a performance and correctness related fix) As you pointed out recently, checking both bounds assumes one comparison in CG. So, we won't get any performance benefit on IA-32 if we remove only one (lower or upper) bound of a 'chkbounds'. > Also, did anyone ever test this ABCD pass? That's a long story. And here is the secret: Jitrino ABCD removes *only* lower bounds checks. Thus, it is useless currently. Well, this is not 100% true :) Sometimes, I saw it removing upper checks, but, probably, very obvious checks. I should have looked into the problem more thoroughly. This is a very sad story, so I decided to look what is happening. The algorithm is *not* easy to read, but what I can say for sure: * it is not the algorithm as in the original paper * it's algorithm applies some more advanced techniques (i.e. analysis of bounds of the kind A*x+B, where A and B are constants, x is a variable) and lacks them * "inequality graph" is not built, thus uncovering some extra limitations * the algorithm assumes all constants to be zero, when proving a check to eliminate. So, I cannot find any evidence for the algorithm to remove an upper check :( I tried the original ABCD example from the paper. And was upset almost like you :) I tried to trigger various switches, but they gave no clue, except a lot of assertions out of the blue. > I ask because I've tried running it on a bidirectional bubble sort > as mentioned in the original paper. The paper mentions that the > pass should be able to prove all of the bounds checks in the sort > method as redundant/ unnecessary. However, when I try running the > abcd pass on a bidirectional bubble sort (attached), none of the > bounds checks are eliminated. well, some actually are: bash$ grep "We can eliminate " naveen.sort.log We can eliminate LB check of I43:chkbounds g195.16 .lt. g8.8 -) g25:tau !!! We can eliminate LB check of I43:chkbounds g195.16 .lt. g8.8 -) g25:tau We can eliminate LB check of I54:chkbounds g32 .lt. g8.18 -) g36:tau !!! We can eliminate LB check of I54:chkbounds g32 .lt. g8.18 -) g36:tau We can eliminate LB check of I64:chkbounds g180 .lt. g8.8 -) g45:tau !!! We can eliminate LB check of I64:chkbounds g180 .lt. g8.8 -) g45:tau We can eliminate LB check of I74:chkbounds g194 .lt. g8.12 -) g55:tau !!! We can eliminate LB check of I74:chkbounds g194 .lt. g8.12 -) g55:tau We can eliminate LB check of I118:chkbounds g82.27 .lt. g8.1 -) g92:tau !!! We can eliminate LB check of I118:chkbounds g82.27 .lt. g8.1 -) g92:tau We can eliminate LB check of I129:chkbounds g80.31 .lt. g8.32 -) g103:tau !!! We can eliminate LB check of I129:chkbounds g80.31 .lt. g8.32 -) g103:tau We can eliminate LB check of I314:chkbounds g196 .lt. g8.5 -) g199:tau !!! We can eliminate LB check of I314:chkbounds g196 .lt. g8.5 -) g199:tau We can eliminate LB check of I294:chkbounds g218.3 .lt. g8.1 -) g185:tau !!! We can eliminate LB check of I294:chkbounds g218.3 .lt. g8.1 -) g185:tau but, you see, only lower bounds! (BTW, I applied your fix, it had no influence on your specific test) ...The code was so buggy and not easy to read, so I decided to implement the original algorithm by myself :) Well, I implemented the algorithm on a given inequality graph. Tested it a bit, and became satisfied on how it works. Now I am working on the IR-to-InequalityGraph transformer. And almost implemented it. At this point there is not a lot to do there to make the code working and eliminating. But, hey, you are the first to talk about ABCD on this list! I am so glad, someone found it too. If you are interested in improving Jitrino's ABCD, I can publish my early code sketches in JIRA, so we could improve the code together ASAP. I would be glad to. What do you think? Anyway, I'll publish my results, but, maybe, a bit later and working. -- 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]
Fwd: [testing] HARMONY-995: adding new target to builds for automatic testing
Now I install the B&T infrastructure on the 2 comp's: win and linux. It is woks (with small improvements. the readme.txt was updated to describe it), but I want to discuss adding a new top-level target to the vm/API builds (for example, 'all'). This target will do nothing but depends on - for API build: all = fetch-depends + rebuild + test - for VM build: all = update + clean + build + test Seems, it will be convenient for automatic (or nightly) building and testing Harmony and, may be, newbie who want to look to "what is Harmony today" without documentation readingJ. If nobody objects I'll prepare patch. 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: http://www.atlassian.com/software/jira
Re: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test
It was me...the build server needs "ant fetch-depends" to get the jetty. I will try to recover it soon. Sorry for the inconvenience caused. Apache Harmony Build wrote: Online report : http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/5763 Build statistics: State: Failed Previous State: Ok Started at: Mon, 25 Sep 2006 09:01:37 +0100 Finished at: Mon, 25 Sep 2006 09:02:10 +0100 Total time: 33s Build Trigger: Schedule Exit code: 1 Building machine hostname: hy2 Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes classlib/make/depends.xml classlib/make/depends.properties Output: Buildfile: build.xml build: [delete] Deleting directory /home/hybld/continuum-working-directory/6/classlib/deploy [echo] Classlib revision is 449596 [echo] Post process: true [echo] JAPI: true [echo] Building with reference jdk/javac [exec] Buildfile: build.xml [exec] clean-java: [exec] clean-bin: [exec] call-modules-all: [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 15 files from /home/hybld/continuum-working-directory/6/classlib/modules/accessibility/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 1 files from /home/hybld/continuum-working-directory/6/classlib/modules/applet/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 41 files from /home/hybld/continuum-working-directory/6/classlib/modules/archive/bin/test [exec] clean-native-includes: [exec][delete] /home/hybld/continuum-working-directory/6/classlib/deploy/include not found. [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 214 files from /home/hybld/continuum-working-directory/6/classlib/modules/auth/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 569 files from /home/hybld/continuum-working-directory/6/classlib/modules/awt/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 233 files from /home/hybld/continuum-working-directory/6/classlib/modules/beans/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] /home/hybld/continuum-working-directory/6/classlib/modules/concurrent/bin/test not found. [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 88 files from /home/hybld/continuum-working-directory/6/classlib/modules/crypto/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 20 files from /home/hybld/continuum-working-directory/6/classlib/modules/instrument/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 162 files from /home/hybld/continuum-working-directory/6/classlib/modules/jndi/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 2 files from /home/hybld/continuum-working-directory/6/classlib/modules/lang-management/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 95 files from /home/hybld/continuum-working-directory/6/classlib/
Re: [classlib][luni]To open warning as error on Linux
Sounds reasonable. Seems the lastest version of GCC is 4.1.x[1], we may download this version and have a try :) [1]http://gcc.gnu.org/ 2006/9/25, Ivan Volosyuk <[EMAIL PROTECTED]>: It helps to maintain code with less potential problems in it. AFAIK, GCC 3.x warnings is just a subset of GCC 4.x warnings. So, if we fix warnings on GCC 4.x the code will compile without warnings on either version of GCC. -- Ivan On 9/25/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote: > If this is a potential build problem do we really need to set this option? > > 2006/9/25, Leo Li <[EMAIL PROTECTED]>: > > Hi, all > > I plan to give a patch that fixed all warning in native code of luni on > > Linux and then set Werror in luni makefile. > > But now I have a problem: Different versions of gcc have different > > definitions of warnings, for example, the file can build on my default > > GCC3.0.4 of RH but fails on GCC4.0.3 of my colleague's ubuntu if I set > > warning as error on. Although I can fix it on GCC4.0.3, what about other > > versions? > > So my question is whether we have our default or reference version of > > GCC?:) -- Ivan Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [VOTE] HARMONY-1217 : JNI-style C header file generator (aka 'javah')
+1 Geir Magnusson Jr. wrote: > All is in order and in SVN for Harmony-1217 wrt BCC and ACQ. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni]To open warning as error on Linux
Thank you, Ivan. I will let it pass GCC4.x. On 9/25/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: It helps to maintain code with less potential problems in it. AFAIK, GCC 3.x warnings is just a subset of GCC 4.x warnings. So, if we fix warnings on GCC 4.x the code will compile without warnings on either version of GCC. -- Ivan On 9/25/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote: > If this is a potential build problem do we really need to set this option? > > 2006/9/25, Leo Li <[EMAIL PROTECTED]>: > > Hi, all > > I plan to give a patch that fixed all warning in native code of luni on > > Linux and then set Werror in luni makefile. > > But now I have a problem: Different versions of gcc have different > > definitions of warnings, for example, the file can build on my default > > GCC3.0.4 of RH but fails on GCC4.0.3 of my colleague's ubuntu if I set > > warning as error on. Although I can fix it on GCC4.0.3, what about other > > versions? > > So my question is whether we have our default or reference version of > > GCC?:) -- Ivan 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] -- Leo Li China Software Development Lab, IBM
Re: [classlib][luni]To open warning as error on Linux
Hi, Alexey: It can help to avoid the situation that Harmony builds successfully on Linux while fails on windows since its -W3 is on as talked in such thread: http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg13806.html On 9/25/06, Alexey Petrenko <[EMAIL PROTECTED] > wrote: If this is a potential build problem do we really need to set this option? 2006/9/25, Leo Li < [EMAIL PROTECTED]>: > Hi, all > I plan to give a patch that fixed all warning in native code of luni on > Linux and then set Werror in luni makefile. > But now I have a problem: Different versions of gcc have different > definitions of warnings, for example, the file can build on my default > GCC3.0.4 of RH but fails on GCC4.0.3 of my colleague's ubuntu if I set > warning as error on. Although I can fix it on GCC4.0.3 , what about other > versions? > So my question is whether we have our default or reference version of > GCC?:) > > > > -- > Leo Li > China Software Development Lab, IBM > > -- 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] -- Leo Li China Software Development Lab, IBM
Re: [classlib][luni]To open warning as error on Linux
It helps to maintain code with less potential problems in it. AFAIK, GCC 3.x warnings is just a subset of GCC 4.x warnings. So, if we fix warnings on GCC 4.x the code will compile without warnings on either version of GCC. -- Ivan On 9/25/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote: If this is a potential build problem do we really need to set this option? 2006/9/25, Leo Li <[EMAIL PROTECTED]>: > Hi, all > I plan to give a patch that fixed all warning in native code of luni on > Linux and then set Werror in luni makefile. > But now I have a problem: Different versions of gcc have different > definitions of warnings, for example, the file can build on my default > GCC3.0.4 of RH but fails on GCC4.0.3 of my colleague's ubuntu if I set > warning as error on. Although I can fix it on GCC4.0.3, what about other > versions? > So my question is whether we have our default or reference version of > GCC?:) -- Ivan 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] Cleaning insides of Class.h header
It is the revision from saturday, september, 23rd. Regards, Pavel. On 9/25/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: Pavel, I glanced at it. Was this patch made on an svn revision number from this week? On 9/23/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > Created Harmony-1558 [1] with the intention to attach all patches to it. > "Step 1" patch attached - interested parties can review. > > Regards, >Pavel. > > [1] https://issues.apache.org/jira/browse/HARMONY-1558 > > > On 7/24/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > > > Hello, all. > > > > I would like to work on cleaning the insides of Class.h header file. > > > > This header is related to internal representation of java class inside > the > > VM. Currently it contains all entities for internal class > representation: > > class itself, constant pool, members (field, method), exceptions > handler, > > vtable and so forth. > > > > First thing I would like to do is to split the file into a group of > files, > > each of which would contain only one entity (and some closely related > > entities, if any). This would produce the following headers: > > 1) Class.h – constant pool and class > > 2) vtable.h – vtable > > 3) class_member.h – field and method entities descriptors, > exception > > handler descriptor > > 4) cci.h – code chunk entity (part of compiled method code) > > > > Second thing to do is to throw away members (and other stuff), which are > > not used anymore and the only reason they are still there is history or > they > > do not belong to these files. > > > > Third thing to do is to make all these entities C++ objects. Currently, > > member variables of all listed entities are used arbitrarily throughout > > DRLVM code. I would like to regularize usage and, also, document > internals > > of these entities. > > > > Certainly, I'll do all these changes step-by-step with little patches > > coming in. > > > > Regards, > >Pavel Pervov > > Intel Middleware Products Division. > > > > > > -- Weldon Washburn Intel Middleware Products Division