What influences young generation pause times?
Jon Masamitsu
jon.masamitsu at oracle.com
Fri Apr 23 03:13:22 UTC 2010
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
>>
>>
More information about the hotspot-gc-dev
mailing list