Date: Wed, 9 Sep 1998 13:43:22 -0500 (CDT) From: Tony Kimball <alk@pobox.com> To: sbb@freegate.com Cc: freebsd-java@FreeBSD.ORG Subject: Re: Daemonising a Java Process: Possible? Message-ID: <13814.52020.566050.184787@compound.east> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13814.52020.566050.184787>