Re: Q: controlled mem mgmt in Java

Dmitri Bronnikov <Bronikov@ic.net> writes:
>Java seem to be very single-minded in regard of memory allocation for
>objects. This entails a huge run-time overhead when functions (OK,
>methods) have a few local small objects, which I would allocate
>directly on stack if I were using C/C++/etc.


I don't see what's stopping a Java implementation from using the stack
for storage of local objects when it can assure that there will be no
references to the objects left when the function exits. If some sizes
are variable, the implementation can still allocate on the stack by
using an approach similar to "alloca", that favorite of GNU
programmers.


>Java also does not allow
>a programmer to use various free-store memory management techniques
>for objects. For example, I like to use "arenas".


Yes, but the Java compilation system is free to analyze the program in
whatever level of detail that may be required, and then produce code
that uses a variety of memory management schemes.


>Today, as various Java machines claim they are closing up on compiled
>C/C++ speed, this seem to be important.


I have a C++ application that does a lot of manipulation on reference
counted objects. That code would be faster if I could rely on garbage
collection instead, so the speed tradeoff can go both ways.


--
-- Joe Buck http://www.synopsys.com/pubs/research/people/jbuck.html
--

Return to the comp.compilers page.
Search the comp.compilers archives again.