RFR: 8173912: [JVMCI] fix memory overhead of JVMCI

[Doug Simon]

> On 6 Feb 2017, at 19:08, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Hi, Doug
> 
> Changes look fine.

Thanks for the review.

> Thank you for doing this - memory consumption is real issues for Java based JIT.

Yes. We also continuing to tackle this on the Graal side.

> Did you test changes with AOT (this is what concern me most)?

I’ve only tested with `jprt -testset hotspot ...` so far. What should I run to test with AOT?

-Doug

> On 2/6/17 1:47 AM, Doug Simon wrote:
>> Please review this change that fixes footprint issues in JVMCI by reducing unnecessary memory allocation
>> and reducing the total set of permanently live objects by an order of magnitude. The changes described
>> below have been tested with JVMCI client Graal.
>> 
>> HotSpotVMConfigStore
>> ====================
>> 
>> HotSpotVMConfigStore communicates VM configuration info from the native VM code to the Java parts of JVMCI.
>> This change reduces the amount of data crossing this boundary significantly:
>> - Only the VM flags currently used by JVMCI and Graal are communicated. A VM call is added as a
>>   fallback for accessing the other flags. A test for the new getFlagValue() VM call is included.
>> - The Java object values encoding the info are canonicalized in the VM using a ResourceHashtable.
>> - Only the VM type sizes used by JVMCI and Graal are communicated.
>> The above changes result in reducing the memory overhead of HotSpotVMConfigStore from 904,210 to 364,742 bytes.
>> 
>> HotSpotResolvedObjectTypeImpl
>> =============================
>> 
>> This change removes or slims down a number of caches for the fields and methods in HotSpotResolvedObjectTypeImpl.
>> 
>> For method caches, a lighter weight array is now used that only falls back to a HashMap when more than 8 methods
>> are requested for a given type. During a JVMCI bootstrap (i.e. -XX:+BootstrapJVMCI), of 8024 HotSpotResolvedObjectTypeImpl
>> objects created, 4156 types never have a method requested, 3353 use the array-based cache and 253 fall back to
>> the HashMap.
>> 
>> For fields, caching has been removed entirely since HotSpotResolvedJavaFieldImpl is such a lightweight data
>> structure that creating a new one every time doesn’t matter. In addition, changes described below made it lighter
>> than it previously was.
>> 
>> Method and field names
>> ======================
>> 
>> The names of HotSpotResolvedJavaFieldImpl are rarely needed, mostly only being used in debugging code. In a JVMCI bootstrap
>> only 1490 of 154699 fields have their names accessed. As such, the HotSpotResolvedJavaFieldImpl.name field has been removed
>> and the name is now retrieved by a VM call. Also, since fields are no longer cached, the HotSpotResolvedJavaFieldImpl.toJavaCache
>> field storing the java.lang.reflect.Field mirror has been removed. This mirror is only ever accessed by debug code.
>> 
>> The names of most HotSpotResolvedJavaMethodImpl are also rarely needed. In a JVMCI bootstrap only 3259 of 11267 methods
>> have their names accessed. However, if a name is accessed once for a method, it is typically accessed numerous times. As
>> such, the name is now stored in a lazily created cache. In addition, the isConstructor() and isClassInitializer() methods
>> have been changed to directly compare the raw Symbol* holding the name with the vmSymbols::object_initializer_name() and
>> vmSymbols::class_initializer_name() values respectively. This further reduces the names created in a bootstrap to ~2000.
>> 
>> Clean up
>> ========
>> 
>> There’s a small clean up in .mx.jvmci/mx_jvmci.py that removes unused functionality for zipping up the JDK
>> after running `make images`.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8173912
>> http://cr.openjdk.java.net/~dnsimon/8173912/webrev/
>> 
>> -Doug
>>