Re: Adding const to java

"Joachim Durchholz" <joachim_d@gmx.de>
6 Nov 2002 11:47:16 -0500

          From comp.compilers

Related articles
Adding const to java lashari@hotmail.com (Ghulam Lashari) (2002-10-24)
Re: Adding const to java onderkarpat@yahoo.com (Onder Karpat) (2002-11-06)
Re: Adding const to java joachim_d@gmx.de (Joachim Durchholz) (2002-11-06)
Re: Adding const to java titzer@expert.ics.purdue.edu (Ben L. Titzer) (2002-11-06)
Re: Adding const to java hagge@isde.uni-hannover.de (Nils Hagge) (2002-11-06)
Re: Adding const to java C.vanReeuwijk@twi.tudelft.nl (Kees van Reeuwijk) (2002-11-06)
| List of all articles for this month |
From: "Joachim Durchholz" <joachim_d@gmx.de>
Newsgroups: comp.compilers
Date: 6 Nov 2002 11:47:16 -0500
Organization: Compilers Central
References: 02-10-101
Keywords: Java
Posted-Date: 06 Nov 2002 11:47:16 EST

Ghulam Lashari wrote:
> I have implemented "const" modifier in Java Programming Language. The
> semantics of const are similar to that of C++. I am trying to experiment if
> there is any usefulness of this modifier for example in gc etc. I am looking
> for some opinions/suggestions here about what domains of the usefulness of
> this modifier can/should be explored (for example in Virtual Machine
> runtime).


Main point: there is no perceptible difference between a reference to
a const object and the object itself. Copying can be safely optimized
so that just a reference is copied. (This is what makes functional
languages efficient in the first place.)


Optimization is easier if a function is known not to modify its
parameters, and known not to access potentially-nonconstant external
data. The compiler can safely assume that the function will always
return the same results for the same set of parameters, so it can
optimize quite aggressively via inline expansion or the reverse,
commen subexpression elimination. Aliasing is not an issue - it's
simply irrelevant whether a constant object is aliased. This removes
one of the more important barriers for optimization.


I'm not sure how much of this is actually applicable to Java or its
VM. The language was clearly designed to be imperative, and the VM is
tailored for the language; it's easy to lose constness by indirect
means. (Say, introspection. Or the VM generating a new, visibly
different object each time by some means. Ensuring constness becomes
more difficult as more potentially-nonconst internals are exposed.)


Regards,
Joachim


Post a followup to this message

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