Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Eric Sosman <esosman@ieee-dot-org.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: Controlling the Garbage Collector
Date: Mon, 25 Jun 2012 13:45:03 -0400
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <jsa838$vih$1@dont-email.me>
References: <YvmdncQlVsKmJUbSnZ2dnUVZ_t4AAAAA@giganews.com> <jrgje5$e8p$1@dont-email.me> <6KSdnTwztJvtR0bSnZ2dnUVZ_t-dnZ2d@giganews.com> <jrgo11$3t6$1@dont-email.me> <_JmdnUu_Z-scJEHSnZ2dnUVZ_t6dnZ2d@giganews.com> <4fe27687$0$281$14726298@news.sunsite.dk> <K9mdnVvXpcl4-37SnZ2dnUVZ_q6dnZ2d@giganews.com> <a4hj1sFc30U1@mid.individual.net> <m3zk7ro9sg.fsf@ipa.eternal-september.org> <js9nn1$lba$1@dont-email.me> <slrnjuh6bd.u9l.avl@gamma.logic.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 25 Jun 2012 17:45:13 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="03ebLEozl+tXCe7JS60Feg"; logging-data="32337"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+4NrsfBPfNhytuKIYF62/t"
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
In-Reply-To: <slrnjuh6bd.u9l.avl@gamma.logic.tuwien.ac.at>
Cancel-Lock: sha1:4nMxvtb+0w/VvZcNt4SPJvOVi+s=
Xref: csiph.com comp.lang.java.programmer:15581

On 6/25/2012 1:01 PM, Andreas Leitgeb wrote:
> Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
>> On 6/25/2012 8:28 AM, Jukka Lahtinen wrote:
>>> Robert Klemme <shortcutter@googlemail.com> writes:
>>>> Long lived objects which live shorter than the application (i.e. not
>>>> classes) are actually the Achilles heel of GC because it is very hard to
>>>> tune the collector in a way that it does not visit those long living
>>>> objects too often and yet run often enough to ensure enough free memory is
>>> It might be good to have a method to gell the GC that a certain
>>> long-lived object is no longer needed.
>>> For example, something like
>>> System.gc(Object old)
>>> where old is the object that has just been needed the last time.
>>       How would you call the method?
>
> class MyRef<T> {
>     private T ref;
>     public T consume() { T tmp = ref; ref=null; return tmp; }
>     public MyRef(T t) { ref=t; }
> }
> [...somewhere else...]
>     BigObject bo=new BigObject();
>     // use bo ...
>     MyRef<BigObject> mrBo = new MyRef<>(bo); bo=null;
>     System.gc( mrBo.consume() );
> ;-)

     ;-)

> Maybe slightly more interesting questions:
> What would be the behaviour of that proposed call,
> - if "old" *is* still (hard-)referenced from live objects?
> - if there's still a weak/soft-reference on that object?
> (pick one: Exception, force(for weak/soft-refs) or ignore?)

     Exactly: The JVM could not simply trust the System.gc(obj)
call to be telling the truth, because that would open the door
to all manner of attacks.  Therefore the JVM would have to verify
that obj was unreachable (at whatever strength) before deciding
to dispose of it.  That is, the JVM would have to run nearly all
of the garbage collector to determine obj's reachability -- so
why not just run the ordinary GC in the ordinary way?  I'm at a
loss to imagine what benefit a System.gc(obj) would offer.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid