forked from ameisen/jdk-mc
-
Notifications
You must be signed in to change notification settings - Fork 0
/
flags.txt
67 lines (62 loc) · 1.61 KB
/
flags.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
AlwaysIncrementalInline
In benchmarks, this almost always hurt performance
UseCMoveUnconditionally
In benchmarks, this almost always helped performance
Looking into not using this but rather making the JIT choose CMOV more liberally
InlineReflectionGetCallerClass
I want to look further into how the JVM inlines such things since it's useful for us
The following values require profiling:
OptoNodeListSize
OptoBlockListSize
MultiArrayExpandLimit
TrackedInitializationLimit
NodeCountInliningCutoff
AutoBoxCacheMax
EscapeAnalysisTimeout
EliminateAllocationArraySizeLimit
ValueSearchLimit
MaxLabelRootDepth
DominatorSearchLimit
MaxInlineLevel
MaxRecursiveInlineLevel
InlineSmallCode
MaxInlineSize
FreqInlineSize
MaxTrivialSize
AlwaysIncrementalInline
LiveNodeCountInliningCutoff
ArrayCopyLoadStoreMaxElem
LoopStripMiningIter
AVX3Threshold
ObjectAlignmentInBytes
AlwaysSafeConstructors
DynamicallyResizeSystemDictionaries
hashCode
EagerInitialization
FastAllocateSizeLimit
CompactStrings
AlwaysCompileLoopMethods
MaxBCEAEstimateLevel
MaxBCEAEstimateSize
TypeProfileWidth
BciProfileWidth
PerMethodRecompilationCutoff
PerBytecodeRecompilationCutoff
PerMethodTrapLimit
PerMethodSpecTrapLimit
PerBytecodeTrapLimit
SpecTrapLimitExtraEntries
UseStringDeduplication
NMethodSizeLimit
InstructionCountCutoff
These require deep profiling:
LoopUnrollLimit
LoopPercentProfileLimit
LoopMaxUnroll
PartialPeelNewPhiDelta # default 0
OptoBundling # defaults to true, seems wasteful overall
cmove flags:
UseCMoveUnconditionally
UseCMoveUnconditionallyPhi
UseCMoveUnconditionallyPredict
CMoveWeightMultiplier