[kaffe] Calendar performances
Hi all, I'm using a call to rightNow = Calendar.getInstance(); and the first call need 44 seconds to accomplish (kaffe 1.1.6 - MIPS 400MHz machine) the following calls are fast (less than 1 second, I did not measure them) Is there some reason for this - is there some initialization - can it be avoided (I just need system date and time). thanks giammy -- Gianluca Moro http://groups.yahoo.com/group/embeddeditalia/ ISCRIVITI alla Mailing List Italiana su LINUX EMBEDDED [EMAIL PROTECTED] Visit http://ilpinguino.altervista.org/ ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Win CE port
Hi, Thanks for your answer. I'm usually a Unix guy wondering around the embedded Windows world. Dalibor Topic wrote: Philippe Laporte wrote: Hi, Has anyone got some WinCE porting experiences to share? Salut Philippe, Hallo Rainer, Personally, I've got Kaffe's CVS HEAD from a few weeks ago to build and run under Cygwin, though I had some problems in the interpreter when I worked on it a few weeks ago. See FAQ.Win32 in CVS head for details how to configure it and to get it build. Why does cygwin say they don't work on CE? Is there a branch soomewhere? Is there a bigger picture than POSIX/ANSI C dependencies being layered on CE vs Win 32? The link at http://www.rainer-keuchel.de/wince/kaffe.html, I'm not sure how good it is. CElib does not appear to be supported much... I've CC:ed Rainer, he may be able to say more about its current status. What library did you use to achieve POSIX compatibility? What toolchain? I've loooked around on the web a bit, and there is a pocketgcc toolchain that uses newlib in Debian. [1] It's fro arm-wince-pe, though, so you'd have to find another one if you have a MIPS or SuperH device. Can you give the link, please? Any other links to start with? I wouldn't imagine this to be so mysterious, or? Thanks a lot, Philippe Laporte Software Gatespace Telematics Första Långgatan 18 41328 Göteborg Sweden Phone: +46 702 04 35 11 Fax: +46 31 24 16 50 Email: [EMAIL PROTECTED] ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: Re: [kaffe] kaffe porting error message.
Thank you for your help. I have a question about this error. If I can't use jthread, I only add to --with-threads=unix-pthreads in the configure. What do I do to resolve this problem? Regard. donggi im -- [ Original Message ] -- Subject: Re: [kaffe] kaffe porting error message. Date: Thu, 19 Jan 2006 04:14:47 +0100 From: Dalibor Topic [EMAIL PROTECTED] To: 임동기 [EMAIL PROTECTED] Cc: kaffe@kaffe.org 임동기 wrote: Hi~ I have done porting job in the XScale target board. When I execute kaffe vm, I have this error message. kaffe-bin: jthread.c:1986: reschedule: Assertion `currentJThread == lastThread' failed. What's the problem? I think you've found a bug in Kaffe/and or your configuration: make sure that the SP_OFFSET is set correct for your cpu architecture, if you plan to use jthreads. See http://www.mail-archive.com/kaffe@rufus.w3.org/msg02400.html for en example. xscale boards come in different sp_offset variations, afair. cheers, dalibor topic [인기 만화 편지지] 양영순,박소희,메가쑈킹~ 만화편지지로 재미있는 겨울을! ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Calendar performances
On Thu, Jan 19, 2006 at 12:27:49AM -0800, Gianluca Moro wrote: Hi all, Ciao Gianluca, I'm using a call to rightNow = Calendar.getInstance(); and the first call need 44 seconds to accomplish (kaffe 1.1.6 - MIPS 400MHz machine) the following calls are fast (less than 1 second, I did not measure them) Is there some reason for this - is there some initialization - can it be avoided (I just need system date and time). I think the reason for the excessive startup time you are seing is due to Calender being time zone and locale specific, and loading the data for all time zones is expensive, as well as loading the data for all locales. The classes to look into are libraries/javalib/external/classpath/java/util/Locale.java and libraries/javalib/external/classpath/java/util/TimeZone.java (on CVS head). My guess would be that loading all the properties data in libraries/javalib/external/classpath/resource/gnu/java/locale is what's slowing you down, so you could be able to work around that by using a different initialisation method, or only defining the localized resources you really need in the locale database. cheers, dalibor topic thanks giammy -- Gianluca Moro http://groups.yahoo.com/group/embeddeditalia/ ISCRIVITI alla Mailing List Italiana su LINUX EMBEDDED [EMAIL PROTECTED] Visit http://ilpinguino.altervista.org/ ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Win CE port
On Thu, Jan 19, 2006 at 11:31:43AM +0100, Philippe Laporte wrote: Hi, Thanks for your answer. I'm usually a Unix guy wondering around the embedded Windows world. Salut Philippe, Dalibor Topic wrote: Philippe Laporte wrote: Hi, Has anyone got some WinCE porting experiences to share? Salut Philippe, Hallo Rainer, Personally, I've got Kaffe's CVS HEAD from a few weeks ago to build and run under Cygwin, though I had some problems in the interpreter when I worked on it a few weeks ago. See FAQ.Win32 in CVS head for details how to configure it and to get it build. Why does cygwin say they don't work on CE? Is there a branch soomewhere? Oh, I am sorry for the misunderstanding, there is no Cygwin/CE that I am aware of, I was using Cygwin on win32. I believe that Rainer's got Win32/NT binaries of KaffeCE on his site, though, too, so my assumption is that Win32 is not very far away from WinCE in terms of behaviour or APIs necessary to port Kaffe. i.e. if you can get Kaffe working fine on Cygwin and on Mingw32, it should not be very hard to get it working fine on WinCE, then, either. Is there a bigger picture than POSIX/ANSI C dependencies being layered on CE vs Win 32? Debian's pocketgcc for arm-wince-pe comes with newlib, which provides a posixy libc for embedded platforms, afaik. You can get the package in debian with apt-get install pocketgcc, I assume, and more information on it is available from http://packages.debian.org/unstable/devel/pocketpc-gcc. You can find information on newlib on sources.redhat.com/newlib . Note that the above toolchain is for windows CE devices using an ARM processor, if your target device uses something else, you'll have to port the toolchain, or find another one. If you are interested in a command line JVM, that should be enough to get you started, since Kaffe allows you to use its own portable threading, jthreads on systems without pthreads. If you need graphical output, you'll need to port additional support libraries too, like X11, Gtk+ or Qt4, or to look at the Windows CE AWT backend in Mysaify VM. cheers, dalibor topic The link at http://www.rainer-keuchel.de/wince/kaffe.html, I'm not sure how good it is. CElib does not appear to be supported much... I've CC:ed Rainer, he may be able to say more about its current status. What library did you use to achieve POSIX compatibility? What toolchain? I've loooked around on the web a bit, and there is a pocketgcc toolchain that uses newlib in Debian. [1] It's fro arm-wince-pe, though, so you'd have to find another one if you have a MIPS or SuperH device. Can you give the link, please? Any other links to start with? I wouldn't imagine this to be so mysterious, or? Thanks a lot, Philippe Laporte Software Gatespace Telematics F?rsta L?nggatan 18 41328 G?teborg Sweden Phone: +46 702 04 35 11 Fax: +46 31 24 16 50 Email: [EMAIL PROTECTED] ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: Re: [kaffe] kaffe porting error message.
On Thu, Jan 19, 2006 at 07:48:28PM +0900, ?? wrote: I've got a lot of trouble reading HTML formatted mail in my command line mail reader, so I hope I have managed to pick out the right bits from your e-mail. If you could convince your mail client to send your posts in plain text, that may fix that problem. As far as I can tell, your problem may be associated with, for example, a bad sp_offset setting for your kernel/cpu/glibc/toolchain. You can find out the right sp_offset by building and running the sp_offset.c code in the developers subdirectory on your target platform. cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] 1.1.7-rc1
On Wed, Jan 18, 2006 at 11:26:31PM +0900, Kiyo Inaba wrote: Hi Dalibor, Please give it a try on the platforms you're intertested in, and report back how well it works, or doesn't for you. Thanks to make Release Candidate. Thank you, Kiyo. I am now checking this with several different CPU/OS right now. (As you know, some machines take long long time to do that ;-) Thanks. But, before telling some result of these old machine, I noticed latest version does not work for cross compiling environment. The reason is missing configure flag, which can not be tested for cross environment. The flag is ac_cv_file__proc_self_maps and I plan to add this for config.frag files tomorrow. Since I don't have enough infomation for each CPU/OS whether proc maps are supported, I just put this to be 'yes' for all OS. This is just for make cross compilation work, and if someone find this is not adequate, please fix for the specific port. I am sorry for having missed looking at this before. That breakage was introduced by me delegating the binreloc check in the configure script to binreloc.m4. In the default mode (auto), it checks for /proc/self/maps in order to determine if binreloc support will work, or not. such a check does not make sense when cross-compiling since the check can be only performed on the compilation build host, not on the target. Instead of declaring manually ac_cv_file__proc_self_maps ourselves for different platforms in config.frag, I'd propose the following solution: in configure.ac, before calling AM_BINRELOC, I'd add a test if we are cross-compiling and in that case set ac_cv_file__proc_self_maps to false, print a warning message for the user to configure with --enable-binreloc explicitely if he wants binreloc support on the platform she is cross-compiling to, and call AM_BINRELOC. Unless the user has explicitely requested --enable-binreloc, support for it will be configured out transparently when cross-compling, but it'll work as before for native builds. I'll post a patch once I have it working for me :) Kiyo P.S. And maybe, I will update 'FAQ.cross-compiling' for 'rt.jar' etc... thanks! I'll add a note about Dan Kegel's crosstools, I've found it to be useful for GNU/Linux crosscompiler builds for various CPU architectures. cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] 1.1.7-rc1
Hi Dalibor, I am now checking this with several different CPU/OS right now. (As you know, some machines take long long time to do that ;-) Thanks. For the time being, regression against rc1 looks ok for both m68k/ linux or netbsd, and ia32/netbsd. Testing for sh3/linux (or possibly netbsd) will be done after proc_self_maps modification. Instead of declaring manually ac_cv_file__proc_self_maps ourselves for different platforms in config.frag, I'd propose the following solution: ... I'll post a patch once I have it working for me :) Of course if we can make more sofisticate solutions for that, I am very happy. I'm looking forward about that. P.S. And maybe, I will update 'FAQ.cross-compiling' for 'rt.jar' etc... thanks! I'll add a note about Dan Kegel's crosstools, I've found it to be useful for GNU/Linux crosscompiler builds for various CPU architectures. My first intention is to update 'rt.jar' issue to reflect latest situation, but then I noticed if our default class lib compilation environment becomes to use jikes, we need not native kaffe for cross compilation, which makes the document much simpler ;-) Dan Kegel's crosstools description should be helpful for people who are not so familiar with cross compiling. By the way, have you tried to use these tools? As far as I am concerned, I prefer to build them from scratch... Of course, for netbsd, I use cross compilation tools supplied as default. I think this is another good reason why netbsd is THE os for software developers ;-) Kiyo ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
