0

Suppose there are two variables pointing to the same instance:

var obj1 = new Object();
var obj2 = obj1;

Is it possible that obj1 gets pointing to wrong memory address due to memory bit flip (e.g. hardware failures)?

so obj1 points to invalid memory address but obj2 is still valid, and points to "new Object()" created.

justyy
  • 5,831
  • 4
  • 40
  • 73
  • 1
    @YCF_L -- yes, I was, in fact, being dim. Not for the first time. I deleted my ill-informed comment ;) – Kevin Boone Sep 23 '20 at 12:55
  • Related: [Cosmic Rays: what is the probability they will affect a program?](https://stackoverflow.com/questions/2580933/cosmic-rays-what-is-the-probability-they-will-affect-a-program) – MC Emperor Sep 23 '20 at 12:58

2 Answers2

0

Not in "Java the language". The language specification assumes that the machine is working correctly, and I assume that by "bit flip" you mean the type of a hardware failure.

If you start to factor in things like random failures of RAM, cosmic rays, omnipotent beings from other dimensions etc. - then everything is possible, but then the "Java" tag should be removed from the question.

update (after some comments under another answer)

I said "Java the Language", because the question conflates Java with JVM. Java programs can run on multiple VMs - and can be transpiled in different ways. Dalvik and JVM are common (hard to say which one is more common nowadays), but there's still a lot of code using two generations of the GWT compiler, TeaVM, RoboVM. The GraalVM is becoming more and more popular.

Java specification (aka Java the Language) is not affected by the physical world. It is an ideal of a language. Asking if it could be affected by a hardware failure is like asking if a meter could be shorter than 100cm if it was made from a poor material.

On the other hand - the real-world implementations of Java are affected by hardware failures, but the failures are not Java-specific. In most cases there will not even exist a mapping between the Java construct of a "variable" as described in the question and the low-level implementation (there will be a stack, or a register, or a key in a closure, or it might get optimized away completely).

So, the question either doesn't make sense, or it has little to do with Java.

fdreger
  • 12,264
  • 1
  • 36
  • 42
-1

Well, let's just answer your question.

Is it possible

Yes. of course.

Let's also answer some rather obvious, but unasked, followups:

How likely is this?

Very unlikely.

Does java have any built in protections, such as hashes of memory pages.

No.

rzwitserloot
  • 85,357
  • 5
  • 51
  • 72
  • "Is it possible? Yes. of course." - That is incorrect. – Jeff Scott Brown Sep 23 '20 at 13:28
  • Of course it's correct. You're on a computer, not a magic voodoo infallible god device. @fdreger it looks like we found the downvoter :) – rzwitserloot Sep 23 '20 at 13:59
  • "Of course it's correct" - It really isn't, not without a bug in the JVM anyway. The JVM does not allow you to point a reference at anything other than a valid memory address on the heap that has an object of the correct type, or `null`. Those are the only 2 things that an object reference can point to on the JVM. You can't get into a position where a reference is "pointing to wrong memory address due to memory bit flip ". The JVM doesn't allow it, bit flip or otherwise. – Jeff Scott Brown Sep 23 '20 at 17:09
  • "@fdreger it looks like we found the downvoter " - I didn't downvote fdreger's answer. I don't understand what he/she is saying. I downvoted rzwitersloot's answer, because it is misleading and I think is just false. – Jeff Scott Brown Sep 23 '20 at 17:11
  • 1
    @JeffScottBrown The question is pretty obvious, no. "due to memory bit flip (e.g. hardware failures)?" - OP is literally asking: "Can hardware failure cause this", and you are saying my answer is incorrect because the correct answer is: "No, that can't happen; not without hardware failures". ?????? – rzwitserloot Sep 23 '20 at 18:16
  • Thanks for all of your feedback. – Jeff Scott Brown Sep 23 '20 at 18:20