Disable Fixed Heap Simple Write Barriers for PortableSharedCache

[harryyu1994]

Signed-off-by: Harry Yu harryyu1994@gmail.com

[harryyu1994]

./java -Xshareclasses:name=fix_heap,cacheDir=/root/ -Xmx100m -Xms100m -Xscminaot300m -Xscmx600m -Xjit:verbose,count=0 -version

./java -Xshareclasses:name=fix_heap,cacheDir=/root/ -Xmx100m -Xscminaot300m -Xscmx600m -Xjit:verbose,count=0 -version

[harryyu1994]

• generated AOT with this option (fixed heap)

ENV JVM_ARGS="-Xshareclasses:name=fix_heap,cacheDir=/opt/ibm/java/ -Xmx1000m -Xms1000m -XX:-PortableSharedCache -Xscmx500M -Xscmaxaot300M -Xjit:verbose"

• then load AOT using this option (variable heap

ENV JVM_ARGS="-Xshareclasses:name=fix_heap,cacheDir=/opt/ibm/java/ -Xmx1000m -XX:-PortableSharedCache -Xscmx500M -Xscmaxaot300M -Xjit:verbose"

@mpirvu Hi Marius, I did not observe an issue even without this change. We seem to load AOT fine with my AcmeAir application. Also another question is if this will cause AOT incompatibility how come we do not have a AOT compatibility check for this?

[mpirvu]

if this will cause AOT incompatibility how come we do not have a AOT compatibility check for this?

Good question, unless we don't understand what fixed heap size is or how to enable it. @dsouzai do you have an idea on this matter?

[dsouzai]

I guess we've never properly accounted for this case. We don't seem to check for isVariableHeapBaseForBarrierRange0 or isVariableHeapSizeForBarrierRange0 in the Feature Flags. Probably also need to also check for isVariableActiveCardTableBase.

[harryyu1994]

I guess we've never properly accounted for this case. We don't seem to check for isVariableHeapBaseForBarrierRange0 or isVariableHeapSizeForBarrierRange0 in the Feature Flags. Probably also need to also check for isVariableActiveCardTableBase.

I guess I will open another PR to include them in the check.

[harryyu1994]

@mpirvu Hi Marius, this one is ready for review.

[mpirvu]

As discussed, I would like to make sure that we have a real problem before merging a "solution" for it.

[harryyu1994]

@dsouzai #7710 is the only place I've seen this problem mentioned. Do you still remember who raised this problem and if there's any evidence that this is actually a problem? My local testing has shown that AOT was loading fine and no crashes when I switched from a fixed-heap configuration to a variable-heap configuration.

[dsouzai]

I know @fjeremic had mentioned in in the past that that writebar sequence is simpler if Xmx and Xms are the same (he's on vacation till late next week I think?).

I don't think we've ever run into a problem, but I suppose theoretically we could if the heap size changes if the loaded AOT code could be using the wrong writebars.

[andrewcraik]

Would we ever actually allow the heap size to be adjusted/changed between runs? This would cause a lot of differences for the runtime and it seems like this is quite different to the original purpose of portable SCC in that we were trying to avoid over dependence on the machine architecture. This is a performance trade for a different purpose - does it make sense to wrap it under the same banner? Might it be better to just produce a better diagnostic to inform users when we reject AOT code due to a GC configuration change so they can decide whether to build the image with a variable heap size or to actually fix their heap for a performance boost?

[harryyu1994]

Might it be better to just produce a better diagnostic to inform users when we reject AOT code due to a GC configuration change so they can decide whether to build the image with a variable heap size or to actually fix their heap for a performance boost?

Yeah I think this may be the better solution here.
When both fix heap and PortableAOT are specified we are going to produce an error message to the user and let them choose between the two. PortableAOT will only allow variable heap configuration.

Would we ever actually allow the heap size to be adjusted/changed between runs?

I don't think we have a use case where the user constantly change heap configurations between runs of the same application.
The problem occurs when we have multi-layered image with multi-layered SCC. In a multi-layered scenario, each layer's AOT is produced by a different JVM instance and potentially different heap configuration.

[mpirvu]

When both fix heap and PortableAOT are specified we are going to produce an error message to the user and let them choose between the two

I am also ok with forcing self()->setIsVariableHeapSizeForBarrierRange0(true); when portableAOT is in effect, provided the effect from it on performance is small (this solution is more user friendly).

[harryyu1994]

When both fix heap and PortableAOT are specified we are going to produce an error message to the user and let them choose between the two

I am also ok with forcing self()->setIsVariableHeapSizeForBarrierRange0(true); when portableAOT is in effect, provided the effect from it on performance is small (this solution is more user friendly).

@andrewcraik Any objections on this? Wondering if you have any idea how much of a performance boost fixed heap provides.

[mpirvu]

Wondering if you have any idea how much of a performance boost fixed heap provides.

This needs to be measured, because even if we had estimations based on old experiments, behavior might have changed.

[harryyu1994]

x86: Did not observe performance penalty with my setup.

fixheap: 
summary = 6182862 in  600s = 10304.5/s Avg:   0 Min:   0 Max: 18835 Err:   0 (0.00%)
summary = 6597629 in  600s = 10995.8/s Avg:   0 Min:   0 Max: 4769 Err:   0 (0.00%)
summary = 6620785 in  600s = 11034.4/s Avg:   0 Min:   0 Max: 2009 Err:   0 (0.00%)
summary = 6617945 in   600s = 11029.5/s Avg:     0 Min:     0 Max:  2869 Err:     0 (0.00%)
summary = 6756532 in   600s = 11260.6/s Avg:     0 Min:     0 Max:  2358 Err:     0 (0.00%)
summary = 6804482 in  600s = 11340.5/s Avg:   0 Min:   0 Max: 1228 Err:   0 (0.00%)

varheap:
summary = 6407492 in  600s = 10678.9/s Avg:   0 Min:   0 Max:  746 Err:   0 (0.00%)
summary = 6478335 in  600s = 10796.8/s Avg:   0 Min:   0 Max:  109 Err:   0 (0.00%)
summary = 6494342 in  600s = 10823.5/s Avg:   0 Min:   0 Max:  64 Err:   0 (0.00%)
summary = 6732480 in   600s = 11220.6/s Avg:     0 Min:     0 Max:  3243 Err:     0 (0.00%)
summary = 6840075 in   600s = 11399.7/s Avg:     0 Min:     0 Max:   172 Err:     0 (0.00%)

Z: 42 hours worth of throughput runs (specjbb2015)

Summary

critical-jOPS:
- fixheap: 2896
- varheap: 2847 (excluding that one bad run)

max-jOPS:
- fixheap: 9968
- varheap: 9970

fixheap 1: RUN RESULT: hbIR (max attempted) = 11245, hbIR (settled) = 10712, max-jOPS = 10120, critical-jOPS = 2738
fixheap 2: RUN RESULT: hbIR (max attempted) = 11548, hbIR (settled) = 10532, max-jOPS = 9931, critical-jOPS = 2872
fixheap 3: RUN RESULT: hbIR (max attempted) = 10712, hbIR (settled) = 10269, max-jOPS = 9855, critical-jOPS = 3079

varheap 1: RUN RESULT: hbIR (max attempted) = 11548, hbIR (settled) = 10532, max-jOPS = 9816, critical-jOPS = 2865
varheap 2: RUN RESULT: hbIR (max attempted) = 11548, hbIR (settled) = 10532, max-jOPS = 9816, critical-jOPS = 2412
varheap 3: RUN RESULT: hbIR (max attempted) = 11548, hbIR (settled) = 10924, max-jOPS = 10278, critical-jOPS = 2972
varheap 4: RUN RESULT: hbIR (max attempted) = 11548, hbIR (settled) = 10710, max-jOPS = 9931, critical-jOPS = 2705

Power: 1 hour worth of throughput runs (AcmeAir)

fixheap 1: summary = 2363020 in  600s = 3938.2/s Avg:   2 Min:   0 Max:  110 Err:   0 (0.00%)
fixheap 2: summary = 2359994 in  600s = 3933.2/s Avg:   2 Min:   0 Max:  107 Err:   0 (0.00%)
fixheap 3: summary = 2367241 in   600s = 3945.2/s Avg:     2 Min:     0 Max:   106 Err:     0 (0.00%)

varheap 1: summary = 2377534 in  600s = 3962.4/s Avg:   2 Min:   0 Max:  104 Err:   0 (0.00%)
varheap 2: summary = 2394298 in  600s = 3990.3/s Avg:   2 Min:   0 Max:  109 Err:   0 (0.00%)
varheap 3: summary = 2376287 in  600s = 3960.3/s Avg:   2 Min:   0 Max:  106 Err:   0 (0.00%)

[harryyu1994]

@mpirvu See above for performance numbers. I think this one is safe to go in.

[mpirvu]

LGTM

[mpirvu]

jenkins test sanity all jdk11