FULL PRODUCT VERSION :
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

FULL OS VERSION :
System Software Overview:
      System Version: OS X 10.11.1 (15B42)
      Kernel Version: Darwin 15.0.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal


A DESCRIPTION OF THE PROBLEM :
While using Collection.forEach() with lambda expression inside in certain cases after JIT compilations code logic is changed.

Example is: 
collection.forEach(demoId -> r.t = new JTuple6<>(null, programId, viewingPeriod.getId(), null, null, marketBreak));

viewingPeriod.getId() always returns not null values, but after JIT compilation null observed  at third position in JTuple6.

Initially I suspect it is Scala byte code issues and report example in Scala bug tracker https://issues.scala-lang.org/browse/SI-9828.
Person from Scala community Lukas Rytz (https://issues.scala-lang.org/secure/ViewProfile.jspa?name=rytz) has simplified my example and managed to reproduce it without Scala dependency, see https://github.com/lrytz/jit-bug/tree/master 

Seems issue is somewhere at intersection of lambda and JIT, since getting rid on lambda function in forEach make it work correctly.

THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: No

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Build example from sources https://github.com/lrytz/jit-bug/tree/master and try to run several times (I can reproduce it only if my mac works under load). At some point you will see log message that issue is reproduced.

EXPECTED VERSUS ACTUAL BEHAVIOR :
I'm expecting to get non-null values at third position of either scala.Tuple6 or custom JTuple class permanently, and not have expect seeing nulls randomly appeared after JIT work.
REPRODUCIBILITY :
This bug can be reproduced occasionally.

---------- BEGIN SOURCE ----------
https://github.com/lrytz/jit-bug/tree/master
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Removing lambda from forEach, or assigning viewingPeriod.getId() to local variable inside lambda cause this issue not reproducing anymore.