Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!newsfeed.freenet.ag!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!news.uni-stuttgart.de!news.nask.pl!news.nask.org.pl!news.cyf-kr.edu.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!.POSTED!not-for-mail From: Michal Kleczek Newsgroups: comp.lang.java.programmer Subject: Re: Managed-Code Bloat Date: Wed, 08 Jun 2011 09:23:50 +0200 Organization: http://onet.pl Lines: 22 Message-ID: References: NNTP-Posting-Host: 77-252-124-164.ip.netia.com.pl Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Trace: news.onet.pl 1307517830 10304 77.252.124.164 (8 Jun 2011 07:23:50 GMT) X-Complaints-To: niusy@onet.pl NNTP-Posting-Date: Wed, 8 Jun 2011 07:23:50 +0000 (UTC) User-Agent: KNode/4.4.9 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5085 BGB wrote: > > also, possible though are some garbage reduction tricks: > ref-counting (as they can detect earlier objects that have died); > (heap-based) value types (because their lifespan behavior is trivial to > determine, and so one can allocate/free them aggressively); > ... > > ref-counting has the drawback though that it is very difficult to write > "general purpose" code and not screw up the ref-counts somewhere (which > can easily blow up the program), causing me to generally not use them. > There has been some work done to implement ref-counting GC in (Sun) JVM. See: http://www.cs.technion.ac.il/~erez/Papers/refcount.ps The results were promissing but it has not been incorporated into production JVM. -- Michal