RuntimePermission for explicit GC

[Ted Neward]

Actually, one thing .NET does here that I'd love to see Java adopt is a "GC" object returned from System that would offer some greater control over GC behaviors--disabling the execution of finalizers, for example, for objects that have already been semantically cleaned up. So something along the lines of:

public class GC
{
  /** same as System.gc() today */
  public void forceCollect();
  /** perform a GC specifically on one generation, given as the name
      returned from the JMX MemoryPool object, e.g., "Eden", "Tenured", etc */
  public void forceCollect(String generation);

  /** Object given in "obj" will not have its finalizer invoked;
      silently returns if object's finalizer is already disabled */
  public void disableFinalizer(Object obj);
  /** Re-schedule an object's finalizer if it was previously disabled; 
      silently returns if object's finalizer is already scheduled */
  public void rescheduleFinalizer(Object obj);

  // other APIs, added as necessary or desired

  // for example, certain JVMs may allow selection of GC algorithms to use
}

public class System
{
  public static GC getGC(); // returns singleton instance of above

  public static void gc() { System.getGC().forceCollect(); }
}

The idea of disableFinalizer() is that for objects where a Java programmer has already done the right thing and called close() or flush() or whatever other cleanup method is necessitated by the implementation, the object doesn't need its finalizer invoked (and therefore releases a certain amount of pressure on the GC). This then makes finalizers a last-resort kind of operation, rather than always being invoked on GC even if all the proper cleanup has already been handled.

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
 

> -----Original Message-----
> From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev-
> bounces at openjdk.java.net] On Behalf Of Clemens Eisserer
> Sent: Sunday, January 13, 2008 4:47 AM
> To: hotspot-gc-dev at openjdk.java.net
> Subject: Re: RuntimePermission for explicit GC
> 
> Hi again,
> 
> I also have some "rants" about the explicit GC invokation: Curently
> there are several places in the  JDK which rely on explicit GC - two
> exaples are RMI and Direct-Buffer management.
> DirectBufferManagement really heavily _relies_ on this, it will not
> work reliable without explizit GCs.
> 
> However there is only System.gc() which may be either disabled, or
> invoke a full GC or a concurrent GC or whatever - should mean from the
> java side you don't have any control over which you might get from the
> runtime even if you can use jdk-private APIs.
> 
> What do you think about a sun-internal API (e.g. sun.misc) like
> GCControl which allows to specify exactly the behaviour you would
> expect from the JVM. For now I would only think about jdk-internal use
> like the mentioned Direct-Buffer management.
> 
> lg Clemens
> 
> > The new -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses flag in JDK
> > 1.6.0_04 reminds me of some behaviour that I'd like to see in future
> > java versions.
> >
> > This flag is useful for an application to schedule GCs during
> > off-hours, but what if my application imports libraries that
> > internally have calls to System.gc()? Thankfully, this is becoming
> > rarer, but it would be nice if System.gc() internally checked a new
> > RuntimePermission "executeExplicitGc", and simply returned without
> > taking any action if that permission was not granted to the calling
> > code. If this was implemented, perhaps the signature could be changed
> > to return a boolean if the collection was successfully scheduled?
> >
> > Cheers,
> > Raman Gupta
> >
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.19.2/1221 - Release Date:
> 1/12/2008 2:04 PM
> 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.7/1232 - Release Date: 1/18/2008 7:32 PM