What influences young generation pause times?

[Jon Masamitsu]

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);
>> }
>> JVM_END
>>
>>
>> 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
>>
>>