[kaffe] about wait and notify
Hi to everyone, I've got a doubt about the behaviour of wait/notify methods at the JVM level. This doubt came in my mind after I noticed a misbehaving program which was using such methods. By the way here's the problem: running a program which executes a notify() call on a monitor, I noticed two different behavior between kaffe and sun JVM. While the former (1.0.5) executes rightly, that means suspend the notifier thread and resume waiting threads just after the notify call, the latter didn't: it continued the execution of the notifier thread untill re-schedulation. Now I'd like to know if this is true (i.e., the two JVMs act differently on thread synchronization) and is a design aspect. If so can anybody tell me why there's this difference? Thanks, Luca -- Luca Ferrari, [EMAIL PROTECTED] ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] about wait and notify
On Monday 24 November 2003 09:02, Luca Ferrari wrote: Hi to everyone, I've got a doubt about the behaviour of wait/notify methods at the JVM level. This doubt came in my mind after I noticed a misbehaving program which was using such methods. By the way here's the problem: running a program which executes a notify() call on a monitor, I noticed two different behavior between kaffe and sun JVM. While the former (1.0.5) executes rightly, that means suspend the notifier thread and resume waiting threads just after the notify call, the latter didn't: it continued the execution of the notifier thread untill re-schedulation. Now I'd like to know if this is true (i.e., the two JVMs act differently on thread synchronization) and is a design aspect. If so can anybody tell me why there's this difference? Kaffe's behaviour is correct. See http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#notify(): !-- begin quote -- public final void notify() Wakes up a single thread that is waiting on this object's monitor. If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation. A thread waits on an object's monitor by calling one of the wait methods. The awakened thread will not be able to proceed until the current thread relinquishes the lock on this object. The awakened thread will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened thread enjoys no reliable privilege or disadvantage in being the next thread to lock this object. This method should only be called by a thread that is the owner of this object's monitor. A thread becomes the owner of the object's monitor in one of three ways: By executing a synchronized instance method of that object. By executing the body of a synchronized statement that synchronizes on the object. For objects of type Class, by executing a synchronized static method of that class. Only one thread at a time can own an object's monitor. !-- end quote -- Read the second paragraph very carefully! If Sun's VM is behaving exactly as you describe then they're not according to spec. However I suspect that this is not the case: if you put a sleep(1) after the notify() you should see that the waiting thread is indeed blocked until the notifying thread leaves the synchronized block. Different implementations of the monitor construct can differ in the way they handle competition between threads of equal priority. Giving preference to threads which have just woken from a wait(), at the expense of any thread which just called notify(), is a possible policy but it's not the only one. Correctly written code which uses monitors schould not depend on details such as this. So you may have found a bug in Sun's monitor handling; you almost certainly have a bug in your code; but Kaffe appears to be doing the Right Thing. IMHO. Regards Chris Gray ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] about wait and notify - PS
P.S., There's a good discussion of various types of monitor implementation at http://www.cse.mrt.ac.lk/lecnotes/semester/level4/cp/papers/chandanaandnilan.pdf. Almost all of the monitors they describe would be valid implementations of the Java wait/notify construct. Enjoy, Chris ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: [Cp-tools-discuss] How to run gjdoc with kaffe
Dalibor Topic [EMAIL PROTECTED] writes: Brian Jones wrote: Arnaud Vandyck [EMAIL PROTECTED] writes: Thanks, not sure how many are watching the cp-tools list from classpath. All the tools need some TLC. What's a TLC? Sorry, Tender Love and Care. Brian -- Brian Jones [EMAIL PROTECTED] ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: [Cp-tools-discuss] How to run gjdoc with kaffe
Brian Jones [EMAIL PROTECTED] writes: Dalibor Topic [EMAIL PROTECTED] writes: Brian Jones wrote: Arnaud Vandyck [EMAIL PROTECTED] writes: Thanks, not sure how many are watching the cp-tools list from classpath. All the tools need some TLC. What's a TLC? Sorry, Tender Love and Care. Or tender loving care. Nic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Planning for 1.1.3 release
On Fri, 21 Nov 2003 19:50:19 +0100 Dalibor Topic [EMAIL PROTECTED] wrote: Hi Jim, Jim Pick wrote: Hi, It's getting to close to that time again. Isn't having a regular release schedule fun? Yep. I'd actually propose a faster release schedule: once a month after 1.1.3. There is so much changing every two months, that the steps between releases are quite huge, so that people following developer releases instead of CVS may have a harder time reporting bugs based on releases only. I originally hoped to do the developer releases monthly, but I find that it usually takes an entire weekend to get it out, so I'm happier with the two month schedule, just from a personal time commitment perspective. I imagine that when the big merging settles down, it should be less of an issue. This should be the last development release before we get serious about putting together a real production release. Here's the dates I have penciled in for that: Sunday, January 18, 2004 - Feature Freeze for 1.2.0 Sunday, January 23, 2004 - Release Candidate - 1.2.0-rc1 Sunday, February 1, 2004 - Release Candidate - 1.2.0-rc2 Sunday, February 8, 2004 - Release 1.2.0 (Production Release) I'm not so optimistic about a stable release that soon, as I don;t think we should really cut that one based on time passed alone, but also define a list of features we want to see in, as well as platforms we want to see run, applications we want to offically list as supported in 1.2 etc. For example, I think we shouldn't release 1.2 before the switch to GNU Classpath is completed. Okay, I think some release goals would be a great thing to have. On the other hand, I don't want to have 1.0.7 on the website as our production release for too much longer, so I think we should still pick a date. Eighteen months between production releases is already a long time. If we slip on the goals, then we can postpone the release. Since we don't have dedicated developer resources, we've got to be careful that the slippage doesn't get out of hand, or the release will never happen. So we should keep the goals pretty minimal. I believe that a real solid, supported production release would really encourage a lot more people to give Kaffe a try, and to get more involved. A perpetual stream of unsupported developer releases won't do that. Let's postpone setting a date for the production release until after 1.1.3 is out. Maybe we'll do a 1.1.4 development release. We need to have a discussion about what should constitute the release goals for the production release. I think that will be easier once we have some decent documentation that shows where we are. Given the moving target nature of what we are doing, we might want to identify a core set of APIs, ports and features that we support, and mark the rest of the stuff as experimental/unsupported. It would be nice to identify certain applications and certify that certain versions of them work on the Kaffe production release. I'm glad to hear it's actually working for something, browsing the list traffic I sometimes catch myself thinking: how are we ever going to fix all these bugs ... ;) But I guess that's just the effect of kaffe getting better, and more people trying it out where it hasn't been tried out before (or for a long time ;) That's so true... :-) Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] ThreadState regression test
Hi, I built from CVS this morning (i386/Linux/jthreads), and the ThreadState regression test failed with this: lt-kaffe-bin: ../../../../../kaffe/kaffe/kaffevm/systems/unix-jthreads/jthread.c:2207: jmutex_unlock: Assertion `tid-status != 1' failed. I tried again, and the test succeeded. It's definitely an intermittent thing. Try doing this at your shell prompt in tests/regression: $ (while true; do make check TESTS=ThreadState.java || exit 1; done) I wasn't able to reproduce my failure, but... For me, sometimes the test returns quickly, and sometimes it doesn't. So I think this regression test is turning up something, even though it usually says it is passing. Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] ThreadState regression test
On Mon, 24 Nov 2003 08:12:43 -0800 Jim Pick [EMAIL PROTECTED] wrote: $ (while true; do make check TESTS=ThreadState.java || exit 1; done) I wasn't able to reproduce my failure, but... For me, sometimes the test returns quickly, and sometimes it doesn't. So I think this regression test is turning up something, even though it usually says it is passing. I'm trying this again, and now I can't even reproduce my own bug report, in the exact same tree. The tests are running consistently for me now. Hmmm. Very weird. I'll keep trying, but I'm not sure if my bug report is real or not yet -- I wouldn't spend a lot of time trying to reproduce it, since it seems to have gone away for me now. I hope it's not flakey hardware... Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Documentation
Ciao Gerlando, Gerlando Falauto wrote: Hi everyone, I haven't read the list for a few months now, so I don't know if there have been any developments from the documentation front. Anyway, my thesis (due in a few days) includes some useful information (well at least I guess it might be useful to other people) about the project, especially the JIT workings. Some of the information might not be 100% percent accurate. Although I guess there wouldn't be enough time to make adequate corrections to the thesis, I hope some of you (Dalibor? Tim? Jim?) might be willing to give it a read anyway. While I'm not very well educated on kaffe's VM core, having just hacked on a few bits ocassionally, I'd love to give it a read anyway. ;) As far as I'm concerned, I'd like to package some decent reference for starters before oblivion comes to me. Yes, please! That would be very welcome. You should get in touch with Jim, who also wants to revamp kaffe's documentation. At least to save newbies from the discouragement of an undocumented bulk of about 80,000 lines of platform-independent C code for the core virtual machine, 17,000 lines of C and 110,000 lines of Java code for the class library, and 34,000 lines of platform-dependent C code distributed among 10 different architectures. Well that was 1.0.7, I don't know what's changed since then. It's more than 110,000 lines of java, by now ;) Please let me know what you guys think, if I should send a document to the list, and in what format. It would be best to post a link to the document in PS/PDF format. cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: [Cp-tools-discuss] How to run gjdoc with kaffe
Hi Chris, Chris Gray wrote: On Sunday 23 November 2003 20:19, Dalibor Topic wrote: Brian Jones wrote: Arnaud Vandyck [EMAIL PROTECTED] writes: Thanks, not sure how many are watching the cp-tools list from classpath. All the tools need some TLC. What's a TLC? Dali, TLD is a wonderful healing medicine not available from regular pharmacists, or even from dodgy purveyors on the internet. A top level domain? ;) TLC stands for tender, loving care. Yeah, I figured it couldn't stand for a girl band from the 90's [1], a TV channel [2] or some kind of 4x4 vehicle[3]. I also thought briefly about Tcl, but rejected that, too ;) [1] http://www.mtv.com/bands/az/tlc/artist.jhtml [2] http://tlc.discovery.com/ [3] http://www.tlc4x4.com/ ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] java 1.4
I just have a quick question if the current kaffe version is compatible with java1.4 api or not. Thanks, Kien ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] java 1.4
KIEN LE wrote: I just have a quick question if the current kaffe version is compatible with java1.4 api or not. It's not compatible, as kaffe hasn't passed the Java 1.4 TCK (there is no such TCK available to free software projects). It lacks some APIs of Java 1.4, but offers free implementations of many APIs found in 1.4. For details, see [1]. cheers, dalibor topic [1] http://japi.sab39.org/htmlout/h-jdk14-kaffe.html ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe for Debain on IA-64
Hello, I am looking for a kaffe package for IA-64 archtecture with Debain (woody). Could some one send me a link, since I could not find one. thanks a lot regards -Balaji ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: [GNU Crypto] Re: gnu-crypto.m4. was: new jalopy available
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 hello Dalibor, On Mon, 24 Nov 2003 05:16 am, Dalibor Topic wrote: Raif S. Naffah wrote: On Sat, 22 Nov 2003 10:51 am, Dalibor Topic wrote: ... p.s. is there some kind of gnu-crypto.m4 file for automake to add a --with-gnu-crypto option to it? I'd love having a simple way to chuck in GNU crypto into kaffe without having to bother with those weird U.S. crypto laws, as kaffe's CVS server is located in California. ... things to consider are: * building gnu crypto is effectively building three jars/libraries: one is the gnu-crypto per se (incl. the JCE Adapters), the other two are javax-crypto and javax-security (callbacks and sasl). So we have three seperate jar files, right? correct. ... Then we need a way to put those in the bootclasspath of the calling VM. i need to double check this but from memory you only need the javax-crypto.jar only on the bootclasspath iff kaffe exhibits the same behaviour as the jdk1.4; otherwise it only need to be accessible from the classpath (similar to any other jar). ... The VM will need to figure out the location of the jar files to add to it's bootclasspath. Let's say we have --with-gnu-crypto[=PATH-TO-JAR-LOCATION] as an API. yes. if the optional PATH-TO-JAR-LOCATION is omitted, then [the | a] default list of destinations would be searched, incl. /usr/local/gnu-crypto. (see the _GNU_CRYPTO_WITH_CLASSPATH macro (lines 119+ in http://savannah.gnu.org/cgi-bin/viewcvs/gnu-crypto/gnu-crypto/acinclude.m4?rev=1.11content-type=text/vnd.viewcvs-markup). otherwise the designated path, and only that path, is considered. if/when the expected jars are found in the location, the macro: a. prints a message that it found, or not, the expected jars; b. sets, as you suggest later the two ac variables: USE_GNU_CRYPTO, and GNU_CRYPTO_HOME (or similar). Maybe even a --with-gnu-crypto-cvs=PATH-TO-GNU-CRYPTO-CVS-CHECKOUT i'm doubtful of the value of this since we (GNU Crypto) always build outside the CVS directory. but you may have some ideas that would work around this situation. if not i'd leave this feature to a followup release :-) API later for those among us who like building from CVS checkouts ;) So basically, I'm thinking about two APIs (macros), one for JARs, and another for rebuilding GNU Crpyto from CVS. I'll concentrate in the first, as that one seems to be easier to do as a prototype, and with lessons from that one, it should be easier to build the other. agree. * once installed in a location (default is /usr/local/gnu-crypto) it should be straightforward to construct the different options/switches needed by the kaffe build script from the contents of that location. I have the following in mind: --with-gnu-crypto should set USE_GNU_CRYPTO as an autoconf variable, and PATH_TO_GNU_CRYPTO_JARS. Then, we can use one to check if kaffe should use GNU crypto, and the other to adapth the bootclasspath in the kaffe driver script, kaffe.in. agree. * it would be nice to be able to re-use most, if not all, of the generated options/switches of such an m4 library with other VM providers; e.g. kissme and jikes rvm. The options/switches depend on the options/switches from the GNU crypto configure.in you want the projects utilising GNU Crypto to be able to change. If there are any of them that make sense once you've uild the JAR files, we should list a set of --enable-gnu-crypto-something switches to allow the VM to enable those features. again, the fact that we build outside the CVS directory, IMO makes it hard to chain build GNU Crypto with other projects. on the other hand, i think what we have discussed so far would allow easy integration of GNU Crypto jars with every VM provider; i.e. once GNU_CRYPTO_HOME is set, and depending on the requirements of the specific VM, the appropriate jars can be constructed as part of the bootclasspath (or equivalent) and/or the plain classpath. if you think this is worth it, let's continue this thread on the GNU Crypto list. I've cc:ed the kaffe mailing list, as I assume kaffe will provide the testbed for this type of integration. much appreciated :-) i'll delay the release until we have this working. p.s. if there is a Debian packager out there who is capable/willing to help us deliver the library as a debian package, pls. let me know. Wasn't Morgon Kanter working on that? [1] What happened to that effort? a recent email sent almost two weeks ago is still unanswered, so i presume per is busy with something else. cheers; rsn -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Que du magnifique iD4DBQE/wb2c+e1AKnsTRiERAy3qAJiIIFGUhIS3u/U3BzRd3cJ5tp47AJ9lKNLW HdUVr6UMe3zB1WMkMCeBow== =NqiN -END PGP SIGNATURE- ___ kaffe mailing list [EMAIL PROTECTED]
[kaffe] Re: GregorianCalendar fixes
Mark Wielaard wrote: Hi, Since I am not a GregorianCalendar expert I was hoping that someone could review the following patch which I have in my tree from Ito Kazumitsu. He and I wrote a couple of mauve test cases which are fixed by this and I see no new failures. But people didn't seem to be completely comfortable with it back in Augustus/September. It would be nice if we could create even more test cases to make sure that nothing else breaks and to have a ChangeLog entry for this patch (Ito?). Don't really have have time to learn about Calendars so I am just re-posting this patch in the hope that someone can review it. I am not expert enough for a review ;) But here the results: http://gcc.gnu.org/ml/gcc-testresults/2003-11/msg00990.html CHeers, Andreas ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: [GNU Crypto] gnu-crypto.m4
On Sat, 22 Nov 2003 10:51 am, Dalibor Topic wrote: I'd love having a simple way to chuck in GNU crypto into kaffe without having to bother with those weird U.S. crypto laws, as kaffe's CVS server is located in California. Actually, these weird crypto laws are not specific to the U.S. The follwing states are currently participating in the Wassenaar Arrangement: Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Republic of Korea, Romania, Russian Federation, Slovakia, Spain, Sweden, Switzerland, Turkey, Ukraine, United Kingdom and United States. The participating states implement the Wassenaar Arrangement in national laws and regulations. These may or may not be identical with the text of the arrangement. General info; contact lists of national bodies http://www.wassenaar.org/ List of Dual Use Goods and Technologies And Munitions List Category 5, Part 2: Information Security [Specifies the technical criteria, such as key lengths, for crypto software to be considered dual-use technology] http://www.wassenaar.org/list/wa-list_02_1cat5p2.pdf General Software Note [excludes software in the public domain from the control regime] http://www.wassenaar.org/list/wa-list_02_1gtnandgsn.pdf Text on the FSF website about the Wassenaar Arrangement [They call it Wassenaar Agreement] http://www.gnu.org/philosophy/wassenaar.html -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: GregorianCalendar fixes
: == Mark Wielaard [EMAIL PROTECTED] writes: : and to have a ChangeLog entry for this patch (Ito?). How about this? 2003-11-25 Ito Kazumitsu [EMAIL PROTECTED] * java/util/GregorianCalendar.java (getLinearTime): avoid counting the leap day of the leap year twice. (computeFields): corrected so that the first week of month is not 0 but 1. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
