What influences young generation pause times?

[Jon Masamitsu]

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