Is RegisterMap updated?

[David Griffiths]

Oh, I'm looking at the jdk8u code which has the following code commented out:

    /*
    if (map.getUpdateMap()) {
      // Tell GC to use argument oopmaps for some runtime stubs that need it.
      // For C1, the runtime stub might not have oop maps, so set this flag
      // outside of update_register_map.
      map.setIncludeArgumentOops(cb.callerMustGCArguments());

      if (cb.getOopMaps() != null) {
        OopMapSet.updateRegisterMap(this, cb, map, true);
      }

      // Since the prolog does the save and restore of EBP there is no oopmap
      // for it so we must fill in its location as if there was an oopmap entry
      // since if our caller was compiled code there could be live jvm
state in it.
      updateMapWithSavedLink(map, savedFPAddr);
    }
    */

I see that is no longer commented out in jdk9 so maybe that's the
cause. (There is nothing else that calls setLocation).

Cheers,

David

On Tue, 29 Jan 2019 at 13:41, Andrew Haley <aph at redhat.com> wrote:
>
> On 1/29/19 11:24 AM, David Griffiths wrote:
> > Hi, in CompiledVFrame.createStackValue there is the following code:
> >
> >       // First find address of value
> >       Address valueAddr = loc.isRegister()
> >         // Value was in a callee-save register
> >         ? getRegisterMap().getLocation(new VMReg(loc.getRegisterNumber()))
> >         // Else value was directly saved on the stack. The frame's
> > original stack pointer,
> >         // before any extension by its callee (due to Compiler1
> > linkage on SPARC), must be used.
> >         : ((Address)fr.getUnextendedSP()).addOffsetTo(loc.getStackOffset());
> >
> > It appears from what I can make out that for the register case the map
> > is not updated and so valueAddr is null. The only thing I can see that
> > calls setLocation is updateMapWithSavedLink. Seems like it should be
> > possible to return the register value for the frame at the top of the
> > stack though?
>
> It could be, but we don't do that. The registers in the map are those
> pushed onto the stack by generated Java code.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671