RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u

Roman Kennke rkennke at redhat.com
Thu Jul 9 19:08:05 UTC 2020


On Thu, 2020-07-09 at 18:59 +0000, Gil Tene wrote:
> > On Jul 9, 2020, at 8:04 AM, Roman Kennke <rkennke at redhat.com>
> > wrote:
> > 
> > 
> > > Now, about that proof: I will spend the day looking if we can do
> > > it
> > > by
> > > comparing object files of builds. E.g. do builds (-shenandoahgc)
> > > before/after a change is applied, run checksums over each object
> > > file,
> > > and compare those checksums. Let's see if there's any pitfalls
> > > there.
> > > 
> > 
> > I digged a little into this. I built JDK11u with and without the
> > patch,
> > and without debug-symbols (important), and compared the resulting
> > objects. I number of object files differ in their generated code,
> > and
> > they all look like:
> > 
> > mov $0x3e, %eax
> > vs
> > mov $0x44, %eax
> > 
> > In other words, constant numbers are different. I very strongly
> > suspect
> > that this is line numbers that are caught by __LINE__, for example
> > in
> > guarantee(). There are a number of other places where __LINE__ is
> > used.
> > Line numbers are not expected to be equal before/after the patch. I
> > could probably hack around that -- but would that still be in the
> > spirit of what we want to achieve? I have my doubts.
> 
> I agree that a difference purely around line number constants should
> not
> be considered a "difference" for the purpose of the proof you are
> looking
> for. The question is how to identify that…
> 
> Maybe instead of object files, we can go for differences in post-
> processed
> sources (basically the actual input to compilation)? I have a feeling
> that we'll
> run into issues there too, but at least there you can do some more
> textual
> analysis…

Yeah, I was thinking that too, but we have various places where we need
to include "utilities/macros.hpp" in order to get INCLUDE_SHENANDOAH_GC
and filenames, line-numbers, etc would be expanded into several files
too. It wouldn't be clean and require manual review - at which point we
can just as well review the original source changes, that seems easier
to read.

Roman



More information about the jdk-updates-dev mailing list