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

[Vladimir Kozlov]

Hi, Doug

Changes look fine. Thank you for doing this - memory consumption is real 
issues for Java based JIT.

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

Thanks,
Vladimir

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
>