Re: Q: controlled mem mgmt in Java

jbuck@Synopsys.COM (Joe Buck)
18 Apr 1997 01:08:46 -0400

          From comp.compilers

Related articles
Q: controlled mem mgmt in Java (Dmitri Bronnikov) (1997-04-16)
Re: Q: controlled mem mgmt in Java jbuck@Synopsys.COM (1997-04-18)
| List of all articles for this month |

From: jbuck@Synopsys.COM (Joe Buck)
Newsgroups: comp.compilers
Date: 18 Apr 1997 01:08:46 -0400
Organization: Synopsys Inc., Mountain View, CA 94043-4033
References: 97-04-085
Keywords: Java, storage

Dmitri Bronnikov <> 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

>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

Post a followup to this message

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