Skip to content

GitLab

WARNING! Access to this system is limited to authorised users only.
Unauthorised users may be subject to prosecution.
Unauthorised access to this system is a criminal offence under Australian law (Federal Crimes Act 1914 Part VIA)
It is a criminal offence to:
(1) Obtain access to data without authority. -Penalty 2 years imprisonment.
(2) Damage, delete, alter or insert data without authority. -Penalty 10 years imprisonment.
User activity is monitored and recorded. Anyone using this system expressly consents to such monitoring and recording.

To protect your data, the CISO officer has suggested users to enable 2FA as soon as possible.
Currently 2.7% of users enabled 2FA.

Closed
Created by John Zhang@u5157779Developer

Redesign the undefined function handler API

Created by: wks

Current status

Currently there are two handlers: trap handler and undefined function handler. They are different.

In trap handlers:

  • Thread is temporarily unbound from the stack, and is rebound after trap handling.
  • Stack is unbound and is ready for introspection.
  • OSR (pop frame, push frame) is possible.

In undefined function handlers:

  • Thread is, conceptually, still executing the CALL instruction that calls the undefined function.
  • The stack is in the RUNNING state, not available for introspection or OSR
  • The client must define the function. Then CALL will be tried again. i.e. If the client does not define the function, it will loop forever.

This asymmetry is complicating the interface.

  1. The undefined function handling API leaves no room for errors in loading the bundle. If, in Java, the client puts a stub for an unloaded method, and there is an error when loading the class, then the client has no other things to do than "defining" the method as "doing nothing but throwing an exception". This isn't very nice.
  2. It leaves the stack and the thread in a strange state: they cannot continue, but still "RUNNING".
  3. Introspection and OSR are impossible.

Proposed change

I propose unifying the two interfaces.

Let undefined functions behave like:

.funcdef @undefined_function VERSION noversion <sig> (a1 a2 a3 ...) {
  %entry:
    TRAP <void> KEEPALIVE (a1 a2 a3...)
    undefined behaviour after TRAP
}

That is, an undefined function behaves like executing a trap with all parameters as keep-alive variables.

Add an extra API call:

MuID (*cur_func)(MuCtx *ctx, MuStackRefValue stack, int frame)

It returns the ID of the function of the current frame. It works even if the function is not defined. Return 0 if the frame is native.

Modify the cur_func_ver API call: It returns 0 when the frame is a frame without version (undefined function).

So a client can identify an undefined function by "cur_func != 0 && cur_func_ver == 0". FYI:

  • cur_func != 0 && cur_func_ver != 0: a defined Mu function
  • cur_func != 0 && cur_func_ver == 0: an undefiend Mu function
  • cur_func == 0 && cur_func_ver == 0: native frame
  • cur_func == 0 && cur_func_ver != 0: impossible

Modify the cur_inst API call: It returns 0 if the frame is just created (before the first instruction), is native, or if the function is not defined.

Modify the dump_keepalives API call: It dumps keep-alive variables for OSR point instructions, or the arguments to an undefined function. Cannot be used on native frames or a just-created frame.

The pop_frame and the push_frame API behave like before. Specifically to undefined functions, popping an undefined function frame reveals its caller to the top of the stack. After loading a bundle that defines the function, a push_frame can re-creates the callee frame, but this time the callee is defined. The client can also choose not to rebind to the same stack, but swap away. Or just throw an exception (probably ClassNotFoundException) to the caller without defining the callee.

About the NEWSTACK instruction

Creation of the stack will be successful, but it will trap when executing the undefined function after binding the stack to a thread.