Earlier quoted context omitted.
J9 has had one-word headers for years now. I think this article was already out of date in 2012 when it was published.
That sounds interesting. Do you have source that you can share?
[deleted]
From Java code to Java heap (2012)
81–88 of 88 posts
Re: From Java code to Java heap (2012)
#82Earlier quoted context omitted.
Actually it's worse. You're more likely to have hash collisions and if you have enough of them you'll overflow into a red-black tree which has an even higher memory footprint. If you care about memory footprint use Eclipse Collections.
> You're more likely to have hash collisions You are? I know they introduced the tree nodes as fallback if you have a bad hashing algorithm or malicious inputs, but that doesn't mean the hash collision rate got worse by default.
Yes you are because HashMap.hash(Object) was changed.
Re: From Java code to Java heap (2012)
#83Earlier quoted context omitted.
> You're more likely to have hash collisions You are? I know they introduced the tree nodes as fallback if you have a bad hashing algorithm or malicious inputs, but that doesn't mean the hash collision rate got worse by default.
Yes you are because HashMap.hash(Object) was changed.
That is only matters if your keys had badly distributed hashes in the first place.
Re: From Java code to Java heap (2012)
#84Earlier quoted context omitted.
Yes you are because HashMap.hash(Object) was changed.
That is only matters if your keys had badly distributed hashes in the first place.
Uhm no. The hash code of my keys may be perfectly distributed but then HashMap#getNode comes along and masks most of my bits away. HashMap#hash(Object) is supposed to make the impact of the masking less bad.
Re: From Java code to Java heap (2012)
#85Earlier quoted context omitted.
That is only matters if your keys had badly distributed hashes in the first place.
Uhm no. The hash code of my keys may be perfectly distributed but then HashMap#getNode comes along and masks most of my bits away. HashMap#hash(Object) is supposed to make the impact of the masking less bad.
If your hashes are perfectly distributed, as in each bit having a 50% probability of being 1, independent of all other bits, then the low order bits will be just as random as the high order bits, no "making the impact less bad" required.
Re: From Java code to Java heap (2012)
#86Earlier quoted context omitted.
First of all, that's a very small domain. I can similarly say that C++ is an "also ran" in business server-side applications. Second, I don't think that Watson, Spark and H2O qualify as merely "also ran".
>I can similarly say that C++ is an "also ran" in business server-side applications Absolutely you can, because it's true. C++ usage has declined dramatically in the last 10 years. It's no longer used as a mainstream language for business applications (something it was never good at). >Second, I don't think that Watson, Spark and H2O qualify as merely "also ran". Spark and H2O don't even qualify as also rans in the s…
> Core algorithms in C++. That's the pattern.
One reason they do that (that's what leading Java people at Google told me), is that their core libraries need to integrate with all their codebases, some are in Java, some in C++, and some in Python. Another is indeed "intrinsic", but:
> But these are the most interesting, most innovative and fastest growing domains. Those who really specialize in these areas overwhelmingly use C++.
I generally agree (as an algorithms and C++ guy myself, although I now use Java for tricky algorithms, too, because I do concurrent data structures, and those really benefit from a GC), but the languages the algorithms-people use have often been distinct from what the industry at large uses, and that's what we're talking about.
> It doesn't work.
Well, I guess H2O would beg to differ. As to data layout, you're right that's being addressed as we speak.
> Java is falling back in most new application areas.
Those application areas have always existed, Java has never been a leader in those sectors, they're not growing, and Java has still been the most successful language ever. Look, we're not talking Java vs. C++ here. We're talking Java vs. Haskell, Erlang, Go etc.. Those alternatives have even less success than Java in all the areas you mention.
> If the answer is no, then that language is not going to be viable for a lot of other tasks as well.
That is provably the wrong yardstick. Java has never been the best choice for a browser, even while being by far the most used language in the history of computing. We're not counting each type of task equally, but multiplying each task by the number of people involved in doing it.
Re: From Java code to Java heap (2012)
#87Earlier quoted context omitted.
>I can similarly say that C++ is an "also ran" in business server-side applications Absolutely you can, because it's true. C++ usage has declined dramatically in the last 10 years. It's no longer used as a mainstream language for business applications (something it was never good at). >Second, I don't think that Watson, Spark and H2O qualify as merely "also ran". Spark and H2O don't even qualify as also rans in the s…
> Core algorithms in C++. That's the pattern. One reason they do that (that's what leading Java people at Google told me), is that their core libraries need to integrate with all their codebases, some are in Java, some in C++, and some in Python. Another is indeed "intrinsic", but: > But these are the most interesting, most innovative and fastest growing domains. Those who really specialize in these areas overwhelmin…
>That is provably the wrong yardstick. Java has never been the best choice for a browser, even while being by far the most used language in the history of computing.
I should have been clearer about what I think browsers are a good yardstick for. They are a yardstick for choosing a language that is viable if your product can only succeed if it uses computing resources within a very narrow margin of the optimum.
Browsers are an interesting instance of such a product, because they need complex in-memory data structures, they use a ton of memory, they need low level access to hardware and they are soft realtime systems.
But that's by no means a contradiction to Java (and very similar languages) being the most popular language on earth. I see no reason why that should change any time soon.
The only thing that the JVM really lacks compared to C#, Go and Swift is value types. If that's being worked on, I hope it's being worked on fast because it is a big deal.
Re: From Java code to Java heap (2012)
#88Earlier quoted context omitted.
> Core algorithms in C++. That's the pattern. One reason they do that (that's what leading Java people at Google told me), is that their core libraries need to integrate with all their codebases, some are in Java, some in C++, and some in Python. Another is indeed "intrinsic", but: > But these are the most interesting, most innovative and fastest growing domains. Those who really specialize in these areas overwhelmin…
>That is provably the wrong yardstick. Java has never been the best choice for a browser, even while being by far the most used language in the history of computing. I should have been clearer about what I think browsers are a good yardstick for. They are a yardstick for choosing a language that is viable if your product can only succeed if it uses computing resources within a very narrow margin of the optimum. Brows…
> They are a yardstick for choosing a language that is viable if your product can only succeed if it uses computing resources within a very narrow margin of the optimum.
Absolutely. HotSpot is indeed the wrong platform for memory constrained environments, as are most GCed runtimes (although JVMs, including versions of HotSpot are used in embedded devices quite a lot, for applications that don't require the best possible use of resources).
I myself have used a real-time version of HotSpot (realtime Java -- RTSJ -- has support for scoped and nested arena-allocated memory) in a hard-realtime, safety-critical missile defense system. It ran on large servers, but current work on RTSJ also targets embedded devices (see https://www.aicas.com/cms/en/rtsj). I don't think this would be a great hit, but there aren't great hits in that market, anyway.
> If that's being worked on, I hope it's being worked on fast because it is a big deal.
Most of the HotSpot team (and not just them) are dedicated to value types as part of Project Valhalla[1], and some resources are directed towards Project Panama[2], that's supposed to be a fast bridge between JVM and native code (essentially replacing JNI with something that's both faster and much easier to write). Java 9 is already feature-complete, but value types are scheduled for Java 10 (maybe panama, too).