What influences young generation pause times?

Raman Gupta rocketraman at fastmail.fm
Thu Apr 22 23:11:08 PDT 2010

My understanding is that by default there is no security manager 
installed, therefore the behavior would be exactly the same as it is 

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.


On 04/22/2010 11:13 PM, Jon Masamitsu wrote:
> Raman,
> Given the plan you outlined below, what would be the behavior if
> an application does nothing about the RuntimePermission
> explicitGC? Would all explicit GC's be ignored?
> Jon
> On 4/22/10 7:09 PM, Raman Gupta wrote:
>> Forgive my ignorance as this is my first foray into the internals of
>> the java JDK/JVM.
>> Here is my (probably wrong) understanding:
>> The JDK contains:
>> src/share/classes/java/lang/Runtime.java
>> src/share/native/java/lang/Runtime.c
>> and presumably all VMs (such as the hotspot VM) must implement the
>> method which is called from Runtime.c:
>> JVM_GC(void);
>> Now having looked at the code, it seems to me this change would make
>> more sense at the JDK level rather than the VM level (and if so, I
>> guess I'm on the wrong mailing list). My naiive implementation would
>> be to
>> 1) leave the JVM implementation alone (including the check for
>> DisableExplicitGC flag), and
>> 2) in Runtime.java, rename the existing gc() method to a private
>> native method called gcImpl() or something like that. Modify Runtime.c
>> accordingly.
>> 3) in Runtime.java, reimplement gc() to check if
>> RuntimePermission("explicitGC") is granted to the caller. If it is,
>> delegate to gcImpl() and return.
>> End result should be to allow users to grant permissions to do
>> explicit GCs regardless of VM. For Hotspot, the DisableExplicitGC flag
>> is still the ultimate arbiter of whether the explicit GC is done or
>> not, as it is now. I think this makes the most sense, and it is also
>> backward compatible in that explicit GCs will never be silently
>> enabled for Hotspot if DisableExplicitGC is specified.
>> To take advantage of this change, users remove DisableExplicitGC
>> setting, and add the appropriate permission to their own code.
>> Cheers,
>> Raman
>> On 04/22/2010 08:35 PM, Jon Masamitsu wrote:
>>> Raman,
>>> In hotspot code in share/vm/prims/jvm.cpp there is an entry
>>> JVM_ENTRY_NO_ENV(void, JVM_GC(void))
>>> JVMWrapper("JVM_GC");
>>> if (!DisableExplicitGC) {
>>> Universe::heap()->collect(GCCause::_java_lang_system_gc);
>>> }
>>> The VM change you would need would be to add
>>> an entry (or logical equivalent however you would
>>> choose to implement it) which would not check
>>> DisableExplicitGC? Maybe something like
>>> JVM_GC_GRANTED (or whatever).
>>> On the Java side you would make the check to
>>> see if the new RuntimePermission has been
>>> granted before calling the JVM_GC_GRANTED()?
>>> Is the JVM_GC_GRANTED() entry the change
>>> you would want us to accept?
>>> Jon
>>> On 4/22/10 9:24 AM, Raman Gupta wrote:
>>>> On 04/22/2010 02:22 AM, Jon Masamitsu wrote:
>>>>> On 4/21/10 4:19 PM, Raman Gupta wrote:
>>>>>> I am not suggesting any new API at this time -- I mentioned it
>>>>>> only as
>>>>>> a pie-in-the-sky kind of thing.
>>>>>> My current suggestion is simply to gate System.gc() (or actually
>>>>>> Runtime.gc() I guess) with a new RuntimePermission. Without the
>>>>>> appropriate permission granted, gc() would simply be a no-op.
>>>>> I know very little about RuntimePermission. Who needs to be
>>>>> involved in
>>>>> creating
>>>>> a new one?
>>>> It seems the core libraries group is responsible for anything in
>>>> java.lang, which both SecurityManager and RuntimePermission are:
>>>> http://openjdk.java.net/groups/core-libs/
>>>> So presumably both the GC group and the core libraries group would
>>>> have to be ok with this change. If you guys are ok with this in
>>>> principle, I can coordinate getting approval from the core-libs group
>>>> via their mailing list. I would also need a sponsor -- I don't know if
>>>> they would be from gc-dev or core-libs or both.
>>>> Documentation like this one would have to be updated as well -- if
>>>> this is part of the JDK source then that is easy enough:
>>>> http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html
>>>> Cheers,
>>>> Raman

More information about the hotspot-gc-dev mailing list