[aarch64-port-dev ] RFR: Critical Shenandoah patch for interpreter

[Andrew Hughes]

----- Original Message -----
> Am Donnerstag, den 21.07.2016, 11:10 -0400 schrieb Andrew Hughes:
> > 
> > ----- Original Message -----
> > > 
> > > I've applied all the patches to my local copy, and here's the
> > > combined
> > > webrev:
> > > 
> > > http://cr.openjdk.java.net/~rkennke/merge-shenandoah/webrev.00/
> > > 
> > > Sorry, the webrev looks all messed up, but if you ignore all the
> > > rev
> > > lines, it should be good.
> > > 
> > Yeah, I was just going to say you have stuff like:
> > 
> > rev 196 : 6719955: Update copyright year
> > Summary: Update copyright year for files that have been modified in
> > 2008
> > Reviewed-by: ohair, tbell
> > rev 178 : 6695819: verify_oopx rax: broken oop in decode_heap_oop
> > Summary: Code in gen_subtype_check was encoding rax as an oop on a
> > path where rax was not an oop.
> > Reviewed-by: never, kvn
> > rev 113 : 6420645: Create a vm that uses compressed oops for up to
> > 32gb heapsizes
> > Summary: Compressed oops in instances, arrays, and headers. Code
> > contributors are coleenp, phh, never, swamyv
> > Reviewed-by: jmasa, kamg, acorn, tbell, kvn, rasbold
> > rev 0 : Initial load
> > 
> > Which version of Mercurial are you using?
> > 
> > I think you made need to update to the latest version of webrev:
> > http://mail.openjdk.java.net/pipermail/webrev-dev/2016-
> > January/000137.html
> 
> Right. Here's the correct webrev:
> 
> http://cr.openjdk.java.net/~rkennke/merge-shenandoah/webrev.01/
> 
> Roman
> 

Thanks.

My concern with this is the changes in the shared code. Are
they only applicable when Shenandoah is in use? Or should they
be considered upstream as more general fixes?

For example, the addition of:

+    oopDesc::bs()->interpreter_write_barrier(_masm, obj);

to src/cpu/x86/vm/templateTable_x86_64.cpp. Is this a no-op
if Shenandoah is not active?

With
-            (quicksuperk->class_loader()  == class_loader()))) {
+          (oopDesc::equals(quicksuperk->class_loader(), class_loader())))) {

in src/share/vm/classfile/systemDictionary.cpp. Is this not
a sensible cleanup that should go upstream?
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222