Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Alexander Kyte
    @alexanderkyte
    We should discuss documenting an interface for our AOT code for campy to implement if you’re interested @kaby76. I think @vargaz and @kumpera might be interested in that discussion.
    Alexander Kyte
    @alexanderkyte
    @lambdageek are we doing anything about mjit for the meeting?
    Aleksey Kliger (λgeek)
    @lambdageek
    What would you like to see?
    mazegen
    @mazegen
    Guys, first of all, thank you for this project that can help many to get deeper into the mono jit compilation process.
    Perhaps I'm not skilled in git enough - is there any way how to see only all the commit related to the mjit? This branch seems to be up-to-date with mono HEAD and it is hard to find all the relevant commits for me.
    mazegen
    @mazegen
    Or let's say it is updated from HEAD from time to time.
    For example, I'm interested in changes in method-to-ir.c
    Bernhard Urban
    @lewurm
    @mazegen: hi :smile:
    I think the easiest would be to git diff origin/master
    that said, there aren't any changes to method-to-ir.c. This file is essentially the front-end to the "Mini JIT compiler"
    the main goal of this managed JIT project is to come up with an interface, so we can plug in different JIT compilers. The main changes on the runtime side are in mini-runtime.c (yeah... the naming is... confusing)
    mazegen
    @mazegen
    @lewurm Hi, thanks for the help. I was confused by the MONO_CEE_MONO_JIT_ATTACH that was dropped later. I'm asking about method-to-ir.c because I know a little about the mini jit, in contrast to LLVM jit. I will dive into mini-runtime.cnow to get more familiar with the whole process.
    Bernhard Urban
    @lewurm
    @mazegen: MONO_CEE_MONO_JIT_ATTACH is another good example of "misleading names" :sweat_smile: JIT in that context means a thread that runs managed code (with the JIT). these days the JIT could be AOT'd code or the interpreter... so the name of this opcode should really be MONO_CEE_MONO_MANAGED_THREAD_ATTACH :smile:
    mazegen
    @mazegen
    @lewurm Yes, and speaking about this one, I found one commit by @lambdageek that doesn't show up in the commits listed by the GitHub link you posted earlier, I'm not sure why: https://github.com/lambdageek/mono/commit/766dacef2240ac046723e80aaba2cfbbf9caad90#diff-e7526071878d708680e4a8c5fa5a46ed
    Bernhard Urban
    @lewurm
    @mazegen because this commit actually happened on [github.com/mono/mono/master](http://github.com/mono/mono/master)
    mazegen
    @mazegen
    Ah, ok, thanks
    Bernhard Urban
    @lewurm
    the changes for the managed JIT project aren't upstreamed yet, so they live in the mjit branch on lambdageek/mono
    mazegen
    @mazegen
    Anyway, this commit's message say "Drop JIT attach: use coop attach in mini, aot and interp"
    Bernhard Urban
    @lewurm
    yep, it was removed recently :smile:
    it's related to the thread suspension mechanism in mono: Previously we had a preemptive suspension (via posix signals essentially) and we gradually moving forward to a cooperative suspension mechanism (by using safepoints)
    mazegen
    @mazegen
    So it was dropped because it was not compatible with coop?
    Bernhard Urban
    @lewurm
    yes
    mazegen
    @mazegen
    I'm just guessing here because the code is quite complicated :)
    Bernhard Urban
    @lewurm
    yes :disappointed:
    mazegen
    @mazegen
    Thanks again for the info, I'm going to study mini-runtime.c again soon :sweat_smile:
    juepiezhongren
    @juepiezhongren
    @lewurm can u list the main reason why bigstep is dropped, managed everything is a trend, current failure is a good lesson
    runtime components decoupling is a must
    Bernhard Urban
    @lewurm
    bigstep was done in the context of a "hack week" inside microsoft. it's a week where employees can try out new things without business justifaction
    while the idea is nice, it would take a long time to productise with little visible benefit for the end-users
    we didn't necessarily drop it, it's just we don't have a time budget to work on it currently. if you are interested to work on it, your contributions are very welcome :smile:
    juepiezhongren
    @juepiezhongren
    i just wonder why mstf hav not opened source midori, according to joe' articles, it seems a "bootstrapping" tech, and with the potential to bring us holy
    grail
    @joeduffy
    Bernhard Urban
    @lewurm
    as far as I know it was discontinued before MSFT jumped on the open source train
    unfortunately :disappointed:
    juepiezhongren
    @juepiezhongren
    yes
    but the code r still there, any place for our community to beg for its open source?
    Bernhard Urban
    @lewurm
    no idea :confused:
    juepiezhongren
    @juepiezhongren
    @lewurm after .net 5, will mjit be retried?
    Bernhard Urban
    @lewurm
    it has nothing to do with .net 5
    juepiezhongren
    @juepiezhongren
    i mean after,
    hahahaha
    juepiezhongren
    @juepiezhongren
    i just wander is it possible.that mstf build a managed "llvm"
    Alexander Kyte
    @alexanderkyte
    It’s not managed, but there’s a couple of other LLVM efforts https://github.com/dotnet/llilc
    Compatibility is the hard part in trying to make a new project
    juepiezhongren
    @juepiezhongren
    what is the diffs between llilc and mono' llvm part?
    Alexander Kyte
    @alexanderkyte
    They’re different VMs, with different layouts of generated runtime code and different optimization sets
    LLVM is the platform that both compile to