Hey all, Just a few comments on the inline keyword and it's effectiveness. I would fear that having a develop who many have little understanding of hotspot would abuse such a keyword. I would fear that this abuse would cause the resulting code produced by javac to surpass limits that can prevent the bytecode from being jit'ed. In most cases, as Dick pointed out, the keyword isn't needed because hotspot will aggressively inline trivial methods. The larger the method, the more likely that it won't be inlined and the more likely that it may not be jit'ed. The limit on compilation is dictated by the number of ideal nodes needed by Hotspot's high level intermediate representation (SSA, CFG combined with call counts for clients and Sea of Nodes (a variant of SSA) combined with CFG, call counts and a VDG for server). Other constraints include method size (35 byte codes), depth of nesting (9). Having the compiler synthetically create large methods goes against the coding style of use small methods that drives Hotspot's optimizations. Charlie Nutter spends a lot of his time making sure that JRuby produced bytecodde that will not break the optimizers in HotSpot.
On the question of System.gc(). The spec states that the VM may ignore the call. In fact, the VMs don't ignore the calls. The calls are synchronized and will run one after the other. Since back to back GC calls don't do much they don't tend to last very long. Even so, they are very disruptive to overall application throughput as you end up parking mutators @ safe points, winding up GC threads only to have them wind down and then releasing mutators that all need to be rescheduled. And all of this for little or no gain. For this reason we have been battling the RMI guys to quit making calls to System.gc(). The response has been to back off the frequency of calls from once a minute to once every 5 minutes and now it's down to once every 30 minutes. From their point of view, they need the call to run when they call it so having the JVM say, nope, not going to do it, wouldn't work. On the question of finalization I'm going to say that finalization does exactly what it was intended to do and for those purposes it works very well. The newer JVM will parallelize the process in that it will use more than 1 helper thread. So, the problem isn't really with finalization, it's just gotten a bad name when people were looking for free(). On this point, I will happily defend Mark Reinhold's work. it's not that bad, just don't abuse it. But doesn't that go for just about everything else? On the question of Strings, StringBuffer/Builder and copying char arrays. Sorry to say that this is still a huge performance drain in many applications. It's the only place where I miss c pointers ;-). Hotspot rarely does the right thing when it comes to string and string manipulation. It's javac that makes the biggest impact (string1 + string2 is converted to using StringBuilder and so on). So here are a few rules when working with strings. Rule #1, don't copy them or force them to copy themselves. Rule #2, use a flyweight instead of a copy Rule #3, don't copy them or force them to copy themselves. Rule #4, use System.arraycopy, it is the most efficient way to copy a primitive array. Regards, Kirk -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
