Re: Do you use a garbage collector (java vs c++ difference in "new")
"Lew" wrote
However, Roedy did not mention a "global pointer". You introduced
that into the conversation, and have yet to explain what you mean by
that.
Chris Thomasson wrote:
I mean atomically incrementing a global pointer off a common base of
memory. This is basic memory allocator implementation 101. You know
this. Perhaps Roedy was talking about a distributed model. What say you?
I'll repeat what I said, but in different words in hope that I am clearer.
What Roedy meant is that Java allocators simply increment the pointer to
available memory by the size of the allocation. Details of *which* memory
pointer, and any synchronization needed if any, are left to the JVM. This
process is in-built to the semantics of the 'new' operator. One does not
explicitly manage any of that. I could not tell you if the operation involves
a global pointer or not without checking the specifics of a particular JVM
implementation, of which there are several from different vendors.
Java can use both, and all methods in between. You don't necessarily
want to send atomic mutations to a common location. Perhaps Roedy meant
N counts off the bases of multiple memory pools. I don't know. I was
speculating. I hope I was wrong. I thought he meant count off a single
location. That's not going to scale very well... You can break big
It scales just fine. The American IRS accepts millions of
electronically-filed tax returns in just a few days through such a system.
buffer into little ones and distributed them over threads... Then the
"count" would be off a thread local pool instead of a global set of
whatever... I have created a lot of allocators, and know a lot about
some of the caveats.
Then I suggest you google for how a particular JVM that interests you does it.
I assure you that in production systems the world over the volume scales
quite well, so the JVM writers must be addressing those issues to which you
refer. This is true for all the big JVM players of which I'm aware.
However, in the context of this conversation the point is moot. As Java
programmers we have *no* direct control over that aspect of the JVM. As Java
programmers, all we can do is invoke 'new'. We *never* deal programmatically
with how the JVM handles the issues you mention.
On the flip side, JVMs provide rich sets of options to select and tune the GC
algorithms, but this has nothing to do with the issues you raise.
Is that finally clear? That Java programmers do not write custom allocators?
That Java programmers know by the very language definition itself that 'new'
is thread-safe? That Java programmers know from JVM documentation and
practical experience that whatever technique they use, these JVMs manage to
scale fabulously? That all the points you raised are *completely* subsumed by
the definition and action of the 'new' operator?
If not, I have no idea how one could possibly make these points any clearer.
--
Lew