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
else
   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):

JVM_ENTRY_NO_ENV(void, JVM_GC_GRANTED(void))
   JVMWrapper("JVM_GC_GRANTED");
   if (!DisableExplicitGC) {
     Universe::heap()->collect(GCCause::_java_lang_system_gc);
   }
JVM_END

JVM_ENTRY_NO_ENV(void, JVM_GC(void))
   JVMWrapper("JVM_GC");
   if (!DisableExplicitGC && !DisableExplicitGCNonGranted) {
     Universe::heap()->collect(GCCause::_java_lang_system_gc);
   }
JVM_END

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.

Cheers,
Raman


More information about the hotspot-gc-dev mailing list