From: <cg...@cd...> - 2000-05-16 11:01:42
|
boi...@ex... said: > I'm doing my weekly planning, so it must be Monday :) Jikes, how distgustingly efficient. What are you, a projectleader or something? ;-). I'm trying to stay on the "barely healthy" side of things - hayfever season started, and the medication doesn't exactly make you fit, and a week of extremely dry are got me a sore throat to boot. So my apologies that I didn't have the spare energy to start documenting things. > Would you happen to have a reusable LRU-style cache written in Java? It's in the JVM - soft references. Works like a charm, and as the garbage collector decides what gets kicked out when, you don't need any arbitrary cache sizes and all that complex stuff. > BTW, Jim Alateras also reported a corruption using version 0.081 so > there's a bug lurking somewhere... beurk! Did he enter it on sourceforge? I feel it's important to show the world that things are moving - we had a couple of hundred downloads, but not much feedback... Regards, Cees -- Cees de Groot http://www.cdegroot.com <cg...@cd...> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B Forge your CipherSaber and list it: http://www.xs4all.nl/~cg/ciphersaber/ |
From: <cg...@cd...> - 2000-05-17 18:50:12
|
boi...@ex... said: > "Works like a charm"? That's not what my experience tells me. There > are a few cases where I would use weak refs but generally, I think > it's a poor design choice to rely on them. Weak refs? Soft refs! (or am I the one mixing them up this time? Normally= , I = can keep them apart :-)) Ok, I buy your JDK 1.1 argument, but for a JDK1.= 2 = environment soft refs are really a better choice. It's a cache so you rea= lly = don't care anyway what is thrown out when, and by soft-reffing your cache= = entries all your caches will be treated as one giant LRU cache, with the = oldest entries in any given "local" cache being kicked out first. That's = quite = hard to do by yourself, and caching stuff yourself, not taking into = consideration what's going on elsewhere in the JVM might be considered a = bit = selfish... > salud, amor, dinero :) =A1y el tiempo para gastar lo! Cees -- = Cees de Groot http://www.cdegroot.com <cg...@cd...>= GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B Forge your CipherSaber and list it: http://www.xs4all.nl/~cg/ciphersaber/= |
From: Alex B. <boi...@ex...> - 2000-05-18 16:59:46
|
Cees de Groot wrote: > > Weak refs? Soft refs! (or am I the one mixing them up this time? Normally, I > can keep them apart :-)) I was using a loose language. Soft refs are a specialization of weak refs which happen to be freed by the GC before you run out of memory, instead of being collected more-or-less as soon as no strong refs point to the object. To quote the JDK 1.2 spec: "All soft references to softly-reachable objects are guaranteed to have been cleared before the virtual machine throws an OutOfMemoryError. Otherwise no constraints are placed upon the time at which a soft reference will be cleared or the order in which a set of such references to different objects will be cleared. Virtual machine implementations are, however, encouraged to bias against clearing recently-created or recently-used soft references." > Ok, I buy your JDK 1.1 argument, but for a JDK1.2 > environment soft refs are really a better choice. It's a cache so you really > don't care anyway what is thrown out when, and by soft-reffing your cache > entries all your caches will be treated as one giant LRU cache, with the > oldest entries in any given "local" cache being kicked out first. That's quite > hard to do by yourself, and caching stuff yourself, not taking into > consideration what's going on elsewhere in the JVM might be considered a bit > selfish... I don't agree on the "you really don't care anyway what is thrown out when" part. The raison-d'être for this cache is to control what to keep in memory. In fact, the JDK documentation on soft refs clearly states that if you want a sophisticated cache, you should implement an MRU cache yourself: "Thus a sophisticated cache can, for example, prevent its most recently used entries from being discarded by keeping strong referents to those entries, leaving the remaining entries to be discarded at the discretion of the garbage collector." So I'm going to move on with a simple MRU-style cache which will do for JDK 1.x and later add another one for JDK 1.2 and up. regards, alex. -- Alex Boisvert, XJ2EE Project Manager Exoffice Technologies, Inc. http://www.exoffice.com mailto:boi...@ex... |
From: Alex B. <boi...@ex...> - 2000-05-16 20:59:32
|
Cees de Groot wrote: > > boi...@ex... said: > > I'm doing my weekly planning, so it must be Monday :) > > Jikes, how distgustingly efficient. What are you, a projectleader or > something? ;-). Hey, that's the title they gave me. The story doesn't say if you become a manager because you're organized or you become organized after managing unorganized people. > I'm trying to stay on the "barely healthy" side of things - hayfever season > started, and the medication doesn't exactly make you fit, and a week of > extremely dry are got me a sore throat to boot. So my apologies that I didn't > have the spare energy to start documenting things. So rumors about drugs making you a sharper programmer are false!?! I'll stick to wine and chocolate then, they taste better. Seriously, take care and don't you write any documentation under the influce of drugs. > > > Would you happen to have a reusable LRU-style cache written in Java? > > It's in the JVM - soft references. Works like a charm, and as the garbage > collector decides what gets kicked out when, you don't need any arbitrary > cache sizes and all that complex stuff. "Works like a charm"? That's not what my experience tells me. There are a few cases where I would use weak refs but generally, I think it's a poor design choice to rely on them. Granted, the JVM might know about low memory conditions but it doesn't understand the dymanics of the running application. Given a choice, I would choose deterministic behavior over some seemingly free magic happening behind the scenes. Okay, now that I've expressed my fears :) I would add that I'd like to keep compatibility with JDK 1.1.x, so soft references are not really an option. I may be a bit out of fashion on this one but I think supporting platforms like Macs and many Unix flavors is important. > > BTW, Jim Alateras also reported a corruption using version 0.081 so > > there's a bug lurking somewhere... beurk! > > Did he enter it on sourceforge? I feel it's important to show the world that > things are moving - we had a couple of hundred downloads, but not much > feedback... All he got was a "double get on block 0" exception after running for a while. I'll ask him to report the bug on SourceForge. salud, amor, dinero :) alex. -- Alex Boisvert, XJ2EE Project Manager Exoffice Technologies, Inc. http://www.exoffice.com mailto:boi...@ex... |