When will Java go mainstream like Python?

[Silvio]

"Lawrence D'Oliveiro" <ldo at geek-central.gen.new_zealand> wrote in message 
news:hm4icr$q4o$1 at lust.ihug.co.nz...
> In message <op.u8nfpex8y5e8ok at laptopwanja>, Wanja Gayk wrote:
>
>> Reference counting is about the worst technique for garbage collection.
>
> It avoids the need for garbage collection. It means I can write things 
> like
>
>    contents = open(filename, "r").read()
>
> and know the file object will be immediately closed after its contents are
> returned.
>
> It also means I don’t have to predefine how much memory my program will 
> use.
> A garbage collector will only kick in when the app runs low on memory. On 
> a
> system with dynamic memory allocation, that will not happen until the 
> entire
> system runs low on memory, unless you limit the app to some fixed amount.
> Which is an antiquated way of doing things.
>
> And then there’s caching. Modern CPUs owe most of their speed to 
> assumptions
> that programs will obey locality of reference. Pointer-chasing is a cache-
> hostile activity. Garbage collection involves a lot of pointer-chasing,
> particularly of dead objects that have long since been flushed from the
> cache, compared with reference counting of recently-accessed objects.
> Therefore garbage collection loses performance.

Reference counting is a technique that is only applicable for a subset of 
scenarios GC can handle. RC fails when circular dependencies exist. In an 
ancient past I have worked with RC-based C++ frameworks and they where 
either very restrictive to prevent circular dependencies or ignored them 
resulting in memory leaks.

In addition, for fast create/destroy scenario's (for examples loops that 
allocate objects with single cycle lifetimes) a generational GC is MUCH 
faster than manual malloc/free new/delete code because it enables a 
completely different heap management logic. Reference counting only adds to 
the slowness in this scenario.
You are also incorrect in stating that a GC will only kick in when memory 
becomes scarce. Partial GCs will happen very frequently (thereby 
invalidating your point about caching) and are extremely fast. Only full GCs 
are infrequent and take more time but they will typically run in a separate 
thread.

No general statement about the relative speed of generational GC systems 
versus manual heap management (or the slower variant RC) can be made since 
they have completely different best, general and worse case behavior and 
scenarios.

In response to your original post: please provide links to examples of 
quality benchmark results. There are numerous language speed comparison 
benchmarks that usually put Python in the tail region with Ruby and the 
likes for many different applications. If you have opposing examples then 
you should provide them.

Silvio