-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improvements #128
Improvements #128
Conversation
Most implementations of the `Operation.getInputResultHandles()` method return a `LinkedHashSet`, even if the interface demands just `Set`. A few existing implementations returned just `HashSet`, and this commit makes them consistent with the rest.
The code that emits LADD had a typo: the correct descriptor for the `long` type is `J` and not `Z`.
Note it is probably easiest to review individual commits separately. |
ada1ba0
to
8af0225
Compare
Previously, all constants were loaded from the constant pool and pushed on the stack using the LDC instruction. This is less efficient than necessary, because for some very commonly used constants, the JVM ISA has dedicated instructions: ICONST_0, ICONST_1 etc. With this commit, all the common constats are loaded using these instructions.
ec56176
to
b4e76f0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome set of improments and fixes! Thanks a lot Ladislav.
@@ -1177,7 +1177,7 @@ void writeBytecode(MethodVisitor methodVisitor) { | |||
|
|||
@Override | |||
Set<ResultHandle> getInputResultHandles() { | |||
return new HashSet<>(Arrays.asList(a1, a2)); | |||
return new LinkedHashSet<>(Arrays.asList(a1, a2)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, would it make sense to use HashSet
everywhere instead? Or clarify the contract of BytecodeCreatorImpl.Operation.getInputResultHandles()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to do some experiments to improve the generated code, and as part of them, I'd probably make this a List
, actually.
Previously, the only arithmetic operation available through Gizmo API was addition (IADD etc.). This commit adds multiplication (IMUL etc.), as well as internal helper methods that will help implement more arithmetic operations in the future.
As opposed to comparing `int` values, where the JVM ISA provides instructions that branch directly, comparing `long`, `float` and `double` values is more involved. The LCMP, FCMP* and DCMP* instructions push a comparison result on the stack as an `int` and an `int` branching instruction must be used afterwards.
The `ifReferencesEqual` method emits the IF_ACMPEQ instruction. This commit adds `ifReferencesNotEqual`, which emits IF_ACMPNE. This is useful to generate bytecode similar to what javac generates.
Notably, 4 methods are added to simplify common `returnValue` invocations. The `returnBoolean` and `returnInt` methods simplify returning a constant, `returnNull` simplifies returning the `null` reference, and `returnVoid` makes return from a `void` method or constructor more obvious.
Most notably, `JdkMap.instance(ResultHandle)` is deprecated and replaced by `JdkMap.on(ResultHandle)` to be consistent with other classes.
Several improvements:
getInputResultHandles()
implementations consistentlong
values (typo in the type descriptor)returnBoolean
,returnInt
,returnNull
andreturnVoid
to simplify common method exitsStringBuilder
chainsequals
,hashCode
andtoString
, similarly to what IDEs doGizmo
class to USAGE.adoc