What influences young generation pause times?

[Raman Gupta]

On 04/23/2010 10:49 AM, Jon Masamitsu wrote:
> On 4/22/10 11:11 PM, Raman Gupta wrote:
>> My understanding is that by default there is no security manager
>> installed, therefore the behavior would be exactly the same as it is
>> today.
>>
>> However, if a security manager *is* installed, either by the user
>> themselves, or by a container such as an application server, or
>> environments restricted by default such as applets, then the security
>> policy in effect would govern the behavior. In this case, if the
>> security policy does not grant the explicitGC permission, either by
>> default or by user (or vendor) modification, then yes, all explicit
>> GCs will be ignored.
>>
>> With the amount of abuse of System.gc() out there I'm not so sure
>> that's a bad thing. If there is code that requires it (see
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6200079 for
>> example), the default policy can be modified to allow it by default.
>> The release notes should suffice for container vendors and the like.
>
> You're right that there is abuse of Systen.gc() :-) and we could
> hide because the "nothing is guaranteed to happen" on a System.gc()
> but it is a major change in behavior. That scares me.
>
> If the RuntimePermissions checking code could look to see if the VM
> underneath had the JVM_GC_GRANTED() interface, then any VM
> that wanted to could provide this additional service. I think that JVMTI
> does something like that - you can get a list of the JVMTI capabilities
> offered by the VM. I don't know if such a thing exists outside
> JVMTI. And yes, other VM vendors need to be involved.

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.

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.

Cheers,
Raman