On 28/07/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:
Alex Blewitt wrote: > There's a heck of a lot wrong with intern()My original observation was that interning makes perfect sense for localized log messages, because the code like println(MessageBundle.get("how are you?"));
Yes, but I disagree with your conclusion; to me, it doesn't make sense. Which is better, performance for printing out a message, or memory requirements? Like I said, unless you are in a seriously time-critical loop (in which case, you'd have to wonder why printing out any kind of message at all is desired), the time taken to look up the message from the bundle is really going to be of no/little concern. However, by hard-coding the message like this, you're guaranteeing that the VM will intern() the string "how are you?", even if it never prints this message out (because it's in the constant pool). Many, many, messages are never printed out in the course of a normal code flow; yet they're all cached in the intern() pool, and in fact, have to be because of the way that constant pools are supposed to work. So this 'perfect sense' is trading off speed of lookup of a message for memory requirements, even if it's never used. If it's never used, the speed of lookup is irrelivant (think exception messages like 'Invalid URL format') but it still takes up space. Reading the Eclipse Performance Bloopoers is a very good summary of the techniques taken by the Eclipse development team to try and limit the amount of memory used, and should be read by anyone with an interest in intern()'d strings, or for that matter, messages in general: http://wiki.eclipse.org/index.php/Performance_Bloopers Importantly, it explains why the Eclipse NLS class uses static string variables to refer to messages, and not to String literals for exactly this reason. If you use a static string variable that is dynamically initialised from a properties file, you only take the memory up when you need to refer to that message (e.g. in the constructor of an exception in an exceptional condition). Furthermore, because it's a dynamically read in string, it doesn't pollute the intern() pool, and thus when the class is unloaded, the string is unloaded too. Once a String is intern()'d, it's like a memory leak -- you'll never see that memory again. Lastly, the Eclipse approach ensures that there are no String values saved as keys anywhere in the system -- they're always referred to by the static field contents. So regardless of whether they're intern()'d or not, you are always comparing by reference anyway. In other words, all of the benefits of intern(), and yet none of the disadvantages. Remind me again why we're not using this method for doing messages in Harmony? Alex. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
