RuntimePermission for explicit GC
Clemens Eisserer
linuxhippy at gmail.com
Sun Jan 13 12:47:27 UTC 2008
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
>
More information about the hotspot-gc-dev
mailing list