stevenschlansker commented on code in PR #2540:
URL: https://github.com/apache/fory/pull/2540#discussion_r2320428246
##########
java/fory-format/src/main/java/org/apache/fory/format/row/binary/writer/BinaryWriter.java:
##########
@@ -121,10 +121,10 @@ protected final void zeroOutPaddingBytes(int numBytes) {
}
/**
- * Since writer is used for one-pass writer, same field won't be writer
twice. There is no need to
- * put zero into the corresponding field when set null.
+ * Writer might recycle buffers, so implementations should clear data from
+ * a previous not-null write when setting null to avoid information leaks.
*/
- public final void setNullAt(int ordinal) {
+ public void setNullAt(int ordinal) {
Review Comment:
Also, I did a little digging with compiler directives to print inlining
decisions.
It looks like despite the method theoretically being polymorphic, in
practice, the JIT is able to inline it anyway since there are not any actual
polymorphic dispatches in the code. (At least, not in my test cases) - row
encoder always calls row writer, array encoder calls array writer, etc
Example:
```
2025-09-03 01:51:44 INFO JaninoUtils:121 [main] - Compile
[RowEncoderTest_BarRowCodec149387948_1353170030] take 53 ms
@ 46
org.apache.fory.format.row.binary.writer.BinaryRowWriter::setNullAt (13 bytes)
inline (hot)
@ 2
org.apache.fory.format.row.binary.writer.BinaryWriter::setNullAt (18 bytes)
inline (hot)
```
So maybe removing `final` is not as harmful as you think? I do appreciate
the desire for maximum performance of course, so let me know what you think is
the best fix.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
