What influences young generation pause times?

Raman Gupta rocketraman at fastmail.fm
Fri Apr 23 13:24:53 PDT 2010

On 04/23/2010 03:36 PM, Jon Masamitsu wrote:
> On 4/23/10 11:52 AM, Raman Gupta wrote:
> I did leave out a part. The customer would have to use
> -XX:+DisableExplicitGC to disallow System.gc() generally. Then the
> JVM_GC_GRANTED() would be called by a thread that had the
> permissions.
> If the new RuntimePermission and JVM_GC_GRANTED() were implemented
> but not used by any application, then everything behaves the same
> as today.
> An application that wants to do System.gc() while locking others
> out would use -XX:+DisableExplicitGC and would add the code to use
> RuntimePermission and JVM_GC_GRANTED() and thus get the System.gc()
> even though DisableExplicitGC is set.

Ahh, I think I see what you are saying:

if RuntimePermission "explicitGC" is granted, then
   JVM_GC_GRANTED  // GC runs regardless of DisableExplicitGC
   JVM_GC  // GC runs only if DisableExplicitGC not set

I think the semantic change in "DisableExplicitGC" might be a little 
confusing for users. It might be simpler for users to understand if a 
new flag like "DisableExplicitGCNonGranted" is added instead (default 
is false):

   if (!DisableExplicitGC) {

JVM_ENTRY_NO_ENV(void, JVM_GC(void))
   if (!DisableExplicitGC && !DisableExplicitGCNonGranted) {

This also allows for the possibility to turn off all explicit GC at 
the JVM level regardless -- which may be useful in certain situations.

To take advantage of this functionality then, users would grant their 
code the new RuntimePermission, and change their use of 
DisableExplicitGC to DisableExplicitGCNonGranted.

>> One other proposal is to implement a JVM interface
>> JVM_GC_PERMCHECK_ALLOWED returning a boolean. If this interface is
>> available, and it returns true, then and only then will the
>> "explicitGC" RuntimePermission be checked by the JDK. In this way, one
>> will have to explicitly enable this permission check via a
>> flag/setting at the JVM level. The default will of course be false.
>> This would maintain the current behavior for both VMs that have not
>> been updated to support JVM_GC_PERMCHECK_ALLOWED, and for VMs that do
>> support it but where customers have not explicitly enabled it via flag
>> or whatever.
> I don't understand this suggestion.

Never mind, I like your approach better.


More information about the hotspot-gc-dev mailing list