Notice that they call it "low pause", not "pause free". There are truly pause-free algorithms, and people who need them. Brokerage systems, eg, need response in the 10s of milliseconds, and a single GC can disrupt a thousand transactions.
iSeries had the SPECjbb crown for several years running, first with its own JVM and then with the IBM J9 portable JVM. Was finally displaced by J9 running on other hardware (as the iSeries hardware was getting out of date). Sun did eventually build a special "IBM killer" box to reclaim the crown by throwing hundreds of processors at the problem (and building hundreds of tuning parameters into the JVM), but it was an artificial configuration. On Aug 3, 9:12 pm, Bob Kerns <r...@acm.org> wrote: > Well, perhaps this illustrates your second point, but: > > http://tinyurl.com/sun-concurrent-gc > > Or it may be that they're not concurrent enough for you. Concurrency > isn't an absolute, and there are various ways of describing the upper > bounds on how much delay a concurrent algorithm can impose on other > threads. (Your point about stringent response time requirements > suggests this may be your issue with calling it concurrent). > > GC benchmarking is hard work and tricky, and I haven't done it in a > long time. I appreciate the anecdotal data; do you have benchmarks > behind it? You've aroused my curiosity about the current state. > > I have generally been more concerned with compatibility in huge code > bases rather than performance differences (which can generally be > overcome with hardware -- not concurrency, though), so I've mostly > avoided non-Sun JVMs when possible. But I like that there are > alternatives of increasing quality. > > Especially given recent corporate history... > > Thanks. > > On Aug 3, 6:07 am, DanH <danhi...@ieee.org> wrote: > > > Well, none of Sun's implementations are concurrent -- they all force > > the application to stop for a time. They're not generally well- > > designed for LARGE applications (eg, a fast 8-way running a heavy > > transaction system), or anything with really stringent response time > > requirements. The IBM iSeries Java implementation ran rings around > > Sun's, and the newer IBM portable Java implementation runs rings > > around the iSeries implementation. > > > One of the problems with Sun's GC scheme is the vast number of > > parameters -- no one understands them, or how to set them for a given > > set of circumstances (especially if those circumstances vary > > dynamically). > > > On Aug 2, 9:57 pm, Bob Kerns <r...@acm.org> wrote: > > > > OT, but I'll bite. > > > > What do you consider a really good GC setup? > > > > Sun's GC is good enough that I would hesitate to make blanket > > > statements that it is better than X or worse than X. (Though I will > > > say that the newer Sun GC implementations are clearly better than the > > > older ones). There are a lot of different parameters to evaluate a GC > > > by -- and not just CPU overhead. > > > > I don't ask in order to dispute your choice, BTW -- just to understand > > > what you're considering a good GC and why -- and perhaps learn of a > > > really good GC I don't know about! > > > > (It's been a while, but I've implemented, debugged, and maintained a > > > number of GCs over the years, and worked with many of the true > > > pioneers in the field of GC. So you can see why I'm curious). > > > > On Aug 2, 12:53 pm, DanH <danhi...@ieee.org> wrote: > > > > > "(don't get me started on GC based languages)" > > > > > I know it's off-topic, but I have to say something. Having done large > > > > applications in both I much prefer GCed languages (provided the GC is > > > > well implemented). More robust and less overhead (yes, faster), with > > > > fewer ways for the programmer to shoot himself in the foot. > > > > (Unfortunately, Sun's GC implementations are only mediocre, so it's > > > > possible you've never seen a really good GC setup.) > > > > > On Aug 1, 2:33 pm, RichardC <richard.crit...@googlemail.com> wrote: > > > > > > My background is C and C++ ... 25 years and no longer counting :) > > > > > > So I had some ingrained expectations when I started learning Java; > > > > > amongst them was the expectation that the Java language would support > > > > > conditional compliation. > > > > > > I have had to learn to live without conditional compliation. The only > > > > > area where I really miss having a lanugage constuct like "#ifdef" is > > > > > when I need to remove instrumentation and/or debugging code. I now > > > > > write less of this type of code and try to remember to mark what I do > > > > > wite with a "remove me" comment, which gets picked up by the Eclipse > > > > > to-do list. I then remove it during my pre-QA code review. > > > > > > I have yet to feel the need to use conditional compilation to deal > > > > > with the often quoted "platform fragmentation" as the differences in > > > > > the platforms mostly impacts the amout of time I spend testing and I > > > > > have yet to write ANY code that differs by supported hardware. Using > > > > > the resource qualifiers has been all I have needed to do so far. > > > > > > I still don't like some aspects of the Java language (don't get me > > > > > started on GC based languages) but Android is much more than just a > > > > > language and writing off a complete platform for one feature you > > > > > consider missing is very strange position to take. > > > > > > On Jul 31, 11:09 pm, sblantipodi <perini.dav...@dpsoftware.org> wrote: > > > > > > > I'm sorry for my rude and really not too much kind speaking, > > > > > > but I can't belive that android doesn't support preprocessor. > > > > > > > I can't think on mobile programming without preprocessor, too many > > > > > > different configurations, > > > > > > think only to LVL and android market and preprocessor could be > > > > > > useful... > > > > > > Ok we can live without it, but codes becomes really unelegant... > > > > > > Sincerely I really don't like the non preprocessor way but > > > > > > unfortunantly, > > > > > > masses told that android is good and I need to develop on it :) > > > > > > > On Jul 31, 10:58 pm, TreKing <treking...@gmail.com> wrote: > > > > > > > > On Sat, Jul 31, 2010 at 3:00 PM, sblantipodi > > > > > > > <perini.dav...@dpsoftware.org>wrote: > > > > > > > > > How can you develop on a mobile without preprocessing? > > > > > > > > Quite easily, actually. > > > > > > > > > Sure android is really good for fart app, but what else? > > > > > > > > Is this is a serious question? Have you browsed through the > > > > > > > Android Market > > > > > > > (as painful as that is)? There's a lot more out there than "fart > > > > > > > apps". > > > > > > > > > I don't want to troll but I really can't understand why I heard > > > > > > > > many developers saying "viva android" when google released the > > > > > > > > first buggy > > > > > > > > SDK. > > > > > > > > Probably simply because it's an alternative to iPhone. > > > > > > > > Now, someone with your experience developing for so many devices > > > > > > > can surely > > > > > > > adapt to not having a preprocessor. It's good for many things but > > > > > > > definitely > > > > > > > not a necessity and will certainly not cripple you when making an > > > > > > > Android > > > > > > > App. > > > > > > > > If you're personally that attached to having a preprocessor, no > > > > > > > one is > > > > > > > forcing you to develop on Android. > > > > > > > > Good luck. > > > > > > > > --------------------------------------------------------------------------- > > > > > > > ---------------------- > > > > > > > TreKing <http://sites.google.com/site/rezmobileapps/treking> - > > > > > > > Chicago > > > > > > > transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
