Java 9 Tech Preview Planned For Fedora 27

[ldo17]

Why doesn’t Java add reference-counting, and only fall back to garbage collection when it has no choice?

Look at how a more modern language like Python does it, or even hoary old Perl. This is why they can make so much more efficient use of memory than Java can manage. Also reference-counting is less cache-hostile, so it could be faster.

[DanLamb]

Why doesn’t Java add reference-counting, and only fall back to garbage collection when it has no choice?

Look at how a more modern language like Python does it, or even hoary old Perl. This is why they can make so much more efficient use of memory than Java can manage. Also reference-counting is less cache-hostile, so it could be faster.

I would have thought of Go for a fast, low memory, low latency alternative to Java's GC.

For a good article on GC, that compares Go to various Java GC options: https://blog.plan99.net/modern-garba...n-911ef4f8bd8e

[Khrundel]

Why doesn’t Java add reference-counting, and only fall back to garbage collection when it has no choice?

Look at how a more modern language like Python does it, or even hoary old Perl. This is why they can make so much more efficient use of memory than Java can manage. Also reference-counting is less cache-hostile, so it could be faster.

JVM is already using tricks to spare GC some work. One of them is "escape analysis": when VM knows that some object created and used locally, it can allocate this object on stack.
Reference counting is a different thing. With GC you have to do a lot of work during collection phase, but it is very cheap to allocate small objects and to copy references. You don't need to increment/decrement counters, which is costly, especially when doing this thread-safe way. Because of defragmentation during GC phase, you can organize the heap simpler way, using stack-like "just increment pointer" allocation instead of stack unfriendly search of large enough block in free blocks list. So, it looks like hybrid allocation scheme will have flaws of both approaches, which can waste all possible savings.

[bug77]

With Android Java, you're right. JDK 9 changes are basically VM and tooling level changes that doesn't impact the Android Runtime.

Android games and some written in Java usually don't use the Android Java Runtime, they use RoboVM, which is an AOT compiler than turns Java apps into Android binaries.

Last year, Xamarin bought RoboVM, then Microsoft bought Xamarin and promptly shut down RoboVM.

JDK9 has an out of the box AOT compiler and will hopefully be much better than RoboVM ever was. In that case, such non-Android Java development will grow.



With the bitter lawsuits, I expected Google to replace Java with either Go or a new Google language. I'm surprised they haven't.

Very few Android apps/games actually use Java. They all use some intermediate toolkit.

I agree with everything, but there are a lot of useful apps that are not games (calendars, file managers, launchers). For those, Java's relatively short TTM is a boon.

Yes, I'd be surprised if WebView doesn't already do HTTP/2 too. I assume it does.
However, this is not about WebView, this is about performing JSON requests to web APIs.
WebView is if your application has a web user interface, but often you have a native Android interface with native Android widgets and the server interact with a remote server using JSON.

True, but for JSON HTTP/2 push capability isn't all that useful.
When you get a request for a web page, pushing the associated JS, CSS maybe even images is a no brainer. But when you get a request for a JSON entity (REST resource most likely), what would you push?
There are a few other advantages to HTTP/2 and those will benefit all clients. But that's not the meat of HTTP/2. As such, I'll be glad when I get HTTP/2, but I'm not bothered if I don't get it promptly.

[ldo17]

JVM is already using tricks to spare GC some work.

It is still a pain in the bum. You have to limit the maximum heap size that the program uses, otherwise it will happily consume all available memory.

Did you know that the default heap size for Java on Android is small, just a few tens of megabytes? With no way to change it (that I’m aware of) on an unrooted system? If you want to use more RAM than that, you have to resort to native code.

I mention that because it seems the only way Google could think of to keep Java’s memory appetite in check.

With GC you have to do a lot of work during collection phase, but it is very cheap to allocate small objects and to copy references.

Things work fine until the GC kicks in, then you get this stutter.

You don't need to increment/decrement counters, which is costly, especially when doing this thread-safe way.

Think of the Linux kernel, which uses reference-counting heavily to manage its internal objects. It seems to do that very efficiently, particularly on today’s multicore, heavily-threaded machines. So efficiently that, if you were to suggest they use garbage collection instead, you would get laughed out of the room.

So, it looks like hybrid allocation scheme will have flaws of both approaches, which can waste all possible savings.

Yet Java is known for being resource-hungry, Python and Perl are not.

[Khrundel]

Things work fine until the GC kicks in, then you get this stutter.

Overall GC performance is not that bad. The problem is "stop the world" situations, when all app threads waiting for GC to complete its work, so JVM evolves in direction to waste more memory and CPU time, but shorten STW phases or split them to many subphases. New default G1GC is intended to do this.

Think of the Linux kernel, which uses reference-counting heavily to manage its internal objects. It seems to do that very efficiently, particularly on today’s multicore, heavily-threaded machines. So efficiently that, if you were to suggest they use garbage collection instead, you would get laughed out of the room.

My point is that RCs can't replace GC in Java completely, so they won't free VM from necessity to trace heap to find living objects, so even not so big cost of updating references counts and searching for free block will be added to cost of GC.

Yet Java is known for being resource-hungry, Python and Perl are not.

You can't compare scripting languages with Java. Java is intended to replace C/C++ in production, while Perl and Python usually offload most work to native libraries.

[ldo17]

You can't compare scripting languages with Java. Java is intended to replace C/C++ in production, while Perl and Python usually offload most work to native libraries.

That’s a very peculiar thing to say, since “scripting languages” are supposed to be less efficient but quicker to get simple things working in than conventional “programming languages”. So here you are admitting that Java has the low productivity of a “conventional” language, without the corresponding benefit of greater efficiency.

[Khrundel]

That’s a very peculiar thing to say, since “scripting languages” are supposed to be less efficient but quicker to get simple things working in than conventional “programming languages”. So here you are admitting that Java has the low productivity of a “conventional” language, without the corresponding benefit of greater efficiency.

What? I'm not fan of java, but comparing with Python and Perl... According to benchmark game site, java performs 10 to 50 times faster than Python 3 and Perl. My point is when interprier is so hoplessly slow as Python or Perl, you simply will not use this language to do any heavy job. So you won't need to create some complex data structures, so there won't be many garbage to collect.
By the way, unlike Python and Perl, Javascript has high performance engines. And, surprise, at least V8 uses simple GC, without some clever GC with reference counting.

[ldo17]

According to benchmark game site, java performs 10 to 50 times faster than Python 3 and Perl.

Which “benchmark game site” would that be? Did they measure the speed before or after Java’s garbage collector kicked in?

[Khrundel]

Which “benchmark game site” would that be? Did they measure the speed before or after Java’s garbage collector kicked in?

http://benchmarksgame.alioth.debian.org/.
When python program 20 times slower than java, nothing can save it. Unless you think JVM GC eats 90% of run time.