Компания
122,54
рейтинг
3 февраля 2015 в 22:52

Разработка → Ядро .Net (GC, JIT, interop, ...) в Open Source перевод

Мы рады сообщить что CoreCLR теперь находится на github и теперь вы имеете доступ ко всем его исходным кодам. CoreCLR является средой исполнения .NET Core, выполняя такие функции как сборку мусора или компиляции в конечный машинный код. .Net Core – это модульная реализация .Net, которая может быть использована как база для огромного количества сценариев, масштабы которых варьируются от простых консольных утилит до веб-приложений, хостящихся в облаке. Чтобы понять, чем отличается .Net Core от .Net Framework, посмотрите на пост «Введение в .Net Core»

Теперь вы можете скачивать исходники CoreCLR, бранчеваться, и делать pull requests, также вы можете компилировать его прямо на своем ПК. Мы выпустили полную и актуальную реализацию CoreCLR, которая включает RyuJIT, .Net GC, родной Interop и множество других компонент .Net runtime. Данный релиз следует тем же принципам, что и все наши последние релизы библиотек, вышедших в open-source: сделать весь .Net Framework open sourced.

Сегодня ядро .Net компилируется и отрабатывает (видимо имеется в виду CI) на Windows. Мы добавим имплементации для специфических для Mac и Linux платформенных вещей в ближайшие пару месяцев. Также мы уже имеем некоторый специфический для Linux код в .Net Core, однако мы только начали портировать с Windows на остальные платформы. Напротив, мы хотели открыть исходные тескты с самого начала, чтобы вы вместе с нами пропутешествовали бы к другим платформам, возможно, внося свой вклад.


Посмотрим, что же внутри репозитория


Репозиторий CoreCLR по своей структуре очень похож на репозитория CoreFX, в котором многие из вас в течении последних месяцев успели поработать.Мы будем продолжать развивать оба репозитория одновременно, чтобы вы по итогу чувствовали себя естественно, находясь в поистине огромной кодовой базе.

С точки зрения размера, репозиторий CoreCLR состоит из примерно 2,6 миллионов строк кода. Причем в рамках этих расчетов GC занимает около 55 тысяч, а сам JIT — около 320 тысяч строк. Также мы недавно поделились с вами, что CoreFX занимает 500 тысяч строк кода, что составляет около 25% от его предполагаемого итогового размера. И, страшно сказать, но когда все будет готово, мы будем иметь около 5 миллионов строк кода.на GitHub



Одним из ключевых различий между репозиториями является то, что CoreFX написан на C#, тогда как CoreCLR содержит огромное количества кода как C#, так и C++. Также репозиторий CoreCLR требует огромного количества тулов для построения кода, часть из которых не идет в поставку с Visual Studio. Мы оставили зависимость на CMake, opensource и кросс-платформенную систему построения проектов. Поскольку нам была необходима система сборки, которая прекрасно бы себя чувствовала и на Windiws, и на Mac, и на Linux, мы посмотрели на различные варианты и как итог, выбрали CMake.

Вы можете узнать, как собирать CoreCLR из CoreCLR Developer Guide. Команда будет постоянно обновлять его, особенно когда Linux и Mac станут реальностью.

Мы также очень надеемся, что сообщество внесет свою лепту в развитие проекта путем создания pull requests (от переводчика: CoreFX имеет огромное количество контрибьюторов, которые постоянно пишут код для CoreFX). .Net Core из-за своего размера работает на огромном количестве сценариев, и потому очень важно иметь большое количество тестов чтобы покрыть максимальное их количество.

Разговор с командой



По ссылке ниже вы можете посмотреть диалог с командой про текущий релиз:


Сборка приложений с .Net Core


Это очень здорово — видеть реализации .Net CoreFX и CoreCLR — в open source. И вы будете удивлены, какие типы приложений можно будет с ним построить. Есть два типа приложений, которые можно построить на текущий момент:
  • ASP.NET 5 Web-приложения и сервисы
  • Консольные приложения

Мы говорили про ASP.NET 5 приложения около года и теперь вы можете построить их используя как .Net Framework, так и CoreCLR/CoreFX. ASP.NET 5 использует mono runtime и может работать как на Mac, так и на Linux. Как только .Net Core станет поддерживать эти системы, вы сможете использовать его на этих платформах. Вы можете узнать больше, как работать с ASP.NET 5 из блога команды ASP.NET или на веб сайте asp.net. Также, если хотите попробовать ASP.NET 5 в деле прямо сейчас, то скачайте Preview версию MS Visual Studio 2015.

Мы хотим сделать возможным построение CoreFX и CoreCLR репозиториев и использовать результаты в приложениях ASP.NET 5, но пока это не является возможным по нескольким техническим причинам, однако мы работаем над этим. Конечная цель очень комплексная: мы должны иметь возможность сочетать изменений сообщества (forks) и наши собственные изменения и получать в итоге базовый стек для ваших приложений.

Консольный тип приложений позволяет понять что такое CoreCLR. Также он предоставляет очень гибкую базу для построения абсолютно любого приложения, какое бы вы ни захотели. Наибольший процент инфраструктуры. которую мы используем для тестирования использует именно этот тип приложения. Также вы можете построить свой собственный CoreCLR и запускать приложения поверх него.

.Net Core Console Apps


На данный момент консольный тип приложений для .Net Core является побочным продуктом нашего технологического процесса. И в течении нескольких последующих месяцев мы будем формировать его как полностью готовый тип приложений, включая шаблоны кода в Visual Studio и отладчик (т.е. его нет, похоже, — прим. перев.). Также мы будем поддерживать OmniSharp для консольных приложений (кто не знает — Sublime text 3 based IDE для .NET). Так что, скоро у вас будет полноценная возможность сборки кросс-платформенных приложений, которые будут запускаться с одного исполняемого файла.

Ниже представлена первая демка консольного приложения, запущенного под CoreCLR.



Console App Walkthrough


Самый простой способ построить CoreCLR приложение — создать консольное приложение. Вы можете получить его из нашего нового corefxlab репозитория. Для того, чтобы использовать его, вы можете просто клонировать, скомпилировать и запустить с помощью командной строки:
cd .\corefxlab\demos\CoreClrConsoleApplications\HelloWorld

nuget restore

msbuild

.\bin\Debug\HelloWorld.exe

Конечно же, поскольку вы склонировали репозиторий, также вы можете открыть файл *.sln в вашей копии Visual Studio. Прошу заметить что отладка пока не возможна… Но ведь она только для тех, кто делает ошибки, так?

Также вы можете модифицировать CoreCLR и запустить консольное приложение, которое будет использовать новый рантайм, который вы сами только что сделали, внеся изменения в ядро. На данный момент автоматизированной сборки не на самом высоком уровне, потому для того чтобы самостоятельно собрать ядро, на данный момент необходимо проделать следующие шаги:

  1. Модифицируйте CoreCLR так, как этого велит ваше сердце
  2. Постройте CoreCLR при помощи build.cmd x64 release
  3. Скопируйте фалы из coreclr\binaries\x64\release в corfxlab\demos\CoreClrConsoleApplications\HelloWorld\NotYetPackages\CoreCLR:
    1. coreclr.dll
    2. CoreConsole.exe
    3. mscorlib.dll
  4. Перекомпилируйте HelloWorld.sln


Итого


Мы готовились сделать CoreCLR открытым в течении нескольких месяцев, одновременно разрабатывая множество новых функций. Теперь у вас есть возможность наблюдать за ежедневной работой нашей команды коммит за коммитом (совершенно также, как и в CoreFX). Не стесняйтесь забрать себе репозиторий и наблюдать за этими изменениями. С нашей стороны мы будем наблюдать за списком Issues и PR чтобы иметь возможность следить за вашими пожеланиями.

Если вы взволнованы и настроены пообщаться с кем-либо, заходите на форумы .Net Foundation. Здесь вы найдете несколько веток, на которых вы можете узнать про CoreCLR получше. Также за ветками следят члены нашей команды, которые готовы отвечать на любые ваши вопросы.

У нас есть много чего, что надо сделать и следующая остановка — это .Net Conf — виртуальная конференция по .Net, которая намечена на март 2015 года и там мы надеемся показать вам хорошее демо
Автор: @sidristij .Net Team
Luxoft
рейтинг 122,54

Комментарии (40)

  • +3
    Вопрос в том, что будет в дальнейшем с Mono. Оно сейчас всё же реализует более полный набор .NET-а, нежели corefx/coreclr. Относительно corefx Мигель писал, что будут понемногу перетаскивать к себе нужные куски кода в тех местах, где с полнотой/безбажностью реализации плоховато.
    • +1
      А Мигель уже форкнул CoreCLR к себе. Возможно, Linux и Mac частью займется именно Xamarin. Они не одну собаку поели на этом
      • +8
        Я надеюсь, что Xamarin просто выкинут своё собственное ядро, воткнут вместо него CoreCLR, допишут функционал для Linux и Mac. И будет тогда полное счастье.
        • 0
          Не будет такого. На Windows/Linux/Mac мир не сошелся, существуют еще мобильные платформы и консоли, на которых вообще нельзя использовать JIT, например, и еще множество других ограничений. CoreCLR в своей идее просто недостаточно универсален, в то время как Mono изначально было задумано с максимальной кроссплатформенностью.
          • +3
            на которых вообще нельзя использовать JIT
            .NET Native же. Да и только GC заменить не помешает. Не прогуливали бы .NEXT, послушали бы доклад DreamWalker про то, какой весёлый GC в Mono.
            • 0
              А что, .NET Native уже заопенсорсили? Вроде бы он сам по себе сейчас в бете и даже не работает для обычных десктопных приложений, только для Windows Store Apps. Заменить GC, конечно, было бы здорово — я не понаслышке знаю, какой GC в Mono, мне для этого не нужно доклады слушать :)
  • +3
    Объемы исходного кода впечатляют… Один только JIT по объему как виртуальная машина mono целиком…
  • +5
    Надвигаются новые времена… это же круто!!!
  • +3
    Вот это да, не знал про OmniSharp и мучался с Xamarin Studio на маке.
    Интересно, неужели они и Visual Stutio сделают кроссплатформеной? Хотя это бессмысленное наверное.
    • +1
      Visual Studio на WPF написана, а вот кроссплатформенный WPF вряд ли случится в обозримом будущем.
      • 0
        Кстати… можно как альтернативу использовать XWT
        • 0
          XWT всё ещё достаточно сырой и имеет крайне ограниченный функционал. Для чего-то простого он сойдёт, но до поддержки нормального продакшена ему далеко. Студию на нём не напишешь.
          • 0
            Ну вот как раз ее они и написали на XWT =))) Но кроме нее, да, наверное, больше ничего =)
      • +1
        Очень хочется увидеть открытым\кроссплатформенным WPF.
        • +2
          Все-таки WPF работает поверх DirectX. Плюс к этому наверняка внутрях WPF есть завязка на специфичное для Windows поведение. А переписывать для увеличения абстракции и последующей реализации этих фич на новых платформах (причем с нуля) никто не будет.
          • +1
            А DirectX 9
            1) может быть реализован поверх opengl (см. wine)
            2) есть нативно в MESA при использовании gallium-драйвера (см. nine)
    • 0
      Вот если бы они исходники Visual Studio и компилятора C++ открыли бы — это было бы хорошо:)
      • –1
        Уже достаточно открытых компиляторов C++ получше чем от MS
  • +12
    Когда открыли компилятор шарпов кто-то сказал, что CLR не откроют никогда.
  • –2
    Вангую «да я тут ядро CLR патчу на выходных» на собеседованиях )))
    • 0
      Антивангую. Ну пару человек, включая вас, может быть. А кому это в энтерпрайзе надо?
      • 0
        Ну как-то да, так и есть )
  • +3
    > сможете бранчеваться
  • +7
    Теперь ждем очередную проверку исходников при помощи PVS-Studio от Andrey2008? Было бы очень интересно.
    • +8
      Всё может быть. Пока занимаемся с LibreOffice.
  • –2
    > И, страшно сказать, но когда все будет готово, мы будем иметь около 5 миллионов строк кода.на GitHub
    Если вы смотрели исходники, то наверно заметили, что половина кода это комментарии к нему.
    • 0
      Хм, это — перевод =)
    • +1
      Настаиваю на том, что комментарии — это тоже код. Во всяком случае, что-то, что помогает понять код, уж точно нельзя считать никак к этому коду не относящимся. Придумать другой способ описания тех или иных процессов в каком-то внешнем документе — полнейшая глупость. Выходит, как бы нам ни хотелось иного, комментарии — часть кода, а следовательно — тоже код.
      • 0
        Я думаю, считали просто количество строк в файле, без учета пустых строк и с комментариями -) А потому статистика корректна
      • –2
        Если удалить все комментарии, то программа будет работать как и раньше.
        Отсюда следует, что комментарии — не код.

        Я к чему. Есть масса проектов где практически нет комментариев. И это плохо, поскольку код сложнее читать и понимать.
        В случае .NET Core комментариев много и это хорошо. Но это в статье высвечено в негативном свете: «И, страшно сказать, но когда все будет готово, мы будем иметь около 5 миллионов строк кода.на GitHub», хотя полезного кода на самом деле будет не 5 миллионов (например), а 3.
        • +1
          Я — программист. И смотрю на код с точки зрения программирования. Если мне под рандомные два пальца запихнуть иголки, а к голове приставить пистолет, я все еще буду программист и смогу писать код остальными пальцами. Но мне будет не очень удобно. Конечно, можно удалить все комментарии отовсюду, но лучше тогда уж давайте остановимся на иголках под ногти. Либо давайте впадем в другую крайность, и тесты тоже не будем считать написанным кодом. Если тесты удалить, программа будет работать, как и раньше.
          • 0
            Я не говорю, что нужно удалить комментарии, а наоборот, сказал, что это хорошо, что они есть.
            Но при подсчете строк кода, предпочитаю считать код без комментариев и без тестов. И то и другое не имеет отношения к программе.

            Если идти по вашей логике, то программа может быть в 10 строк, а комментарии в 100 строк и 1000 строк тестов. Итого программа у нас на 1110 строк. Так?

            ЗЫ тесты можно рассматривать вообще как отдельную программу
            • +2
              Еще надо выстроить весь код в одну строчку — на исполнение то это не повлияет. Тогда в каждой программе будет ровно одна строка.
            • 0
              Также в защиту комментариев и тестов: тесты, как и комментарии — это тоже отдельная работа, и отдельный талант. Любой, кто хоть раз поддерживал легаси-код, со мной согласится. Километры нервов. Километры! Уж поверьте, если код выстроить в строчку, вреда не будет больше, чем если удалить комментарии… Alt+F, и всего делов. А коментарии…
        • +1
          Можно обфусцировать, заинлайнить — кода станет меньше? Промежуточные переменные — это не код?
          • 0
            Про обфускацию не говорили. Переменные конечно код. Но комменатрии это не код. Это комментарии.
            Также как комментарии к этой статье, не являются статьей. Статья и без каментов будет собой.
  • 0
    Чем отличается CoreCLR от CoreFX?
    • +1
      CoreCLR — ядро, runtime. CoreFX — набор библиотек. Collections, IO.File, и т.д.
      • 0
        Т.е., CoreFX — это новое название для BCL?
  • +4
    Желающие могут прочесть новую статью: PVS-Studio: 25 подозрительных фрагментов кода из CoreCLR

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка