Using param --optmize-synchronized and --reuse-reg of dex2jar will consume more cpu/memory usage and time

[n0099]

d2j-dex2jar -- convert dex to jar
usage: d2j-dex2jar [options] <file0> [file1 ... fileN]
options:
...
 -os,--optmize-synchronized   optimize-synchronized
 -r,--reuse-reg               reuse register while generate java .class file

jvm param	dex2jar param	avg mem usage	avg cpu usage across 4 cores 25%=1 core	time spend	visualvm screenshot
oracle jdk17 -Xms512m -Xmx8g	-os -r	3.5G	40%	38mins
graalvm jdk19 -Xms4g -Xmx5g	-os -r	3G	25%~35%	35mins
graalvm jdk19 -Xms3g -Xmx4g -XX:+UseStringDeduplication -XX:StringDeduplicationAgeThreshold=1	none	3G	25%~35%	32mins
graalvm jdk19 -Xms3g -Xmx4g -XX:+UseStringDeduplication -XX:StringDeduplicationAgeThreshold=1	-os	3.5G	25%~45%	40mins
graalvm jdk19 -Xms3g -Xmx4g -XX:+UseStringDeduplication -XX:StringDeduplicationAgeThreshold=1	-r	2.8G	25%~40%	36mins
graalvm jdk19 -Xms3g -Xmx4g -XX:+UseStringDeduplication -XX:StringDeduplicationAgeThreshold=1	-os -r	2.7G	40%	32mins

[ThexXTURBOXx]

I looked into this a bit and it seems that REUSE_REGISTER is not used anywhere. Maybe pxb was going to work on this feature, but never started.
So it should probably not matter if it is enabled or not.
And in your measurements it looks like it does not matter too much (confirming my assumption).
I think the small differences are just random.

However, the OPTIMIZE_SYNCHRONIZED parameter is actually used in two places within IR2JConverter.
There it could do some micro-optimisation when handling the LOCK and UNLOCK tokens.
It does not seem to change too much according to your measurements. So it might be unfinished.

So I will mark this as a question and perhaps we can discuss this at another time in the near future.
Anyway, thanks for your measurements!