From owner-freebsd-java  Wed Sep  9 11:41:07 1998
Return-Path: <owner-freebsd-java@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id LAA27083
          for freebsd-java-outgoing; Wed, 9 Sep 1998 11:41:07 -0700 (PDT)
          (envelope-from owner-freebsd-java@FreeBSD.ORG)
Received: from pobox.com (port33.prairietech.net [208.141.230.110])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27077
          for <freebsd-java@FreeBSD.ORG>; Wed, 9 Sep 1998 11:41:04 -0700 (PDT)
          (envelope-from alk@pobox.com)
Received: (from alk@localhost) by pobox.com (8.8.8/8.7.3) id NAA15670; Wed, 9 Sep 1998 13:43:25 -0500 (CDT)
From: Tony Kimball <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed,  9 Sep 1998 13:43:22 -0500 (CDT)
X-Face: O9M"E%K;(f-Go/XDxL+pCxI5<W_e*r7B8ojMD.5+qDgOp4/\gTQEgbOoBqf:Vtl*aW:<;9/
	UIVk'U^XhYg+v#r~*X<$Q=_ik@5:%E}pl]9|9|:]WLW8n:fLgg0~cfwWRBQxK/HSG0b1D/gljJC$qp
	b=HDF@+"H<|fXy`w#$8#6A"!F:>*gr[=FN@Y`cl1.Tn
Reply-To: alk@pobox.com
To: sbb@freegate.com
Cc: freebsd-java@FreeBSD.ORG
Subject: Re: Daemonising a Java Process: Possible?
References: <13813.27934.606377.693358@compound.east>
	<199809082154.WAA00626@fdy2.demon.co.uk>
	<13814.46288.737653.240366@compound.east>
	<3.0.5.32.19980909105902.00979b70@mailhost.hq.freegate.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13814.52020.566050.184787@compound.east>
Sender: owner-freebsd-java@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Quoth Steve Byrne on Wed, 9 September:
: Uh...how can you conclude that?  The compilation technology has little to
: do with the runtime memory management model.  Cygnus has posted papers about
: their GC approach, both on their web site, and in the most recent issue of
: Dr. Dobbs.  I suggest you read that before assuming that memory leakage of 
: allocated storage is connected with the generation of machine code.

I think my point was not clear to you:  gjc was not designed as jit,
i.e. as a component of a long-lived virtual machine.  GC in the 
generated code and GC in the compiler itself being entirely distinct
issues, and there being no requirement for the compiler not to leak
through successive invokations (since "power-cycle" garbage collection
is inherent in the invokation model), my supposition was that memory
management in the compiler itself will be one of the first-order tasks
required to use gjc as jit, on the assumption that the text/data/bss
are persistently linked into the jvm.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message