Re: C++ vs Java "new" (no flame war please!)

Lew wrote:
Let's assume you want to create N objects where N is the largest number of
such objects that would fit in available memory.

List <Foo> stuff = new ArrayList <Foo> (N);

mlw wrote:
That's one memory alloc, sure.

Lew wrote:
for ( int x = 0; x < N; ++x )
{
stuff.add( new Foo( getAString() ) );
}

mlw wrote:
The above code is exactly my problem with Java. In C++ I can overload new
and put all the objects anywhere I want, even in to one contiguous memory
block calling malloc merely once and combining the object and the string in
one allocation,

You still need to calculate offsets into that block to fix the start of each individual object. In fact, the code in your custom allocator uses more memory and much more time than would the JVM for the equivalent Java class.

Every memory allocation has overhead, in GCC malloc, it is probably 4 bytes,
8 bytes on 64 bit systems. So, if you have fairly small objects, and lots
of them, a good chunk of memory will be eaten up with malloc overhead. If
you have a small object with a string, you will have two memory
allocations!

Your C++ class did a copy of the string. A Java class likely would not, since Strings are immutable, so it would only do one allocation for the Foo object and none for the String. Even if one did copy the String, the time overhead of the Java allocation and copy would be much less than for the C++ code you showed. For one thing, the Java code would only loop through the String once, not twice as in your C++ code; it would have no need to calculate "strlen()". The memory overhead would be no different since a copy is a copy is a copy.

But as I said, the Java code would not copy the String, so the point is moot. One allocation and less memory overhead in the Java version.

Obviously this is a rare problem, but it is a problem none the less.

I don't see what the problem with Java is. What is the bad effect that concerns you with Java?

Is it memory overhead? Objects in Java take up only as much space as they take.

Is it time overhead? Java object allocations run on the order of 10-20 machine cycles. Initialization of the object takes some time, perhaps, but that would be true with your custom allocator as well.

Your description seems to delineate a problem with C++ that your custom allocator handles, but I see nothing of this relevant to Java.

-- Lew
.

Relevant Pages

  • Re: forth and virtual memory
    ... too, maybe even the same order, so ordering the blocks by allocation ... on systems with too little memory ... What Java is known for, and what it actually does, are two distinct ... My measurements indicate that some of the benchmarks (from SpecJVM98, ...
    (comp.lang.forth)
  • Re: HLA Lib
    ... All memory allocation is freed up when the process quits. ... reduce need to resize blocks for 98% string operations. ... HLA strings already consume. ...
    (alt.lang.asm)
  • Re: C++ vs Java "new" (no flame war please!)
    ... of such objects that would fit in available memory. ... memory and much more time than would the JVM for the equivalent Java ... The "allocation" ... If you have a small object with a string, ...
    (comp.lang.java)
  • Re: D gets it right
    ... >releasing memory properly using good old free, ... Java and ... (define (make-adder k) ... stack-based allocation method like that espoused by propoents of RAII, ...
    (comp.programming)
  • Re: alloca / _alloca / dynamic stack memory
    ... // Return Pointer to allocated memory ... but does not free memory until the ... // memory allocation method ... What does String have for data? ...
    (microsoft.public.vc.language)