Uploaded image for project: 'JikesRVM'
  1. JikesRVM
  2. RVM-796

Generalize objectAsThread, objectAsType, etc. magic wih Magic.eatCast

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Medium
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.1.4
    • Component/s: Compiler: Optimizing
    • Labels:
      None

      Description

      We have a bunch of Magic.objectAsXXX methods. It would be nice to generalize these. We would like to be able to do:

      RVMThread t = (RVMThread)Magic.eatCast(o);

      instead of:

      RVMThread t = Magic.objectAsThread(o);

      since this results in fewer Magic methods. The semantics of eatCast would be as follows:

      • ignored in baseline compiler (because we don't care about performance there, and this will be used in runtime code that is opt compiled anyway),
      • any checkcast on the result of the eatCast() call is eliminated.

      Included is a patch that appears to implement this. Please review if you have a chance. I'm using it in my branch but it would be nice to get this into the trunk to simplify work for others doing similar things as me.

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            dgrove David Grove added a comment -

            If defining magic methods wasn't such an annoyance, then we wouldn't need this?

            if one could just write:

            @Intrinsic(typeconversion = "foo.bar.Baz")
            public native Baz castToBaz(Object o);
            

            and be done with it, then I'd think that we'd prefer that to eatCast.

            Asking because this should be possible after the next couple steps of magic implementation re-working that I'm doing in support of the VEE'09 paper.

            It's a shame that type erasure prevents us from writing

            @Intrinsic
            native T castTo[T](Object o);
            
            Show
            dgrove David Grove added a comment - If defining magic methods wasn't such an annoyance, then we wouldn't need this? if one could just write: @Intrinsic(typeconversion = "foo.bar.Baz" ) public native Baz castToBaz( Object o); and be done with it, then I'd think that we'd prefer that to eatCast. Asking because this should be possible after the next couple steps of magic implementation re-working that I'm doing in support of the VEE'09 paper. It's a shame that type erasure prevents us from writing @Intrinsic native T castTo[T]( Object o);
            Hide
            dgrove David Grove added a comment -

            Moving all unscheduled issues to 3.1. Please close or retarget to a different fix target as appropriate.

            Show
            dgrove David Grove added a comment - Moving all unscheduled issues to 3.1. Please close or retarget to a different fix target as appropriate.
            Hide
            dgrove David Grove added a comment -

            Defer to 3.1.1

            Show
            dgrove David Grove added a comment - Defer to 3.1.1
            Hide
            dgrove David Grove added a comment -

            bulk defer open issues to 3.1.2

            Show
            dgrove David Grove added a comment - bulk defer open issues to 3.1.2
            Hide
            dgrove David Grove added a comment -

            Bulk defer to 3.1.3; not essential to address for 3.1.2.

            Show
            dgrove David Grove added a comment - Bulk defer to 3.1.3; not essential to address for 3.1.2.
            Hide
            dgrove David Grove added a comment -

            bulk defer issues to 3.1.4

            Show
            dgrove David Grove added a comment - bulk defer issues to 3.1.4

              People

              • Assignee:
                Unassigned
                Reporter:
                pizlo Filip Pizlo
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated: