3 ms·

> ...yet I’ve seen programs handling SIGSEGV: for God’s sake, don’t do that! I recommend the author not examine JVM null pointer handling too closely then.

lesenek 3y ago
(I’m the author.) I will not then. It surprises me that the JVM would handle null pointers by hoping dereferencing one would raise a segfault, considering that the JVM is written in C AFAIK where such dereferencing invokes undefined behavior, not a memory access at address 0 which would segfault most of the time.
- bheadmaster 3y ago
  I think it's an optimization. Checking for null pointer on every object access can become costly, as it's a fundamental operation (everything is a pointer in Java). By handling SIGSEGV, you save time in non-null case, at the expense of more complex code and, as you've mentioned, non-standard behavior. Also wanted to mention your comment was [dead], had to vouch for it to resurrect it.
  - lesenek 3y ago
    I understand the problem, but I am concerned by the solution. The problem is that C semantic is quite clear on the subject[1]: dereferencing a null pointer is undefined behavior, not "non-standard behavior" which would suggests correct albeit non-portable behavior. I don't know of any compiler switch that tells the compiler to "define" this behavior, like `-fno-strict-aliasing` or `-fwrapv` do. [1] ISO/IEC 9899:2011 §6.5.3.2
    - bheadmaster 3y ago
      I understand - I deliberately used the vague term "non-standard behavior", since the solution somehow works. There is a GCC flag "-fno-delete-null-pointer-checks" [0] which seems like it might enable this behavior, but I'm not sure. [0] https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Optimize-Options.html#:~:text=Use%20%2Dfno%2Ddelete%2Dnull,by%20default%20on%20most%20targets https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Optimize-Option.... P.S. Seems like your account is shadowbanned. Might want to contact dang: hn@ycombinator.com if you plan on posting more.
      - lesenek 3y ago
        From my understanding, I think that option only prevents the compiler from removing null checks when the pointer was dereferenced before. It was probably motivated by this incident in the Kernel[1] where an optimized-out null check condition (because it was dereferenced right before) caused a vulnerability. I like this story, since both sides (Linux vs GCC) have perfectly reasonable positions IMO. [1] https://lwn.net/Articles/342330/ https://lwn.net/Articles/342330/ PS: I took action by contacting Dang about the shadowban; thank you for warning me, I was wondering why I felt like a ghost.
- ShroudedNight 3y ago
  I appreciate you replying, and my sympathies for the posting weirdness - I was worried that I had inadvertently caused a karma trap. From what I recall (it's been ~ 5 years), at least on OpenJ9, the potential SIGSEGV's for null references occurred in code generated by our JIT compiler, or in hand-rolled assembly, and not in code generated by any C translation unit. This may well not satisfy the standard, but honestly, at that point, I'm not sure any FFI-linked code will. If you find this distinction insufficient, and still require the use of a JVM, if my memory serves correctly, -Xrs on OpenJ9 will avoid using those trap handlers. I don't believe this is true of Hotspot.
  - lesenek 3y ago
    If the null dereferencing happens in assembly code and not in C, it seems fine to me: the C standard is irrelevant for assembly; after all, it's the C language that introduces UB, not the machine code.

lesenek 3y ago

(I’m the author.) I will not then. It surprises me that the JVM would handle null pointers by hoping dereferencing one would raise a segfault, considering that the JVM is written in C AFAIK where such dereferencing invokes undefined behavior, not a memory access at address 0 which would segfault most of the time.

bheadmaster 3y ago
I think it's an optimization. Checking for null pointer on every object access can become costly, as it's a fundamental operation (everything is a pointer in Java). By handling SIGSEGV, you save time in non-null case, at the expense of more complex code and, as you've mentioned, non-standard behavior. Also wanted to mention your comment was [dead], had to vouch for it to resurrect it.
- lesenek 3y ago
  I understand the problem, but I am concerned by the solution. The problem is that C semantic is quite clear on the subject[1]: dereferencing a null pointer is undefined behavior, not "non-standard behavior" which would suggests correct albeit non-portable behavior. I don't know of any compiler switch that tells the compiler to "define" this behavior, like `-fno-strict-aliasing` or `-fwrapv` do. [1] ISO/IEC 9899:2011 §6.5.3.2
  - bheadmaster 3y ago
    I understand - I deliberately used the vague term "non-standard behavior", since the solution somehow works. There is a GCC flag "-fno-delete-null-pointer-checks" [0] which seems like it might enable this behavior, but I'm not sure. [0] https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Optimize-Options.html#:~:text=Use%20%2Dfno%2Ddelete%2Dnull,by%20default%20on%20most%20targets https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Optimize-Option.... P.S. Seems like your account is shadowbanned. Might want to contact dang: hn@ycombinator.com if you plan on posting more.
    - lesenek 3y ago
      From my understanding, I think that option only prevents the compiler from removing null checks when the pointer was dereferenced before. It was probably motivated by this incident in the Kernel[1] where an optimized-out null check condition (because it was dereferenced right before) caused a vulnerability. I like this story, since both sides (Linux vs GCC) have perfectly reasonable positions IMO. [1] https://lwn.net/Articles/342330/ https://lwn.net/Articles/342330/ PS: I took action by contacting Dang about the shadowban; thank you for warning me, I was wondering why I felt like a ghost.
ShroudedNight 3y ago
I appreciate you replying, and my sympathies for the posting weirdness - I was worried that I had inadvertently caused a karma trap. From what I recall (it's been ~ 5 years), at least on OpenJ9, the potential SIGSEGV's for null references occurred in code generated by our JIT compiler, or in hand-rolled assembly, and not in code generated by any C translation unit. This may well not satisfy the standard, but honestly, at that point, I'm not sure any FFI-linked code will. If you find this distinction insufficient, and still require the use of a JVM, if my memory serves correctly, -Xrs on OpenJ9 will avoid using those trap handlers. I don't believe this is true of Hotspot.
- lesenek 3y ago
  If the null dereferencing happens in assembly code and not in C, it seems fine to me: the C standard is irrelevant for assembly; after all, it's the C language that introduces UB, not the machine code.