What influences young generation pause times?

[Jon Masamitsu]

On 4/23/10 11:52 AM, Raman Gupta wrote:
> ...

>
> If I understand you correctly, then Runtime.java/Runtime.c would check 
> if the underlying VM had JVM_GC_GRANTED (a new interface). 
> JVM_GC_GRANTED is like JVM_GC but DisableExplicitGC is not checked. If 
> the "explicitGC" RuntimePermission was granted to the running code, 
> and JVM_GC_GRANTED was available, then Runtime.java/Runtime.c call 
> JVM_GC_GRANTED instead of JVM_GC.
>
> If that is right, then I'm not sure how that changes anything. The 
> change of behavior we are concerned with is that where today an 
> explicit GC *would* run, we would be changing the JDK in such a way, 
> via RuntimePermission, that it *would not* run. JVM_GC_GRANTED does 
> not seem to change this.

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.
>
> 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.
>
> Cheers,
> Raman