In jsa@alexandria (Jon S Anthony) writes: > In article kst@thomsoft.com (Keith Thompson) writes: > > In jsa@alexandria (Jon S Anthony) writes: > > [...] > > > But *languages* don't have GC. Implementations of them do. Even > > > Meyer says little about GC in ETL - just that all *implementations* > > > are *expected* to have it. > > > > That's not *quite* correct. It's admittedly difficult to define > > garbage collection in a formal language definition, but the Java > > definition at least attempts to do so. Here's paragraph 20.16.9 > > of The Java Language Specification, version 1.0 (available at > > ). > > > > 20.16.9 public void gc() > > > > Calling this method suggests that the Java Virtual Machine expend > > effort toward recycling discarded objects in order to make the > > memory they currently occupy available for quick reuse. When > > control returns from the method call, the Java Virtual Machine > > has made a best effort to recycle all discarded objects. (The > > name gc stands for "garbage collector.") > > > > The Java runtime system will perform this recycling process > > automatically as needed, in a separate thread, if the gc method > > is not invoked explicitly. > > > > See also the method gc (�20.18.12) of class System, which is > > the conventional and convenient means of invoking this method. > > > > This does refer to the "Java Virtual Machine", but I don't think there's > > any requirement that the JVM be implemented via the usual byte code > > interpreter. > > But the point is that it is talking about the JVM, _not_ JTL. The JVM > is about a particular implementation. Is it? I was making an implicit assumption, which I will now make explicit. Note that I was quoting from the Java Language Specification, not the Java Virtual Machine definition. My assumption was that the JVM is an abstract machine on top of which Java the language is implemented, and that a conforming JVM can be implemented by means other than the typical Java byte-code interpreter. In other words, if I implement a Java compiler that generates SPARC machine code, the JVM for that implementation consists of the SPARC hardware plus whatever software is necessary to satisfy the JVM definition. This additional software presumably would include automatic garbage collection, among other things. If this is what the term Java Virtual Machine means, then it's perfectly appropriate to refer to the JVM in the language specification. It's an interesting technique of separating low-level concerns from high-level language concerns, while allowing the low level to be implemented either in software, in hardware, or in some combination of the two. On the other hand, if the term JVM refers specifically to the Java byte-code interpreter, then referring to it in the language specification is a serious flaw. I haven't studied the Java documentation closely enough to resolve this. > Moreover, "suggests", "expend > effort toward", "made a best effort", etc. sounds a lot like "expected > to have". I said it was stated. I didn't say it was well stated. > > Even for a Java compiler that generates machine code directly, the > > runtime system has to provide a JVM implementation as specified in > > the language specification. I think. > > Where is this stated? Even if true, I don't see the relevance. It may not be stated anywhere. As a practical matter, given that Java provides no explicit pointers and no way to explicitly deallocate memory, it's unlikely that any implementer would ever provide a Java implementation without automatic garbage collection. Such an implementation would be nearly useless. Given this practical constraint, it's reasonable to say *informally* that the Java language provides automatic garbage collection. -- Keith Thompson (The_Other_Keith) kst@thomsoft.com <*> TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706 FIJAGDWOL