This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: status of gcj's boehm collector?



"Boehm, Hans" <hans_boehm@hp.com> writes:
> ...System.gc()...
> > In that case, how would a latency-sensitive application signal the GC
> > that it is now "okay" to stop-the-world for a long time (ie perform a
> > full heap scan)?

> I looked it up in response to your message.  Sun's documentation states:
> "When control returns from the method call, the Java Virtual Machine has
> made a best effort to reclaim space from all discarded objects."  The one
> line summary states "Runs the garbage collector".  Thus just having the VM
> ignore it seems a bit dubious; calling it as a hint that this might be a
> good time to run the collector is even more dubious; you really need to know
> that there has been a significant amount of allocation since the last
> collection, since it's likely the VM will unconditionally go ahead and
> collect.  And I think there's usually no good way to know that.

If you feel that is an important concern, some sort of
System.getNumAllocationsSinceLastFullHeapScan() could be added.


> Another problem is that this sort of opportunistic garbage collection should
> really be abortable if you get an unexpected request for more work during
> the GC.

If the world is frozen, how would you know that you had recieved such
a request?



> > I thought that was the whole point of System.gc() -- it might not
> > actually cause a GC; it's just a hint to the GC that "now is a safe
> > time to pause the application for a while". Sorta like Thread.yield().

> I think Thread.yield() can be used correctly.

Unfortunately in a multithreaded application, a non-latency-critical
thread might call Thread.yield() while a latency-critical thread was
in a "bad place" to be halted. The yield() would provoke a VM-wide
stop-the-universe for a full heap scan, which is now a good thing.

I can think of a lot of situations where it might be useful for one
thread to yield while another is in a latency-critical section.

I still think System.gc() has the right connotations, since it is not
a thread-specific operation. Would you approve of using it if there
was a way for the appliation to know how much allocation had taken
place since the last full heap scan?

If not, what would you suggest instead of System.gc()?


  - a


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]