Виртуальная машина Java и CLR
Насколько я понимаю, на стороне сервера Вы не поддерживаете голоса по отдельности, Вы просто добавляете существующее голосование с новым голосом, полученным из внешнего интерфейса. Чтобы иметь возможность обновить отправленное сообщение, ваш сервер должен знать, какой был старый голос, предоставленный в старом Голосовании. Таким образом, чтобы реализовать обновление по выбору голосов, ваш клиент должен предоставить старый голос, а также новый голос, который будет обновлен, чтобы сервер мог вычесть старый голос и добавить новый голос.
Ниже приведен дополнительный класс на стороне клиента, который необходимо добавить в угловом формате.
public vote(id, oldNum, newNum) {
var voted = { id: id, oldVote: oldNum, newVote:newNum };
this.socket.emit('updateVote', voted);
}
Этот сервис вам нужно называть так же, как отправку нового голоса, но нужно предоставить oldVote и newVote.
Ниже приведен код на стороне сервера для принятия этого редактирования отправленного голосования. Здесь вам нужно добавить еще одного слушателя событий для редактирования пропущенного голоса.
socket.on('updateVote', (ballet) => {
messageList[ballet.id].rank -= ballet.oldVote;
messageList[ballet.id].rank += ballet.newVote;
io.to('main room').emit('new-message', messageList[ballet.id]);
});
Выше кода, вычитает уже проголосовал и добавляет новый голос.
5 ответов
Существует много общих черт между обеими реализациями (и по-моему: да, они - оба "виртуальные машины").
С одной стороны, они - оба стековый VM's, без понятия "регистров" как мы привыкли видеть в современном ЦП как x86 или PowerPC. Оценка всех выражений ((1 + 1) / 2) выполняется путем продвижения операндов на "стек" и затем сования тех операндов от стека каждый раз, когда инструкция (добавляют, делятся, и т.д.) должен использовать те операнды. Каждая инструкция продвигает свои результаты назад на стек.
Это - удобный способ реализовать виртуальную машину, потому что в значительной степени каждый ЦП в мире имеет стек, но количество регистров часто отличается (и некоторые регистры специального назначения, и каждая инструкция ожидает свои операнды в различных регистрах, и т.д.).
Так, если Вы собираетесь смоделировать абстрактную машину, чисто стековая модель является довольно хорошим способом пойти.
Конечно, реальные машины не управляют тем путем. Таким образом, JIT-компилятор ответственен за выполнение "enregistration" операций байт-кода, по существу планируя фактические регистры ЦП для содержания операндов и результатов, когда это возможно.
Так, я думаю, что это - одна из самых больших общностей между CLR и JVM.
Что касается различий...
Одно интересное различие между этими двумя реализациями - то, что CLR включает инструкции для создания универсальных типов, и затем для применения параметрических специализаций к тем типам. Так, во времени выполнения CLR полагает, что Список <интервал> совершенно другой тип из Списка <Строка>.
Под покрытиями это использует тот же MSIL для всех специализаций ссылочного типа (таким образом, Список <Строка> использует ту же реализацию в качестве Списка <Объект> с различными преобразованиями типа на границах API), но каждый тип значения использует свою собственную уникальную реализацию (Список <интервал> генерирует совершенно другой код из Списка <дважды>).
В Java универсальные типы просто прием компилятора. JVM не имеет никакого понятия, которого классы имеют аргументы типа, и это не может выполнить параметрические специализации во времени выполнения.
С практической точки зрения, которая означает, Вы не можете перегрузить методы Java на универсальных типах. У Вас не может быть двух различных методов, с тем же именем, расходясь только в том, принимают ли они Список <Строка> или Список <Дата>. Конечно, так как CLR знает о параметрических типах, он не имеет никаких проблемных методов обработки, перегруженных на универсальных специализациях типа.
На ежедневной основе вот в чем разница, которое я замечаю больше всего между CLR и JVM.
Другие важные различия включают:
CLR имеет закрытия (реализованный, поскольку C# делегирует). JVM действительно поддерживает закрытия только начиная с Java 8.
CLR имеет сопрограммы (реализованный с ключевым словом 'урожая' C#). JVM не делает.
CLR позволяет пользовательскому коду определять новые (структуры) типов значения, тогда как JVM обеспечивает фиксированный набор типов значения (байт, короткий, международный, долго, плавайте, дважды, обуглитесь, булевская переменная), и только позволяет пользователям определять новые ссылочные типы (классы).
CLR оказывает поддержку для объявления и управления указателями. Это особенно интересно, потому что и JVM и CLR используют строгие реализации сборщика "мусора" уплотнения поколений как их стратегию управления памятью. При обычных обстоятельствах строгое уплотнение GC приходится действительно нелегко с указателями, потому что при перемещении значения от одной ячейки памяти до другого все указатели (и указатели на указатели) становятся недопустимыми. Но CLR обеспечивает механизм "прикрепления" так, чтобы разработчики могли объявить блок кода, в рамках которого CLR не позволяют переместить определенные указатели. Это очень удобно.
Самая большая единица кода в JVM является или 'пакетом', как свидетельствуется 'защищенным' ключевым словом или возможно JAR (т.е. Архив Java), как свидетельствуется способностью к specifiy банка в пути к классу, и рассматривайте его как папка кода. В CLR классы агрегированы в 'блоки', и CLR обеспечивает логику для обоснования об и управления блоками (которые загружаются в "AppDomains", обеспечивая песочницы подприкладного уровня для выделения памяти и выполнения кода).
Формат байт-кода CLR (состоявший из инструкций MSIL и метаданных) имеет меньше типов инструкции, чем JVM. В JVM, каждая уникальная операция (добавляют два международных значения, добавляют два значения плавающих, и т.д.) имеет ее собственную уникальную инструкцию. В CLR все инструкции MSIL являются полиморфными (добавьте два значения), и JIT-компилятор ответственен за определение типов операндов и создания соответствующего машинного кода. Я не знаю, который является предпочтительно стратегия, все же. У обоих есть компромиссы. JIT-компилятор HotSpot, для JVM, может использовать более простой механизм генерации кода (это не должно определять типы операнда, потому что они уже кодируются в инструкции), но это означает, что этому нужен более сложный формат байт-кода с большим количеством типов инструкции.
Я использовал Java (и восхищался JVM) в течение приблизительно десяти лет теперь.
Но, по-моему, CLR является теперь превосходящей реализацией почти каждым способом.
Больше специфических особенностей различий может быть найдено в из различных академических и частных источников. После того как хорошим примером являются Проектные решения CLR.
Некоторые определенные примеры включают:
- Некоторые операнды низкого уровня вводятся такой как, "добавьте два ints", где, поскольку CLR использует полиморфный операнд. (т.е. fadd/iadd/ladd по сравнению только с добавляют),
- В настоящее время JVM делает более агрессивное профилирование во время выполнения и оптимизацию (т.е. Горячая точка). CLR в настоящее время делает оптимизацию JIT, но не оптимизацию во время выполнения (т.е. замените код, в то время как Вы работаете).
- CLR не встраивает виртуальные методы, JVM делает...
- Поддержка значения вводит в CLR вне просто "примитивов".
Это не виртуальная машина, платформа .NET компилирует блоки в собственный двоичный файл во время первого показа:
В вычислениях своевременная компиляция (JIT), также известный как динамический перевод, является техникой для того, чтобы улучшить производительность во время выполнения компьютерной программы. JIT полагается на две более ранних идеи в средах выполнения: компиляция байт-кода и динамическая компиляция. Это преобразовывает код во времени выполнения до выполнения его исходно, например, байт-код в собственный машинный код. Повышение производительности по интерпретаторам происходит из кэширования результатов перевода блоков кода и не просто переоценки каждой строки или операнда каждый раз, когда это встречено (см. интерпретируемый язык). Это также имеет преимущества статически компиляция кода во время разработки, поскольку это может перекомпилировать код, если это, как находят, выгодно, и может осуществлять гарантии безопасности. Таким образом JIT может объединить некоторые преимущества интерпретации и помех (заранее) компиляция.
Несколько современных сред выполнения, таких как Платформа.NET Microsoft, большинство реализаций Java, и последний раз Actionscript 3, полагаются на JIT-компиляцию для высокоскоростного выполнения кода.
Источник: http://en.wikipedia.org/wiki/Just-in-time_compilation
Сложение платформы.NET содержит виртуальную машину, точно так же, как Java.
Ваш первый вопрос сравнивает JVM с Платформой.NET - я предполагаю, что Вы на самом деле означали соответствовать CLR вместо этого. Если так, я думаю, что Вы могли записать маленькую книгу по этому (РЕДАКТИРОВАНИЕ: похож на Benji, уже имеет :-)
Одно важное различие - то, что CLR разработан, чтобы быть нейтральной в отношении языка архитектурой, в отличие от JVM.
Другое важное различие - то, что CLR был специально предназначен для обеспечения высокого уровня совместимости с собственным кодом. Это означает, что CLR должен управлять надежностью и безопасностью, когда к собственной памяти получают доступ и изменяют, и также справьтесь с маршалингом между основанными на CLR структурами данных и собственными структурами данных.
Для ответа на второй вопрос термин “виртуальная машина” является более старым термином от аппаратного мира (например, виртуализация IBM 360 в 1960-х), который раньше означал эмуляцию программного обеспечения/аппаратных средств базовой машины выполнять тот же вид материала, который делает VMware.
CLR часто упоминается как "механизм выполнения". В этом контексте это - реализация Машины IL сверху x86. Это также, что делает JVM, хотя можно утверждать, что существует важное различие между полиморфными байт-кодами CLR и введенными байт-кодами JVM.
Таким образом, педантичный ответ на Ваш второй вопрос является "нет". Но это действительно сводится к тому, как Вы определяете эти два условия.
Править: Еще одно различие между JVM и CLR - то, что JVM (версия 6) очень отказывается освободить выделенную память назад к операционной системе, даже там, где это может.
Например, скажем, то, что процесс JVM запускает и выделяет 25 МБ памяти от операционной системы первоначально. Код приложения затем делает попытку выделений, которые требуют дополнительных 50 МБ. JVM выделит дополнительных 50 МБ от операционной системы. После того как код приложения прекратил использовать ту память, он собран "мусор", и размер "кучи" JVM уменьшится. Однако JVM только освободит выделенную память операционной системы при определенных очень определенных обстоятельствах. Иначе, для остальной части времени жизни процесса, что память останется выделенной.
CLR, с другой стороны, освобождает выделенную память назад к операционной системе, если это больше не необходимо. В примере выше, CLR освободил бы память, после того как "куча" уменьшилась.
CLR и JVM являются оба виртуальными машинами.
Платформа.NET и среда выполнения Java являются связыванием соответствующего VMs и их библиотек. Без библиотек VMs довольно бесполезны.