Quantcast

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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Doug Simon @ Oracle
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Doug Simon @ Oracle

> On 6 Feb 2017, at 19:08, Vladimir Kozlov <[hidden email]> 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
>>

Loading...