RFR 8134802 - LCM register pressure scheduling

[Aleksey Shipilev]

Hi,

A good way to test the RA changes against "realistic" workload is to run
Octane suite with Nashorn, while collecting -XX:+CITime [1]. It is very
compiler-heavy workload. You may also want to "taskset -c 0" the entire
thing to make the CITime less flaky.

Thanks,
-Aleksey

[1] Quick start:
 $ <make the OpenJDK>
 $ cd nashorn/make
 $ ant externals
 $ ant dist
 $ cd ..
 $ ../build/linux-x86_64-normal-server-release/images/jdk/bin/java
-XX:+CITime -jar dist/nashorn.jar -scripting
test/script/basic/run-octane.js -- --iterations 1

On 09/05/2015 04:41 AM, Vladimir Kozlov wrote:
> Impressive work. Thank you for reusing current RA functionality.
> 
> "is very minimal" - how minimal? 2% or 10%?
> 
> Did it gave any performance improvement? Changes are significant and
> should be justified.
> 
> Changes look reasonable. I only notice one thing:
> Flag bits in Node is very precious to use for node's state tracking. Why
> not use VectorSet?
> 
> Thanks,
> Vladimir
> 
> On 9/4/15 1:33 PM, Berg, Michael C wrote:
>> Hi Folks,
>>
>> I would like to contribute LCM register pressure scheduling. I need two
>> reviewers to examine this patch and comment as needed:
>>
>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8134802
>>
>> webrev:
>>
>> http://cr.openjdk.java.net/~mcberg/8134802/webrev.01/
>>
>> These changes calculate register pressure at the entry of a basic block,
>> at the end and incrementally while we are scheduling. It uses an
>> efficient algorithm for recalculating register pressure on a as needed
>> basis. The algorithm uses heuristics to switch to a pressure based
>> algorithm to reduce spills for int and float registers using thresholds
>> for each. It also uses weights which count on a per register class basis
>> to dope ready list candidate choice while scheduling so that we reduce
>> register pressure when possible. Once we fall over either threshold, we
>> start trying mitigate pressure upon the affected class of registers
>> which are over the limit. This happens on both register classes and/or
>> separately for each. We switch back to latency scheduling when pressure
>> is alleviated. As before we obey hard artifacts such as barriers, fences
>> and such. Overhead for constructing and providing liveness information
>> and the additional algorithmic usage is very minimal, so as affect
>> compile time minimally.
>>
>> Thanks,
>>
>> Michael
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150907/9864b3e9/signature.asc>