Instanceless virtual allocator methods

[dmlloyd]

There are cases - particularly around object allocation - where we could benefit from virtual method dispatch behavior despite not having a receiver instance to operate on.

For example, with object allocation, the base Object class has complex, customizable behavior (dealing with method headers for example, or eventually supporting lock nursery and lightweight locking optimizations), and subclasses may have additional interesting behavior (for example Throwable would record the stack pointer per #1778, and arrays would need to dynamically choose their allocation size and initialize the length immediately). These behaviors would precede constructor invocation, yet are type-dependent. Right now we just have distinct compiler-side code paths for these cases, but that ignores cases where the exact type ID could be unknown at compile time, and also puts somewhat heavy code in line with every allocation.

Right now VirtualMethodLookup operates on an object instance. But, it should probably be operating directly on a type ID value instead, with the default lookup behavior using an explicit Load to get the type ID. This would allow these loads to be more easily coalesced in addition to avoiding the requirement of having a valid this reference.

Since there is no this, it could be argued that the actual target instance method type would actually behave more like static. On the language side, there are pros and cons to having these methods be static. One significant con of using a static method on the language would be that the super.xxx() call would not work correctly. Since subclass allocators would generally call their superclass allocator first, this would be a significant hindrance. However, using instance methods on the language side means that we would have to do some special work to handle this. The easiest solution would be to reject any instanceless virtual method which accesses this. A more nuanced approach could be to add an intrinsic which implements a thisIs(xx) method, after which this becomes defined, e.g. thisIs(super.allocate()).

Another future use case for instanceless invocation would be optimization cases where this is not used in any reachable callee. Standard virtual methods could be transformed into their instanceless equivalents, allowing a more compact calling convention to be used instead of other techniques such as passing in null for this, which wastes a call value slot (typically a register).

[dmlloyd]

This also may imply that we need a way to acquire the receiver's type ID from a "static" context, particularly if the type ID becomes an implicit parameter for these types of methods (thought this could partially or completely invalidate the benefits of the aforementioned optimization). On a normal instance method, this would be equivalent to typeIdOf(this); on an instanceless method, it would read the implicit parameter similar to the manner of currentThread().