RFR (L): 8015774: Add support for multiple code heaps

Mon Apr 14 22:15:36 UTC 2014

codeCache.hpp:
I guess CodeCache::_save_nmethods is not longer necessary since we ripped out the speculative disconnect?

codeCache.cpp:

Why are these necessary?
  51 #ifdef COMPILER1
  52 #include "c1/c1_Compilation.hpp"
  53 #endif
  54 #ifdef COMPILER2
  55 #include "opto/compile.hpp"
  56 #endif

arguments.cpp:

I know you’re working on the adaptive resizing solution. How are you planning to implement it?
Since it would be expensive to do compaction, the degree of resizing possible will be hampered by fragmentation. Perhaps there should be another allocation layer that gives preference to for certain allocation type to be allocated in specific areas, but does not preclude allocation in other areas? For example if we’re out of space for C2 methods we would be allowed to allocate in the C1 space. Is it something like that?

I think if we want to push the current solution we have to bump the code cache size temporarily up until we have an allocation strategy that doesn’t waste space so much. Otherwise there’re might be regressions for applications that work fine with the current setup.

sweeper.cpp:

I agree with Vladimir, I’d be nice to make code cache iteration more abstract and not expose nmethod types when doing it.

globals.hpp:

We probably don’t need all of those spaces for the interpreter-only configuration:
 190 define_pd_global(intx, NonProfiledCodeHeapSize,      14*M);
 191 define_pd_global(intx, ProfiledCodeHeapSize,         15*M );
 192 define_pd_global(intx, NonMethodCodeHeapSize,        3*M );

igor

On Apr 14, 2014, at 6:05 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> Hi Volker,
> 
> please see comments inline.
> 
> On 04/14/2014 02:54 PM, Volker Simonis wrote:
>> Hi Tobias,
>> 
>> is this change intended for jdk8 or 9?
>> 
> 
> the change is intended for JDK 9. The webrev is based on the JDK 9 repository (http://hg.openjdk.java.net/jdk9/hs-comp/hotspot) changeset 6280.
> 
>>  In any case, I saw that your
>> webrev is based on the hsx repository which I thought should not be
>> used any more. 
>> 
> 
> Why do you think that it is based on hsx? The earlier versions 00 - 03 actually were, because I already started developing the patch last year, but the newest one is based on the JDK 9 repository.
> 
> As Roland noticed, the default code heap sizes for arm/ppc were wrong (because tiered compilation is supported). The updated webrev can be found at:
> 
> http://cr.openjdk.java.net/~anoll/8015774/webrev.05/
> 
> Thanks,
> Tobias
> 
>> Could you please rebase your patch on jdk9 and also
>> update the corresponding ppc64 files in the webrev (as far as I can
>> see, that's only src/cpu/ppc/vm/c2_globals_ppc.hpp). I'd like to test
>> this on Linux/PPC64 and AIX as well.
>> 
>> Thank you and best regards,
>> Volker
>> 
>> 
>> 
>> On Mon, Apr 14, 2014 at 1:56 PM, Tobias Hartmann
>> 
>> <Tobias.Hartmann at oracle.com>
>>  wrote:
>> 
>>> Hi,
>>> 
>>> please review the new version of the following patch that adds support for
>>> multiple code heaps to the code cache.
>>> 
>>> Bug: 
>>> https://bugs.openjdk.java.net/browse/JDK-8015774
>>> 
>>> Webrev: 
>>> http://cr.openjdk.java.net/~anoll/8015774/webrev.04/
>>> 
>>> 
>>> Short description:
>>> This change implements support for multiple code heaps in the code cache.
>>> The interface of the code cache was changed accordingly and references from
>>> other components of the VM were adapted. This includes the indirect
>>> references from:
>>> - the Serviceability Agent: vmStructs and the Java code cache interface
>>> (sun.jvm.hotspot.code.CodeCache)
>>> - the dtrace ustack helper script (jhelper.d)
>>> - the pstack support library libjvm_db.c
>>> 
>>> Currently the code cache contains the following three code heaps each of
>>> which contains CodeBlobs of a specific type:
>>> - Non-Profiled methods: nmethods that are not profiled and native methods
>>> - Profiled methods: nmethods that are profiled
>>> - Non-methods: Non-methods like buffers and adapters
>>> 
>>> By default the non-method code heap uses 3 MB plus additional space for the
>>> compiler buffers that is dependent on the number of compiler threads (see
>>> CodeCache::initialize_heaps). The remaining code cache space is distributed
>>> equally among the non-profiled and the profiled code heaps.
>>> 
>>> Tested:
>>> JPRT, SPECjvm2008, SPECjbb2005, SPECjbb2013, Octane + Nashorn
>>> 
>>> Thanks,
>>> Tobias
>>> 
>>> 
>>> -------- Original Message --------
>>> Subject: Re: RFR (L): 8015774: Add support for multiple code heaps
>>> Date: Mon, 21 Oct 2013 17:47:48 +0200
>>> From: Albert Noll 
>>> <albert.noll at oracle.com>
>>> 
>>> To: Azeem Jiva 
>>> <azeem.jiva at oracle.com>
>>> 
>>> 
>>> 
>>> That is fine. As we realized the last two weeks, there is more work to be
>>> done to make multiple code heaps work effectively.
>>> 
>>> Albert
>>> 
>>> Von meinem iPhone gesendet
>>> 
>>> Am 21.10.2013 um 17:36 schrieb Azeem Jiva 
>>> <azeem.jiva at oracle.com>
>>> :
>>> 
>>> I still think we should hold off for JDK8u20
>>> 
>>> --
>>> Azeem Jiva
>>> @javawithjiva
>>> 
>>> On Oct 21, 2013, at 8:33 AM, Albert Noll 
>>> <albert.noll at oracle.com>
>>>  wrote:
>>> 
>>> 
>>> Von meinem iPhone gesendet
>>> 
>>> Anfang der weitergeleiteten E‑Mail:
>>> 
>>> Von: Vladimir Kozlov 
>>> <vladimir.kozlov at oracle.com>
>>> 
>>> Datum: 11. Oktober 2013 19:38:07 MESZ
>>> An: 
>>> hotspot-compiler-dev at openjdk.java.net
>>> 
>>> Betreff: Re: RFR (L): 8015774: Add support for multiple code heaps
>>> 
>>> This looks acceptable.
>>> 
>>> Thanks,
>>> Vladimir
>>> 
> 