Физическая адресация означает, что ваша программа действительно знает реальное расположение оперативной памяти. Когда вы обращаетесь к переменной по адресу 0x8746b3, она действительно хранится в физических чипах ОЗУ.
При виртуальной адресации все обращения к памяти приложения переходят в таблицу страниц, которая затем отображается из виртуального в физический адрес. Таким образом, каждое приложение имеет свое собственное «личное» адресное пространство, и никакая программа не может читать или записывать в память другой программы. Это называется сегментация .
Виртуальная адресация имеет много преимуществ. Он защищает программы от сбоя друг друга из-за плохого манипулирования указателем и т. Д. Поскольку каждая программа имеет свой собственный набор виртуальной памяти, ни одна из программ не может читать чужие данные - это одновременно и безопасность, и плюс безопасности. Виртуальная память также позволяет разбивать на страницы , где физическое ОЗУ программы может храниться на диске (или, теперь, более медленной флэш-памяти), когда оно не используется, а затем вызываться обратно, когда приложение пытается получить доступ к странице. Кроме того, поскольку только одна программа может быть размещена на конкретной физической странице , в физической системе подкачки либо a) все программы должны быть скомпилированы для загрузки по разным адресам памяти, либо b) каждая программа должна использовать Position- Независимый код или c) некоторые наборы программ не могут выполняться одновременно.
Физически-виртуальное отображение может быть сделано в программном обеспечении (с аппаратной поддержкой перехватов памяти) или в чистом аппаратном обеспечении. Иногда даже сами таблицы страниц находятся на специальном наборе аппаратной памяти. Я не знаю, с какой стороны, что встроенная система делает, но на каждом рабочем столе есть аппаратный TLB (Translation Lookaside Buffer, в основном кэш для виртуально-физических отображений), а некоторые теперь имеют расширенные модули отображения памяти, которые помогают с виртуальные машины и тому подобное.
Единственными недостатками виртуальной памяти являются сложность в аппаратной реализации и более низкая производительность.
Это больше, чем соглашение об именах, потому что события в пользовательских элементах управления автоматически получают префикс «On» в декларативном синтаксисе.
Например, у меня есть UserControl, который объявляет событие ProjectSelected. Чтобы добавить обработчик декларативно, я установил атрибут OnProjectSelected.
UserControl:
public event EventHandler<ProjectSelectedEventArgs> ProjectSelected;
Декларативное добавление обработчика:
<user:ProjectList id="uxProjectList" runat="server"
OnProjectSelected="uxProjectList_ProjectSelected" />
Добавление обработчика в код позади:
uxProjectList.ProjectSelected += uxProjectList_ProjectSelected;
Это меня до чертиков смутило дважды, один раз, когда я не мог ' Я выяснил, почему событие не было доступно декларативно, и снова, когда я назвал событие «OnProjectSelected», а атрибут стал «OnOnProjectSelected».
Those store references to the delegates that the calling code will be wiring up using events; in order to distinguish between the event itself, and the delegate.
It's just a naming convention used when raising events. OnSomethingHappened ... OnClick, OnChange, OnClose. I don't think there is anything magical or sinister, it's just a convention.
Semantically it is basically an old throwback to VB traditions where event listeners were generally called OnWhatever. Old habits die hard.