refactor LambdaInfo

[vtjnash]

eventually, MethodInfo should be able to merge with Method in the MethodTable->defs
and LambdaInfo (MethodSpecialization?) should be able to replace Method in the MethodTable->cache

the difference between these types is very small in usage (resulting in a small amount of code duplication), but previously jl_lambda_info_t and been performing two nearly completely independent functionalities, identified only by which fields were active. this is a minor but annoying breaking internal change, so I figured doing it on the heals of the big renaming of LambdaStaticData was perhaps the best time to consider this.

the savings is small, but not entirely insignificant (~2% of sysimg)

[JeffBezanson]

To be removed?

[vtjnash]

the pure field, as it exists currently, is essentially a placeholder for "ast properties that inference wants to stash somewhere"

[JeffBezanson]

+1 Looks like a good direction to go, and I agree now is the time to do it. How soon do you think we can merge Method and MethodInfo? Would be good to get through as much of that change as possible.

[vtjnash]

I think I can replace the method caches with MethodSpecialization (renamed from LambdaInfo) fairly quickly. I think merging Method and MethodInfo could be pretty quick if I simply merge their fields and then fill them in as they become known. I think the tricky case is the code pattern from #10373, where some properties of the Method get filled in differently on each iteration (name, signature, tvars)

one other re-arrangement here that I think could be considered is reintroducing LambdaInfo as a limited subset of its current self that exactly replaces the existing ast field with fields. i'm not really certain how that should look (which is why i started this as an RFC).

[JeffBezanson]

Let's keep LambdaInfo; I think MethodSpecialization is too long. I think the LambdaInfo you have so far here is very close to its final form, and should be used by all producers and consumers of ASTs. Its inner "ast" field will actually be an array of statements, possibly encoded compactly. This array of statements can't be used on its own, and will always need the context info provided by LambdaInfo.

[StefanKarpinski]

Making methods more first class has the potential to simplify a number of reflection APIs. One that occurs to me off the top of my head is being able to call a Method on any arguments that satisfy its dispatch constraints. That would allow invoke to be defined in terms of finding a Method and calling it.

[JeffBezanson]

I think the real way to do invoke is to make a new function that contains only the selected method. Then specialization falls out naturally the way you expect. The question is where to store these per-method functions; currently we have a special field for caching them inside Method objects, which is what makes the feature somewhat "built in". It seems hard to make invoke efficient without that field.

[vtjnash]

I've now tried roughy 4 different variations on this idea to try out some different combinations of field divisions. fwiw, the current situation is roughly:

type Method
  next::Method
  sig::Type
  # fields for (cache) + reference to LambdaInfo (cache)
  # fields for (def) + reference to LambdaInfo (def)
end

type LambdaInfo
  ast
  # fields for (cache) + reference to LambdaInfo (def)
  # fields for (def)
end

# where (def) means reached as an entry from MethodTable.defs
# and (cache) means reached as an entry from MethodTable.cache

the commits vary in how they rearrange the fields among various old and new types. for example, the design of the latest commit (a202fd1 "merge LambdaInfo and MethodList, but split off AstInfo") is:

type Method # one entry in a MethodTable of a Function
  next::Method
  sig::Type
  code::AstInfo
  # fields for def
end # was LambdaInfo (def) + Method (def)

type AstInfo # a syntax tree
  def::Method
  ast
  # metadata for ast
end # was `linfo.ast`

type LambdaInfo # an executable thunk (also may be one entry in a cache)
  next::LambdaInfo
  sig::Type
  rettype::Type
  func # code (e.g. an AstInfo, but could be #undef for a builtin)
  sparam_vals # really a closure-env
  fptrs::Ptr{Void}
end # was LambdaInfo (cache) + Method (cache)

[JeffBezanson]

I don't really understand this field. The fact that it's not always the same type makes me a bit suspicious.

[vtjnash]

this commit was an exploration in making LambdaInfo the minimal set of fields to make it a purely executable thunk (without any extraneous metadata like an AST, name, debug info, etc.)

it was an abstract representation of the contract fptr(this, sig) -> rettype where fptr = compile(func)

[JeffBezanson]

I see that it makes sense to separate a code object from something that is actually executable, due to (1) a Method definition only contains "raw code" and nothing you can actually execute yet, (2) being executable brings in lots of extra objects (pointers to native code), (3) we need to add static parameters. But I'm not yet 100% sold on splitting LambdaInfo.

Issue 1: IIUC, LambdaInfo.sig is sometimes the types the code was specialized on, and sometimes a method cache key. I find this confusing. I also think we should be able to efficiently use the same compiled code for many method cache entries, by pointing to the same object. Especially with jb/functions there can be bad cases where we might need a large number of such entries. We could, for example, represent the method cache like a typical linear probing hash table, with alternating keys (types) and LambdaInfo pointers in a flat array. I think that might also resolve my confusion about the func field, since it could then always be an AstInfo.

Issue 2: We should probably stop calling these things ASTs. They are not syntax trees, and could even become bytecode. If we do this split I think AstInfo should be called something like Code, and LambdaInfo something like Runnable. Those names probably aren't ideal, but they should clearly convey the difference between the two types.

[vtjnash]

Issue 1: IIUC, LambdaInfo.sig is sometimes the types the code was specialized on, and sometimes a method cache key....

agreed. i was exploring whether it could make sense to merge the two ideas (as can easily be done for Method) and remove the distinction between your two usages. the experiment worked and provided some intriguing flexibility in what a LambdaInfo could represent / do, but i have mostly concluded that it was not an overall improvement.

my current plan forward was to scratch that last commit, keeping only a few things from it:

1. removal of unspecialized logic from gf.c (i liked how it could become a property of codegen, rather than method dispatch. i believe this was a nice reduction in code duplication, at the expense of possibly making calling a function generator marginally more expensive).
2. giving CodeInfo (née AstInfo) a unique type. per discussions with @carnaval, we should try to design this such that we aren't modifying the LambdaInfo during type-inferenece as an additional criterion / benefit (i'm not sure exactly what he wants there, however)

Issue 2: We should probably stop calling these things ASTs.

sure, it seems reasonable to switch to a more generic term such as IR or Code for this

[vtjnash]

replaced by #15779