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

[Andrew Hughes]

----- Original Message -----
> 
> 
> > 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?
> 
> Yes, that is a no-op for all GCs except Shenandoah.
> 
> > 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?
> 
> Similar here: for all GCs other than Shenandoah, oopDesc::equals(a, b)
> expands to a==b, for Shenandoah we need to do a little bit of special
> handling to avoid false negatives in case a==b but we're getting two
> different copies of the same object.
> 

Ok, thanks for clarifying. Sounds like these could potentially be a
first round of upstream changes, building the way for Shenandoah.

Can we push these changes ASAP? Then I can add the security update on
top and we can get it out to end-users.

> Roman
> 
> 

-- 
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