What influences young generation pause times?

[Raman Gupta]

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
>
>