What influences young generation pause times?

[Jon Masamitsu]

On 04/23/10 13:24, Raman Gupta wrote:
> 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):

Perhaps it would be confusing for the user.  Any program today
would continue to behave as it currently does.  The user would have to 
take some action
to grant RuntimePermission "explicitGC" so they should not be surprised.  I
can see the point of the new flag "DisableExplicitGCNonGranted".  It's just
that we have so many flags already, it would be nice to not introduce yet
another one.
>
> 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.

Perhaps we could obsolete DisableExplicitGC and just use 
DisableExplicitGCNonGranted
in the future.  We'd probably only have to support DisableExplicitGC as 
an alias
for DisableExplicitGCNonGranted for 15 or 20 years :-).

>
>>> 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