BR112015015865B1 - sistema e método para executar coleta de lixo - Google Patents

Abstract

SISTEMA, MÉTODO PARA EXECUTAR COLETA DE LIXO E MÉTODO PARA UMA MEMÓRIA DE ACESSO DE UMA ENTIDADE DE COMPUTAÇÃO. A presente invenção refere-se a uma memória gerenciada na qual múltiplas entidades de computação cada uma tem uma porção específica de entidade correspondente que está sujeita à coleta de lixo. Um armazenamento temporário imutável está localizado fora da memória gerenciada. Para uma dada entidade de computação, a porção de memória gerenciada correspondente contém objetos específicos de entidade que podem ser acessados por uma entidade de computação específica, mas não pelas outras múltiplas entidades de computação. Para uma ou mais das porções de memória gerenciada específica de entidade, a porção também inclui uma referência à memória compartilhada, tal como um armazenamento temporário imutável. A referência está estruturada para ser ignorada pelo coletor de lixo, apesar da referência poder parecer como um objeto normal na porção de memória gerenciada. Assim, um modelo de acesso de memória unificado é tornado possível no qual os métodos para uma entidade de computação acessar um objeto comum na memória gerenciada é similar a como a entidade de computação acessa a memória compartilhada.

Description

ANTECEDENTES

[0001] O desempenho de sistema de operação de computador é frequentemente caracterizado pela taxa máxima de operações de entrada/saída (I/O) (também denominada "desempenho de I/O") que o sistema de operação pode sustentar ao longo de um dado intervalo de tempo. Como um resultado, os sistemas de operação emprega uma variedade de mecanismos bem conhecidos para intensificar o desempenho de I/O.

[0002] Os sistemas de operação são tradicionalmente descritos utilizando linguagens não gerenciadas (tal como a linguagem assembly, C, C++) as quais provêm o programador de sistema com um controle muito fino de como a memória é manipulada. A utilização de apontadores não verificados pode ser utilizada para minimizar o overhead do sistema de operação e permitir um rendimento aumentado ou latência reduzida. A desvantagem da utilização destes apontadores não verificados é que estes são difíceis de criar e racionalizar, levando a um software não confiável e a vulnerabilidades de segurança.

[0003] Escrever um software em uma linguagem de programação gerenciada provê substanciais benefícios de exatidão e eficiências de tempo de desenvolvimento. Estas linguagens gerenciadas impedem os programadores de criar muitos tipos de defeitos de software, o que leva a uma qualidade de software aperfeiçoada e tempo de desenvolvimento reduzido. A exatidão de sistema de operação é um ingrediente crítico para fornecer uma experiência de computação confiável e segura. Portanto, utilizar linguagens gerenciadas para criar sistemas de operação é uma proposição convincente já que a confiabilidade de sistema de operação pode aperfeiçoar e os custos de  desenvolvimento podem ser reduzidos.

[0004] Para conseguir estes benefícios, as linguagens de programação gerenciadas inserem uma camada de abstração entre o código-fonte delineado pelo programador e os recursos de máquina brutos de um sistema de computador físico. Esta camada de abstração geralmente serve para restringir o que os programadores são permitidos escrever, e fazendo isto elimina categorias inteiras de defeitos potenciais. Infelizmente, esta camada de abstração introduz um overhead o qual pode ferir o desempenho do software que está sendo criado. Como um resultado, uma suposição comum é que as linguagens gerenciadas trocam os defeitos de exatidão por defeitos de desempenho. Com isto, um software escrito em linguagens gerenciadas é frequentemente inerentemente considerado mais lento do um software escrito em linguagens não gerenciadas.

[0005] O problema específico que afeta os sistemas de operação de código gerenciados é a necessidade inerente de copiar dados entre camadas conforme os dados se deslocam através do sistema. Isto é induzido pelo fato que componentes distintos do sistema existem em diferentes contextos de isolamento e não existe nenhum mecanismo claro para romper estes contextos de isolamento.

SUMÁRIO

[0006] De acordo com pelo menos uma modalidade aqui descrita, um sistema tem uma memória gerenciada na qual múltiplas entidades de computação cada uma tem uma porção de memória gerenciada específica de entidade correspondente que está sujeita à coleta de lixo. Um armazenamento temporário imutável está localizado fora da memória gerenciada. Para uma dada entidade de computação, a porção de memória gerenciada correspondente contém um ou mais objetos específicos de entidade que podem ser acessados por uma entidade de computação específica, mas não pelas outras múltiplas entidades de computação que têm as suas próprias porções de memória gerenciada específica de entidade.

[0007] Para uma ou mais das porções de memória gerenciada específica de entidade, a porção também inclui uma referência à memória compartilhada. Em uma modalidade, esta memória compartilhada pode ser um armazenamento temporário imutável. The referência está estruturada para ser ignorada pelo coletor de lixo, apesar da referência poder parecer como um objeto normal na porção de memória gerenciada. Por exemplo, talvez a referência seja um elemento de matriz. O coletor de lixo, no entanto, pode discernir entre outros objetos e a referência. Como um exemplo, o coletor de lixo pode procurar por um endereço na matriz, e se este endereço for uma localização fora da memória gerenciada, o coletor de lixo não executa uma coleta de lixo na referência.

[0008] Assim, um modelo de acesso de memória unificado é tornado possível no qual os métodos forem a entidade de computação acessar um objeto comum em uma memória gerenciada é similar a como a entidade de computação acessa a memória compartilhada. Este Sumário não pretende identificar as características chave ou características essenciais do assunto reivindicado, nem este pretende ser utilizado como uma ajuda na determinação do escopo do assunto reivindicado.

BREVE DESCRIÇÃO DOS DESENHOS

[0009] De modo a descrever o modo no qual as acima recitadas e outras vantagens e características podem ser obtidas, uma descrição mais específica de várias modalidades será oferecida por referência aos desenhos anexos. Compreendendo que estes desenhos apresentam somente modalidades de amostra e não devem, portanto, ser considerados limitando o escopo da invenção, as modalidades serão descritas e explicadas com especificidade e detalhes adicionais através da utilização dos desenhos acompanhantes nos quais: Figura 1 ilustra abstratamente um sistema de computação no qual algumas modalidades aqui descritas podem ser empregadas; Figura 2 ilustra um fluxograma de um método para prover um armazenamento temporário imutável; Figura 3A ilustra um ambiente no qual um processo para popular um armazenamento temporário ocorre; Figura 38 ilustra o ambiente no qual o armazenamento temporário populado é tornado imutável; Figura 39 ilustra um fluxograma de um método para utilizar o armazenamento temporário imutável; Figura 40 ilustra um ambiente no qual diferentes entidades de computação têm diferentes vistas de um armazenamento temporário imutável; Figura 41 ilustra um fluxograma de um método para comunicar os dados imutáveis de uma entidade de computação para a seguinte; Figura 42 ilustra um ambiente de fluxo no qual um fluxo de dados está provido de uma fonte de fluxo para um armazenamento temporário de fluxo, e então provido do armazenamento temporário para um consumidor de fluxo; Figura 43 ilustra um ambiente no qual uma segunda entidade de computação adquire um cache através de um cache de uma primeira entidade de computação; Figura 44 ilustra um fluxograma de um método para uma a segunda entidade de computação para primeiro ler de um cache suportado por uma primeira entidade de computação; Figura 45 ilustra um fluxograma de um método para a segunda entidade de computação para subsequentemente ler do cache suportado pela primeira entidade de computação; Figura 46 ilustra um fluxograma de um método para a primeira entidade de computação (ou o cache de apoio) para executar uma evicção; Figura 47 ilustra um exemplo de um sistema de código gerenciado; e Figura 48 apresenta uma matriz de bytes gerenciada normal a qual tem duas abrangências distintas que apontam para esta e que permitem que a aplicação veja porções da matriz como diferentes tipos.

DESCRIÇÃO DETALHADA

[0010] De acordo com as modalidades aqui descritas, mecanismos estão descritos que promovem uma semântica de entrada/saída (I/O de cópia zero em sistemas de operação gerenciados). Alguns de tais mecanismos podem ser utilizados em sistemas de operação de código não gerenciados assim como em sistemas de operação de código gerenciados. Os mecanismos não são mutuamente exclusivos já que um, alguns, ou mesmos todos os mecanismos podem ser combinados para ainda adicionalmente promover uma semântica de I/O de cópia zero.

[0011] "Cópia zero" refere-se a uma arquitetura projetada para permitir que dados entrem no sistema sendo escritos na memória e propagados através de muitas camadas de abstrações sem a necessidade de copiar os dados. Uma arquitetura de cópia zero não garante que nenhuma cópia de dados ocorra. Ao invés, esta meramente coloca no lugar um mecanismo para assegurar que a maioria de operações I/O possa ser feita sem copiar. Nesta descrição, "memória" é definida como qualquer memória de acesso randômico, a qual é tipicamente uma memória volátil, mas pode também incluir porções não voláteis, ou talvez ser inteiramente não volátil. Nesta descrição, "memória" é definida como o meio de armazenamento primário de um sistema de computação, comprometido de localizações endereçáveis individuais acessíveis aos microprocessadores do sistema de computação e acessíveis a dispositivos de hardware tal como controladores gráficos ou controladores de interface de rede através de mecanismos de DMA (acesso de memória direto).

[0012] Primeiro, os mecanismos de dados brutos de cópia zero compartilháveis imutáveis que utilizam um armazenamento temporário imutável de dados compartilhados serão descritos. Tais mecanismos permitem a transferência de grandes armazenamentos temporários de dados através de todo o sistema de computação sem cópias. Os mecanismos serão adicionalmente estendidos para a utilização compartilhada de fluxos de dados dentro do sistema de computação com controle de fluxo total para permitir uma eficiente utilização de recursos, tudo enquanto mantendo a semântica de cópia zero total. Apesar da segurança de tipo corrente de sistemas de código gerenciados permitir uma implementação mais imediata destes mecanismos, a utilização destes mecanismos dentro de sistemas de código não gerenciados pode ser empregada também.

[0013] Segundo, um mecanismo para cache de cópia zero sera descrito. Tal cache de cópia zero pode ser empregado tanto em sistemas de código não gerenciados quanto em sistemas de código gerenciados. O cache de cópia zero torna possível criar uma arquitetura de cache de uso geral que apresenta a semântica de cópia zero para os dados que entram no cache assim como os dados que estão sendo retornados do cache.

[0014] Terceiro, diversos mecanismos serão descritos que adicionalmente melhoram o desempenho de sistemas de código gerenciados, se estes sistemas empregam ou não o armazenamento temporário imutável ou dados compartilhados. Tais mecanismos de código gerenciados incluem um acesso de memória uniforme e casting de tipo de tipo seguro. Um acesso de memória uniforme permite que um código gerenciado acesse uniformemente tanto a memória gerenciada quanto memória não gerenciada (utilizada para os armazenamentos temporários de I/O) utilizando uma proposta consistente e componível. O casting de tipo de tipo seguro permite que o código gerenciado execute um cálculo de apontador para fornecer uma dada região de memória para ser vista como tipos distintos enquanto mantendo uma segurança de tipo total.

[0015] Alguma discussão introdutória de um sistema de computação será descrita com relação à Figura 1. Então os mecanismos acima listados serão descritos na ordem acima provida com relação às Figuras 2 até 13.

[0016] Os sistemas de computação estão agora crescentemente tomando uma ampla variedade de formas. Os sistemas de computação podem, por exemplo, ser dispositivos portáteis, utensílios, computadores laptop, computadores desktop, mainframes, sistemas de computação distribuídos, ou mesmo dispositivos que não foram convencionalmente considerados como um sistema de computação. Nesta descrição, o termo "sistema de computação" está definido amplamente como incluindo qualquer dispositivo ou sistema (ou sua combinação) que inclui pelo menos um processador físico e tangível, e uma memória física e tangível capaz de ter na mesma instruções executáveis por computador que podem ser executadas pelo processador. A memória pode tomar qualquer forma e pode depender da natureza e forma do sistema de computação. Um sistema de computação pode ser distribuído sobre um ambiente de rede e pode incluir múltiplos sistemas de computação constituintes.

[0017] Como ilustrado na Figura 1, na sua configuração mais básica, um sistema de computação 100 inclui pelo menos uma unidade de processamento 102 e um meio legível por computador  104. O meio legível por computador 104 pode conceitualmente ser imaginado como incluindo uma memória de sistema física, a qual pode ser volátil, não volátil, ou alguma combinação das duas. O meio legível por computador 104 também conceitualmente inclui um armazenamento de massa não volátil. Se o sistema de computação for distribuído, o processamento, a memória e/ou a capacidade de armazenamento podem ser distribuídos também.

[0018] Como aqui utilizado, o termo "módulo executável" ou "componente executável" podem referir a objetos de software, roteamentos, ou métodos que podem ser executados no sistema de computação. The diferentes componentes, módulos, máquinas, e serviços aqui descritos podem ser implementados como objetos ou processos que executam no sistema de computação (por exemplo, como encadeamentos separados). Tais módulos executáveis podem ser um código gerenciado no caso de serem executados em um ambiente gerenciado no qual a segurança de tipo é imposta, e no qual os processos são alocados aos seus próprios objetos de memória distintos. Tais módulos executáveis podem também ser um código não gerenciado no c aso de módulos executáveis sendo criados em código nativo tal como C ou C++.

[0019] Na descrição que segue, as modalidades estão descritas com referência a atos que são executados por um ou mais sistemas de computação. Se tais atos forem implementados em software, um ou mais processadores do sistema de computação associado que executa o ato direciona a operação do sistema de computação em resposta a ter instruções executáveis por computador executadas. Por exemplo, tais instruções executáveis por computador podem ser incorporadas sobre um ou mais meios legíveis por computador que formam um produto de programa de computador. Um exemplo de tal operação envolve a manipulação de dados. As instruções executáveis por computador (e os dados manipulados) podem ser armazenadas na memória 104 do sistema de computação 100. O sistema de computação 100 pode também conter canais de comunicação 108 que permitem que o sistema de computação 100 comunique com outros processadores sobre, por exemplo, a rede 110.

[0020] As modalidades aqui descritas podem compreender ou utilizar um computador de uso especial ou de uso geral que inclui um hardware de computador, tal como, por exemplo, um ou mais processadores e memórias de sistema, como abaixo discutido em maiores detalhes. As modalidades aqui descritas também incluem meios legíveis por computador físicos e outros para executar ou armazenar as instruções executáveis por computador e/ou estruturas de dados. Tal meio legível por computador pode ser qualquer meio disponível que possa ser acessado por um sistema de computador de uso geral ou uso especial. O meio legível por computador que armazena as instruções executáveis por computador são meios de armazenamento físicos. O meio legível por computador que carrega as instruções executáveis por computador são meios de transmissão. Assim, como exemplo, e não limitação, as modalidades da invenção podem compreender pelo menos dois tipos distintamente diferentes de meios legíveis por computador: meio de armazenamento de computador e meio de transmissão.

[0021] O meio de armazenamento de computador inclui RAM,ROM, EEPROM, CD-ROM ou outro armazenamento de disco ótico, armazenamento de disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outro meio de armazenamento tangível o qual pode ser utilizado para armazenar um meio de código de programa desejado na forma de instruções executáveis por computador ou estruturas de dados e os quais podem ser acessados por um computador de uso geral ou uso especial.

[0022] Uma "rede" é definida como uma ou mais conexões de dados que permitem o transporte de dados eletrônicos entre sistemas de computador e/ou módulos e/ou outros dispositivos eletrônicos. Quando as informações são transferidas ou providas sobre uma rede ou outra conexão de comunicações (ou com fio, sem fio, ou uma combinação com fio ou sem fio) para um computador, o computador apropriadamente ver a conexão como um meio de transmissão. O meio de transmissão pode incluir uma rede e/ou conexões de dados as quais podem ser utilizadas para carregar um meio de código de programa desejado na forma de instruções executáveis por computador ou estruturas de dados e os quais podem ser acessados por um computador de uso geral ou uso especial. Combinações dos acima devem também ser incluídas dentro do escopo de meio legível por computador.

[0023] Ainda, quando alcançando vários componentes de sistema de computador, o meio de código de programa na forma de instruções executáveis por computador ou estruturas de dados pode ser transferido automaticamente do meio de transmissão para o meio de armazenamento de computador (ou vice versa). Por exemplo, as instruções executáveis por computador ou estruturas de dados recebidos sobre uma rede ou conexão de dados podem ser armazenadas temporariamente em RAM dentro de um controlador de interface de rede (por exemplo, um "NIC"), e então eventualmente transferidas para a RAM de sistema de computador e/ou para um meio de armazenamento de computador menos volátil em um sistema de computador. Assim, deve ser compreendido que o meio de armazenamento de computador pode estar incluído em componentes de sistema de computador que também (ou mesmo primariamente) utilizam o meio de transmissão.

[0024] As instruções executáveis por computador compreendem, por exemplo, instruções e dados os quais, quando executados em um processador, fazem com que um computador de uso geral, computador de uso especial, ou dispositivo de processamento de propósito especial execute uma certa função ou grupo de funções. The instruções executáveis por computador podem ser, por exemplo, binários, instruções de formato intermediário tal como linguagem assembly, ou mesmo um código-fonte. Apesar de o assunto ter sido descrito em uma linguagem específica para as características estruturais e/ou atos metodológicos, deve ser compreendido que o assunto definido nas concretizações não está necessariamente limitado nas características descritas ou atos acima descritos. Ao invés, as características e atos descritos estão apresentados como formas exemplares de implementar as concretizações.

[0025] Aqueles versados na técnica apreciarão que a invenção pode ser praticada em ambientes de computação de rede com muitos tipos de configurações de sistema de computador, incluindo, computadores pessoais, computadores desktop, computadores laptop, processadores de mensagem, dispositivos portáteis, sistemas de multiprocessador, eletrônica de consumidor baseada em microprocessador ou programável, PCs em rede, minicomputadores, computadores mainframe, telefones móveis, PDAs, pagers, roteadores, comutadores, e similares. A invenção pode também ser praticada em ambientes de sistema distribuído onde sistemas de computador locais e remoto, os quais estão conectados (ou por conexões de dados com fio, conexões de dados sem fio, ou por uma combinação de conexões de dados com fio e sem fio) através de uma rede, ambos executando tarefas. Em um ambiente de sistema distribuído, os módulos de programa podem estar localizados em dispositivos de armazenamento de memória tanto locais quanto remotos.

DADOS BRUTOS DE CÓPIA ZERO COMPARTILHÁVEIS IMUTÁVEIS

[0026] Um maior desafio para suportar a cópia zero tem sido as interfaces de I/O em sistemas tradicionais as quais são definidas como operações de cópia entre diferentes camadas em um sistema. Uma Interface de Programa de Aplicação (API) de leitura aceita um armazenamento temporário de aplicação como entrada e preenche-o com dados de alguma fonte de dados. Similarmente, uma API de escrita toma um armazenamento temporário de aplicação e escreve o seu conteúdo em algum alvo de dados. A semântica das APIs de leitura/escrita concede à aplicação liberdade total para o alinhamento de armazenamento temporário, espaço de alocação e retenção. Este modelo simples tem diversas limitações inerentes sendo que o modelo é incapaz de expressar armazenamentos temporários não contíguos ou reduzir o número de operações de cópia de dados.

[0027] Muitos sistemas de operação suportam arquivos mapeados em memória como um mecanismo para compartilhar páginas no cache de armazenamento temporário de sistema de arquivo com aplicações e evitar as operações de cópia associadas com a interface de leitura/escrita. APIs especiais foram adicionados à interface de rede para diretamente enviar dados do cache de armazenamento temporário de sistema de arquivo utilizando mapeamentos de memória de arquivo para acelerar o tráfego de rede.

[0028] A abstração de arquivo mapeado em memória falta suporte para ocultar o alinhamento subjacente e esparsos layout de armazenamentos temporários e requer que as aplicações manipulem e gerenciem os mapeamentos virtuais e as vistas de dados lógicos diretamente. Por exemplo, uma aplicação acessando um arquivo em deslocamento 10 precisa aplicar uma aritmética de apontador sobre o endereço virtual de base de mapeamento para derivar endereço correto. Estender o arquivo enquanto este é mapeado requer que a aplicação gerencie vistas adicionais que podem não necessariamente estar contíguas em seu espaço de endereço e os acessos de vista transversal precisam ser manipulados pela aplicação.

[0029] Evitar cópia de dados através de arquivos mapeados em memória tem outras desvantagens. Assegurar uma consistência de semântica entre os arquivos mapeados em memória e as operações de leitura/escrita requer uma coordenação complexa entre I/O, memória e sistemas de arquivo. O I/O mapeado em memória impõe o overhead de completamento síncrono já que um erro de falta de página em um endereço virtual que mapeia a uma região de arquivo para o fluxo até que a página esteja disponível na memória física.

[0030] As técnicas de memória virtual de cópia em escrita também têm sido utilizadas para ocultar o custo de operações de cópia. Estas técnicas de cópia em escrita aliam as páginas de cache de aplicação e armazenamento temporário com base na suposição que é raro que as aplicações modifiquem os armazenamentos temporários de entrada no lugar. Isto dá ao sistema de arquivo uma oportunidade para colocar em cache as mesmas páginas físicas sem uma cópia. Para algumas cargas de trabalho, esta otimização pode evitar a operação de cópia ao preço de uma complexidade considerável especialmente quanto as pilhas de aplicação e armazenamento estão em diferentes domínios de proteção. Outras técnicas, tal como o remapeamento de página de memória virtual têm sido úteis para a rede receber percursos sob certas condições quando os armazenamentos temporários de aplicação estão apropriadamente alinhados.

[0031] A Figura 2 ilustra um fluxograma de um método 200 para prover um armazenamento temporário imutável. A Figura 3 A ilustra um ambiente 300A no qual um processo de popular um armazenamento temporário ocorre. A Figura 3B ilustra o ambiente 300B no qual o armazenamento temporário populado é feito imutável. Consequentemente, o método 200 da Figura 2 será agora descrito com frequentes referências às Figuras 3A e 3B. Os ambientes 300A e 300B podem ocorrer dentro do sistema de computação 100 da Figura 1, apesar de não requerido. Os ambientes 300 A e 300B podem estar distribuídos ou localizados em um único sistema de computação.

[0032] Os dados de fonte que devem ser utilizados para popular o armazenamento temporário são primeiro acessados por uma entidade de computação de aquisição (ato 210). Os dados de fonte podem ser quaisquer dados, mas em uma modalidade, os dados de fonte incluem grandes quantidades de dados brutos que requerem recursos de computação significativos de modo a gerar. Nesta descrição, uma "entidade de computação" é qualquer componente, módulo, método, função, processo, processador, ou qualquer sua combinação, que seja capaz de processar dados em um sistema de computação. Tal entidade de computação pode ser distribuída ou residir em um único computador.

[0033] The entidade de computação de aquisição pode gerar todos ou alguns dos dados de fonte (ato 211). Alternativamente ou além disso, a entidade de computação de aquisição pode adquirir todos ou alguns dos dados de fonte de uma fonte de dados (ato 212). Por exemplo, referindo à Figura 3A, a entidade de computação de aquisição 320 adquire (como representado pela seta 301) dados de fonte 311 de uma fonte de dados 310. A fonte de dados poderia ser, por exemplo, uma rede, ou um dispositivo de armazenamento não volátil tal como um disco.

[0034] A entidade de computação de aquisição também adquire um armazenamento temporário (ato 220). Esta aquisição de armazenamento temporário (220) está mostrada em paralelo com a aquisição de dados de fonte (ato 210), já que o aspecto mais amplo dos princípios aqui descritos não requerem que qualquer ato ocorra primeiro. No entanto, em alguns sistemas, um pode ser requerido antes do outro e/ou seus atos podem pelo menos parcialmente ocorrer concorrentemente. Referindo à Figura 3A, a entidade de computação de aquisição 320 adquire o armazenamento temporário 330 no grau em que a entidade de computação de aquisição pode então popular o armazenamento temporário 330 com dados.

[0035] Independentemente se a entidade de computação de aquisição gera os dados de fonte, ou recebe os dados de fonte de uma fonte de dados, ou ambos, a entidade de computação de aquisição popula o armazenamento temporário com dados (ato 230). Referindo à Figura 3A, por exemplo, a entidade de computação de aquisição 320 popula (como representado pela seta 302) os dados 311 dentro do armazenamento temporário 330.

[0036] O armazenamento temporário é então classificado como imutável (ato 240). A Figura 3B ilustra um ambiente 300B que é similar ao ambiente 300A da Figura 3A, exceto que os dados 311 estão mostrados presos dentro do armazenamento temporário 330, o qual está mostrado como tendo um limite hachurado cruzado 331 abstratamente representando que o armazenamento temporário 330 é agora imutável. Esta classificação protege os dados (por exemplo, dados 311) populados dentro do armazenamento temporário imutável (por exemplo, armazenamento temporário 330 na Figura 3B) de mudar durante o tempo de vida do armazenamento temporário imutável, e também protege o armazenamento temporário imutável de ter o seu endereço físico mudado durante o tempo de vida do armazenamento temporário imutável. Devido a esta característica imutável, o acesso aos dados imutáveis pode ser dado para um número arbitrário de entidades de computação sem o risco de conflito já que cada destas entidades de computação pode somente observar os dados.

[0037] Em um ambiente de linguagem nativa (tal como C ou C++), esta imutabilidade pode ser conseguida escrevendo em uma Unidade de Gerenciamento de Memória (MMU) de um processador para restringir o processador de escrever para certas faixas de memória. Isto pode ser bastante dispendioso, e a restrição em acessos de memória não é muito granular, sendo conseguida frequentemente no nível de página relativamente grande. Ainda, esta pode ser uma operação dispendiosa, e não evita circunstâncias na qual a cópia é executada de modo a ocultar dados de diferentes níveis em granularidades menores do que o nível de página.

[0038] Em um ambiente gerenciado (um ambiente que inclui um tempo de execução gerenciado), um software é utilizado para declarar a memória como imutável, e impor a imutabilidade. Mais ainda, o tempo de vida de um armazenamento temporário de memória pode ser mantido através de uma contagem de utilizações, a qual incrementa quando um novo apontador para a memória é dado para uma entidade, e decrementado quando um apontador para a memória não está mais sendo utilizado por uma entidade. Quando a contagem de utilizações retorna para zero, o armazenamento temporário é inalcançável, e pode ser reclamado pelo gerenciador de memória. Em uma modalidade, o núcleo concede autoridade para diferentes entidades acessarem a memória e mantém uma contagem de utilizações, enquanto que um tempo de execução gerenciado provê vistas sobre a memória imutável, impõe a imutabilidade, e provê restrições sobre os dados. Mais ambientes gerenciados de ambiente de visualização estão abaixo descrito com relação à Figura 12.

[0039] A Figura 4 ilustra um fluxograma de um método para utilizar o armazenamento temporário imutável. Primeiro um componente de vista oferece vistas flexíveis do armazenamento temporário imutável (ato 401), e então provê as vistas conforme apropriado para diferentes consumidores do armazenamento temporário imutável (ato 402). A entidade de computação então pode acessar o armazenamento temporário imutável somente através de sua respectiva vista (ato 403). Por exemplo, referindo ao ambiente 500 da Figura 5, uma primeira entidade de computação 501 acessa (como representado pela seta 521) o armazenamento temporário imutável 330 através de uma primeira vista 511, e uma segunda entidade de computação 502 acessa (como representado pela seta 522) o armazenamento temporário imutável 330 através de uma segunda vista 512. As elipses 513 mostram que isto pode continuar por mais do que apenas estas duas entidades de computação 501 e 502. As vistas 511 e 512 podem diferentes vistas, mas podem também ser a mesma vista. Independentemente, o componente de vista 520 é capaz de prover diferentes vistas do armazenamento temporário imutável 330 subjacente. Nesta descrição, os termos "primeiro" e "segundo" são utilizados meramente para distinguir um item de outro, e não implicam em qualquer tipo de sequência, prioridade, posição, ou importância.

[0040] Em algumas modalidades, as entidades de computação que consomem dados do armazenamento temporário imutável estão em diferentes lados de uma proteção ou limite de processo. Por exemplo, a Figura 5 ilustra que as entidades de computação 501 e 502 que consomem dados através de suas respectivas vistas 511 e 512 estão realmente separadas pelo limite 530. Por exemplo, as entidades de computação 501 e 502 podem ser processos distintos em cujo caso o limite 530 representa o limite entre os processos. O limite 530 pode também ser um limite de proteção em cujo caso pode-se não prover os dados diretamente para o outro sem copiar. Por exemplo, a entidade de computação 501 poderia ser um componente de núcleo dentro do sistema de operação, enquanto que a entidade de computação 502 poderia ser um componente de modo de usuário tal como um componente de aplicação.

[0041] Tipicamente, os dados não compartilhados através de limites de processo e proteção a menos que os dados sejam copiados. Tal cópia pode tomar uma quantidade significativa de recursos de computação, especialmente se a quantidade de dados copiados for muito grande, ou se diferentes porções dos dados devem ser frequentemente compartilhadas de tais limites. Os princípios aqui descritos provêm um mecanismo conveniente e flexível para compartilhar dados através de limites processo e proteção sem copiar. Isto por meio disto aperfeiçoa o desempenho do sistema de operação.

[0042] As vistas providas pelo provedor de vista 520 podem ser de grão fino. Por exemplo, suponha que os dados imutáveis a serem lidos do armazenamento temporário imutável são dados de rede. As várias camadas da pilha de protocolos podem cada uma estar interessada em diferentes porções daqueles dados de rede. Os componentes de nível de rede (tal como um componente de Protocolo de Internet) podem estar interessados nos cabeçalhos de nível de rede, enquanto que o componente de nível de aplicação pode estar simplesmente interessado na carga bruta. Entre estas duas camadas estão diferentes componentes que estão interessados em diferentes porções dos dados de rede.

[0043] Os princípios aqui descritos podem ser efetivamente aplicados ao processamento destes dados de rede sem requerer que os dados de rede sejam copiados. Por exemplo, o nível mais baixo da pilha de protocolos pode ser capaz de ver o pacote de rede inteiro. Este nível mais baixo pode processar o cabeçalho mais externo daquele pacote, e retornar uma definição de vista do próximo componente de nível mais alto na pilha de protocolos. A definição de vista define o escopo inteiro do pacote de rede exceto para o pacote mais externo. Este segundo componente provê a definição de vista para o provedor de vista 520, o qual provê esta vista para o segundo componente. Assim, o componente mais baixo vê o pacote inteiro, enquanto que o próximo componente vê o mesmo pacote sem o cabeçalho mais externo. Isto foi feito sem copiar dados de nenhum modo. Ao invés, os dados ficaram dentro do armazenamento temporário imutável. Isto pode ser repetido até que a camada de aplicação mais alta seja provida com uma definição de vista que define somente a carga do pacote.

[0044] A Figura 6 ilustra um fluxograma de um método 600 para comunicar os dados imutáveis de uma entidade de computação para a seguinte. Uma primeira entidade de computação acessa uma definição de vista (ato 601), e provê esta definição de vista para um provedor de vista (ato 602). O provedor de vista então provê a vista para a primeira entidade de computação (ato 603). Após a primeira entidade de computação executar sua lógica (ato 604), esta pode então prover outra definição de vista para a próxima entidade de computação (ato 605) que é processar os dados do armazenamento temporário imutável. A próxima entidade de computação pode então repetir este método 600, e assim o processo pode continuar através de múltiplas camadas do sistema.

[0045] Apesar do acima descrever armazenamentos temporários/fluxos de consumição em um modo de cópia zero, os princípios acima descritos podem também aplicar à produção de armazenamentos temporários e fluxos por um produtor de dados. No caso de um produtor de dados, existe também uma flexibilidade para a aplicação enviar os seus próprios armazenamentos temporários (alocados separadamente) ou pedir ao produtor de dados para prover vistas escrevíveis (Abrangências) para o seu próprio armazenamento temporário interno. Isto potencialmente não somente elimina a cópia, mas também aperfeiçoa a utilização de armazenamento temporário eliminando a necessidade de enviar armazenamentos temporaries meio preenchidos.

FLUXO DE DADOS DE CÓPIA ZERO

[0046] O movimento de dados brutos através de um sistema de operação é frequentemente modelado utilizando uma arquitetura de fluxo. Um fluxo representa um conduto lógico entre uma fonte de dados e um consumidor de dados, permitindo que os dados produzidos pela fonte sejam fornecidos para o seu destino. Os fluxos tipicamente implementam um armazenamento temporário de modo a acomodar as incongruidades de rendimento entre o produtor e o consumidor.

[0047] Por exemplo, a Figura 7 ilustra um ambiente de fluxo 700 no qual um fluxo de dados 711 está provido (como representado pela seta 701) de uma fonte de fluxo 710 para um armazenamento temporário de fluxo 720, e então provido (como representado pela seta 702) do armazenamento temporário 720 para um consumidor de fluxo 730. O ambiente 700 também inclui um gerenciador de fluxo 740 que executa um controle de fluxo. O gerenciador de fluxo 740 faz com que as porções de fluxo sejam alimentadas para o consumidor de fluxo 730 do armazenamento temporário 720 (como representado pela seta 702) em uma taxa satisfatória para o consumidor de fluxo 730. Mais ainda, o gerenciador de fluxo 730 executa uma leitura apropriada à frente do fluxo (como representado pela seta 701) para assegurar que a quantidade de porções de fluxo dentro do armazenamento temporário de fluxo 720 não são tão poucas que o consumidor de fluxo 730 esteja em risco de ficar sem as porções de fluxo, e não sejam tantos que uma quantidade de memória desnecessária do armazenamento temporário de fluxo 720 seja ocupada. O gerenciador de fluxo 740 também gerencia o tempo de vida das porções de fluxo dentro do armazenamento temporário de fluxo 720 de modo que a memória ocupada pela porção de fluxo possa ser reclamada uma vez que a porção de fluxo é consumida.

[0048] Os fluxos frequentemente logicamente cruzam múltiplos processos e/ou limites de proteção. Por exemplo, quando uma aplicação lê os dados de um arquivo, os dados são frequentemente lidos do disco físico sob o controle de um driver de dispositivo de modo protegido. Os dados então passam através de uma camada de sistema de arquivo camada, e então são finalmente tornados disponíveis para o código de aplicação. Frequentemente, o cruzamento de camada pode envolver uma cópia de dados a qual impacta o desempenho e o consumo de energia.

[0049] No entanto, os princípios do armazenamento temporário imutável de cópia zero acima descritos podem ser utilizados para formular um armazenamento temporário de fluxo (tal como o armazenamento temporário de fluxo 720) no qual a necessidade de copiar as porções de fluxo através de processos ou limites de proteção é eliminada.

[0050] Especificamente, suponha que um armazenamento temporário imutável (tal como aquele descrito com relação às Figuras 2 até 6) é estabelecido para da uma das múltiplas porções de fluxo no fluxo. Mais ainda, suponha que o método da Figura 2 e os processos das Figuras 3A e 3B sejam executados para criar um armazenamento temporário imutável associado que contém uma única porção de fluxo, cada vez que uma porção de fluxo é recebida.

[0051] Tal armazenamento temporário imutável permite que quaisquer dados, incluindo as porções de fluxo, sejam passados através de diferentes camadas e componentes do sistema, permitindo que cada um tenha a sua própria específica vista dos dados, sem requerer copiar os dados, como descrito com relação a dados gerais nas Figuras 5 e 6. O armazenamento temporário de fluxo 720 neste caso simplesmente seria uma coleção de armazenamento temporários imutáveis, cada um tendo uma porção de fluxo correspondente contida como dados nestes. Conforme cada porção de fluxo é consumida, a memória do armazenamento temporário imutável correspondente é permitida ser reclamada. Assim um fluxo de dados de cópia zero é possível utilizando os princípios aqui descritos.

CACHE DE CÓPIA ZERO

[0052] O cache é um aspecto importante de qualquer subsistema de I/O de sistema de operação. A latência é reduzida e o rendimento efetivo é aumentado alavancando o fato que os padrões de acesso de dados tendem a ser agrupados e os mesmos dados frequentemente recuperados múltiplas vezes. Um cache tradicional é feito tendo associações de memória dedicadas de camadas variáveis do sistema de operação gerenciadas independentemente cada uma com políticas de retenção e substituição ortogonal. Acessar os dados de um cache frequentemente envolve copiar dados de armazenamentos temporários de cache em armazenamentos temporários de aplicação.

[0053] Os princípios acima descritos com relação às Figuras 2 até 6 permitem o compartilhamento de armazenamentos temporário imutáveis entre processos e através de limites de proteção, através dos quais as chamadas de função não podem ser colocadas, mas ao invés uma comunicação interprocesso muito mais dispendiosa ou uma comunicação de limite de proteção cruzado deve ser utilizada para a comunicação através de limites.

[0054] Estes princípios podem ser utilizados para implementar um cache. Conforme os dados fluem de operação de Acesso de Memória Direto (DMA), os dados são introduzidos no sistema como armazenamentos temporários imutáveis (tal como o armazenamento temporário imutável 330 das Figuras 3A, 3B e 5). Os armazenamentos temporários imutáveis podem ser circulados ao redor do sistema para comunicar os novos dados e podem ao mesmo tempo ser um instantâneo em um cache para reutilização posterior. Quando uma solicitação posterior para os dados emerge, o mesmo armazenamento temporário imutável pode ser recuperado do cache e reutilizado - tudo sem nunca copiar ou realmente mesmo acessar os dados subjacentes. Isto leva a substanciais ganhos de eficiência.

[0055] Quando uma entidade de computação contém um cache que está baseado nos dados subjacentes no armazenamento temporário imutável, a entidade de computação tem uma "forte" referência para os dados subjacentes no armazenamento temporário imutável, e pode utilizar esta forte referência para acessar os dados do armazenamento temporário imutável. A utilização do termo "forte" para modificar a referência é meramente utilizada para distinguir a referência do que serão denominadas referências "suave" e "fraca" abaixo. Do mesmo modo, a utilização do termo "fraco" e "suave" para modificar a referência é meramente utilizada para distinguir as referências uma da outra e de uma forte referência.

[0056] Desde que qualquer entidade tenha uma forte referência para um armazenamento temporário imutável dentro do cache, o armazenamento temporário imutável e seus dados são garantidos continuarem a existir por pelo menos a duração da forte referência para cada entidade que tenha a forte referência. Uma referência "soft" para um armazenamento temporário imutável não pode ser utilizada para acessar dados do armazenamento temporário imutável sem primeiro converter a referência suave para uma forte referência. Uma forte referência pode ser convertida para uma referência suave uma vez que o acesso de dados seja completado.

[0057] A referência suave pode ser utilizada como uma forma de sugestão de gerenciamento de memória. Se existirem somente referência suaves para um dado armazenamento temporário imutável por qualquer entidade de computação e o sistema está ficando com pouca memória, o sistema pode escolher reclamar a memória que apoia este armazenamento temporário imutável. Se isto ocorrer, então a próxima tentativa de converter a referência suave em uma forte referência falhará. O conteúdo do armazenamento temporário será perdido e a entidade de computação precisaria regenerar o conteúdo de outro armazenamento temporário imutável da fonte de dados.

[0058] Esta referência suave é um modo valioso de utilizar tanta memória de sistema quanto possível para caches sem requerer uma alta precisão para sintonizar os tamanhos de caches no sistema. Por exemplo, um cache pode escolher conter uma grande porção de seus dados como referências suaves ao invés de fortes. A utilização de memória de outro processo pode então cravar grande o suficiente para acionar o sistema para um estado de baixa memória. O sistema pode então reagir rapidamente e liberar memória destas referências suaves sem precisar fazer nenhuma escolha sobre quanta memória dar para qual processo.

[0059] Uma entidade de computação pode também conter uma referência "fraca" para um dado armazenamento temporário imutável. Como com as referências suaves, uma fraca referência deve ser convertida para uma referência "forte" para permitir acesso aos dados dentro do armazenamento temporário imutável. Uma forte referência pode também convertida em uma fraca referência. A fraca referência provê uma segunda forma de gerenciamento de memória management para estes armazenamentos temporários. Se esta for utilizada para reter um acesso potencial para um armazenamento temporário imutável sem fazer com que a entidade de computação que contém a fraca referência seja carregada com a memória utilizada por aquele armazenamento temporário. Se existirem somente referências fracas para um dado armazenamento temporário imutável por qualquer processo, então o armazenamento temporário subjacente pode ser imediatamente liberado.

[0060] As referências fracas para armazenamentos temporaries imutáveis podem ser utilizadas para mitigar o custo de interprocesso e comunicações de limite de proteção cruzada que seriam requeridos para recuperar a forte referência para o armazenamento temporário imutável de outro processo que tem uma forte referência para o armazenamento temporário imutável. Isto é, um cache de fracas referências seria criado em uma entidade de computação (por exemplo, um processo) para mitigar os custos de recuperar estes armazenamentos temporários de outra entidade de computação (por exemplo, outro processo), mesmo se estes já estivessem em cache por aquela outra entidade de computação.

[0061] A Figura 9 ilustra um fluxograma de um método 900 para uma segunda entidade de computação para primeiro ler de um cache suportado por uma primeira entidade de computação. A Figura 10 ilustra um fluxograma de um método 1000 para a segunda entidade de computação para subsequentemente ler do cache suportado pela primeira entidade de computação. Juntos, os métodos 900 e 1000 permitem que a segunda entidade de computação construa um cache local com base no cache mantido pela primeira entidade de computação. Os métodos 900 e 1000 podem ser executados no contexto do ambiente 800 da Figura 8, e assim serão descritos com frequente referência à Figura 8.

[0062] Referindo primeiro ao ambiente 800 da Figura 8, uma primeira entidade de computação 810 tem um cache 811 de dados suportados pelo armazenamento temporário imutável 801. Uma segunda entidade de computação 820 é para adquirir dados do armazenamento temporário imutável também. A segunda entidade de computação 820 é também para manter um cache 812 de dados derivados do armazenamento temporário imutável 801. No entanto, o cache 812 é um cache fraco no sentido que este pode não aguardar por um comando de liberação da segunda entidade de computação antes de cessar existir. Assim, a segunda entidade de computação 820 não tem controle sobre quando o seu cache 812 é liberado.

[0063] Um limite 830 (um limite interprocessador ou proteção) está entre a primeira entidade de computação 810 e a segunda entidade de computação 820. Em uma implementação exemplar, suponha que a primeira entidade de computação é um sistema de arquivo, e a segunda entidade de computação é um servidor da web que serve e/ou processa arquivos providos pelo sistema de arquivo.

[0064] Quando a primeira entidade de computação adquire o cache (por exemplo, um cache de arquivo no caso de um sistema de arquivo), a primeira entidade de computação ganha um acesso mais rápido e mais local para os dados (com isto o termo "cache"), mas também adquire uma forte referência para o armazenamento temporário imutável que suporta o cache. A forte referência provê a garantia que o armazenamento temporário imutável (e seus dados) continuará a existir por pelo menos tanto tempo que o primeiro sistema de computação continuar a conter a forte referência (e potencialmente mais tempo se outras entidades também contiverem referências fortes para o armazenamento temporário imutável). Neste estado, inserimos a descrição da Figura 9, a qual ilustra um método 900 para a segunda entidade de computação (por exemplo, a segunda entidade de computação 820) para inicialmente ler do cache (por exemplo, cache 811) suportado pela primeira entidade de computação (por exemplo, a primeira entidade de computação 810).

[0065] A segunda entidade de computação comunica com a primeira entidade de computação para obter uma forte referência para os dados imutáveis (ato 901). Este é um interprocesso ou comunicação de limite de proteção cruzada, e assim é uma comunicação dispendiosa. No entanto, esta pode bem ser a única comunicação de limite cruzado requerida por enquanto o armazenamento temporário imutável que suporta o cache continuar a existir. Por exemplo, suponha o servidor da web recebeu uma primeira solicitação para um arquivo contido dentro do cache. Esta solicitação inicial pode fazer com que o servidor da web execute esta comunicação inicial e obtenha uma forte referência para o armazenamento temporário imutável do sistema de arquivo. Utilizando esta forte referência, a segunda entidade de computação pode ler os dados do armazenamento temporário imutável (ato 902). Quando ou após lendo os dados do cache, a segunda entidade de computação denota a forte referência para o armazenamento temporário imutável do que uma fraca referência para o armazenamento temporário imutável (ato 903).

[0066] A Figura 10 ilustra um fluxograma de um método 1000 para a segunda entidade de computação para subsequentemente ler do cache suportado pela primeira entidade de computação se o cache da segunda entidade de computação não tiver os dados. Quando recebendo uma solicitação para ler do cache enquanto a fraca referência para o cache ainda existe (ato 1001), a segunda entidade de computação determines se o armazenamento temporário imutável ainda existe (bloco de decisão 1002). Se o armazenamento temporário imutável ainda existir ("Sim" no bloco de decisão 1002), a segunda entidade de computação converte a sua fraca referência para uma forte referência para o armazenamento temporário imutável (ato 1011), lê do armazenamento temporário (ato 1012) (e localmente coloca em cache estes dados no cache local 812), e posteriormente converte a forte referência de volta para uma fraca referência (ato 1013). Isto é feito sem executar um interprocesso ou comunicação de limite de proteção cruzada com a primeira entidade de computação. Ao invés, a segunda entidade de computação simplesmente adquire uma vista sobre o armazenamento temporário imutável, e lê do armazenamento temporário imutável.

[0067] Se o armazenamento temporário imutável não ainda existir ("Não" no bloco de decisão 1002). Um interprocesso ou comunicação de limite de proteção cruzada é executado com a primeira entidade de computação para por meio disto fazer com que a primeira entidade de computação readquira os dados e recrie um novo armazenamento temporário imutável (ato 1021). Então, retornando para o método 900, a segunda entidade de computação pode então ganhar uma forte referência para um novo armazenamento temporário imutável (ato 901) e ler do armazenamento temporário (ato 902).

[0068] Assim, a segunda entidade de computação pode ser vista como tendo um cache fraco (um que pode precisar ser reconstruído antes que a segunda entidade de computação seja feita utilizando o cache fraco) que é derivado do cache forte da primeira entidade de computação (uma que permanece no lugar no controle da primeira entidade de computação). Construindo este segundo cache "fraco" no topo de outro cache forte cria alguns problemas com a política de substituição (ou evicção) no cache de apoio. Evicção refere-se a um mecanismo no qual menos dados utilizados (isto é, dados "frios") são removidos (ou evictos) do cache para dar mais espaço para dados mais frequentemente utilizados (isto é, dados "quentes"). A evicção está baseada em estatísticas referentes à frequência na qual certos itens de dados são acessados. O cache fraco 812 e o cache forte 811 têm estatísticas distintas referentes à frequência de acesso de porções de cache já que estes vêm diferentes solicitações para dados.

[0069] Especificamente, o cache fraco 812 será utilizado para servir as solicitações pela segunda entidade de computação 820 primeiro antes de cair de volta para o cache de apoio 811. Este cache fraco assim absorverá todas menos as referências iniciais aos dados quentes, ocultando a sua utilidade para o cache de apoio 811. Assim, quando o cache de apoio 811 recebe solicitações para novos itens, sem endereçar isto, o cache de apoio poderia fazer com que os dados que são "quentes" de acordo com as estatísticas do cache fraco 812, substituir itens que ainda estão sendo retidos pelo cache fraco 812. Esta substituição pode remover a última referência forte/suave persistente para o armazenamento temporário subjacente, liberando o armazenamento temporário que corresponde à fraca referência no cache fraco. A próxima solicitação para este item contra o cache fraco então falhará.

[0070] De acordo com as modalidades aqui descritas, este problema é resolvido comunicando a utilidade dos dados quentes (como visto pelo cache fraco 812) para o cache de apoio 811. O sistema pode prover este mecanismo como um efeito lateral quando a segunda entidade de computação converte uma fraca referência para os dados em uma forte referência para os dados. O sistema conta o número de vezes que isto ocorre por armazenamento temporário subjacente e expõe esta contagem como uma propriedade de metadados sobre o próprio armazenamento temporário. O cache de apoio pode então consultar este valor e determinar o número de referências que ocorreram entre quaisquer dois pontos no tempo. Esta informação pode ser utilizada pelo algoritmo de substituição do cache de apoio para manter este item vivo em ambos os caches.

[0071] A Figura 11 ilustra um fluxograma de um método 1100 para a primeira entidade de computação (ou o cache de apoio) para executar uma evicção. Primeiro, o cache de apoio uses suas próprias estatísticas de modo a identificar candidatos para evicção (ato 1101). O primeiro cache de apoio então confere com as segundas estatísticas do cache fraco por aqueles candidatos identificados (ato 1102). A decisão de evicção referente aos candidatos é então compromissada (ato 1103) após ter conferido com a segunda estatística de modo que se a segundo estatística indicar um acesso mais frequente do candidato identificado, o candidato identificado pode ser mantido dentro do cache pelo momento.

[0072] Estes primeiros três conceitos (a saber, Dados Brutos de Cópia Zero Compartilháveis Imutáveis, Fluxo de Dados de Cópia Zero, e Cache de Cópia Zero) podem ser aplicados em sistemas de código não gerenciados assim como em sistema de código gerenciado. No entanto, como as vistas providas pelos sistemas gerenciados podem ser criadas mais rapidamente e feitas de grão mais fino do que aquelas dos sistemas não gerenciados, os princípios podem ser mais efetivamente utilizados com os sistemas gerenciados.

[0073] A Figura 12 ilustra um exemplo de um sistema de código gerenciado 1200. O sistema gerenciado 1200 inclui uma memória gerenciada 1201. O sistema gerenciado 1200 tem múltiplos componentes de código gerenciado 1230, cada um tendo acesso exclusivo a uma memória específica de entidade. Por exemplo, os componentes de código gerenciado 1230 em execução estão ilustrados como incluindo sete componentes 1231 até 1237, apesar das elipses 1238 representarem grande flexibilidade neste número. Por exemplo, os componentes 1231 até 1237 podem ser processos.

[0074] Cada um dos sete componentes 1231 até 1237 em execução tem uma memória específica de entidade 1211 até 1217 correspondente. Um componente gerenciado pode não acessar a memória específica de entidade de outra memória específica de entidade. Assim, existe uma proteção de isolamento entre a memória específica de entidade de modo que somente o componente gerenciado correspondente pode acessar esta memória específica de entidade. Por exemplo, o componente 1231 acessa a porção de memória específica de entidade 1211, mas não as porções de memória específica de entidade 1212 até 1217; o componente 1232 acessa a porção de memória específica de entidade 1212, mas não a porção de memória específica de entidade 1211 ou as porções de memória específica de entidade 1213 até 1217, e assim por diante.

[0075] A memória de código gerenciado 1210 também inclui uma memória compartilhada 1219. Esta memória compartilhada 1219 é um exemplo do armazenamento temporário imutável 330 das Figuras 3A, 3B e 5. Isto dito, os princípios acima descritos não se baseiam em um sistema de código gerenciado de nenhum modo. No entanto, os dois conceitos finais aqui descritos estão limitados a ambientes gerenciados. Uns poucos elementos adicionais da Figura 12 serão descritos com relação à descrição destes dois conceitos finais (a saber, Acesso de Memória Uniforme e casting de tipo de Tipo Seguro).

ACESSO DE MEMÓRIA UNIFORME

[0076] Memória em um ambiente de linguagem gerenciado é uma coisa potencialmente muito dinâmica. Os objetos são alocados fora de um monte e são gerenciados por um coletor de lixo. Referindo à Figura 12, o sistema gerenciado 1200 inclui um coletor de lixo 1221. Com base em heurística, o coletor de lixo regularmente executa uma manutenção do monte compactando os objetos juntos de modo a reclamar um espaço previamente utilizado. Compactar os objetos juntos implica em que o endereço de memória de um objeto é essencialmente instável, sujeito a mudanças pelo coletor de lixo. The coletor de lixo depende de padrões de geração de código específicos e do suporte do sistema de operação para ser capaz de mover os objetos em um modo que seja transparente para o código de nível de aplicação.

[0077] Um subsistema de I/O do sistema de operação é responsável por misturar grandes quantidades de dados através de memória de sistema. Quando lendo, os dados são tipicamente adquiridos de um dispositivo externo e colocados na memória através de uma operação de DMA gerenciada pelo próprio dispositivo com interação mínima com o processador. Similarmente, quando escrevendo dados, operações de memória de DMA podem ser automaticamente lidas do conteúdo de memória.

[0078] As operações de DMA não podem competir com o conteúdo de memória que está sendo realocado durante operação. Fazer isto requereria uma coordenação de grão fino entre o processador e os dispositivos o que impactaria o desempenho e a eficiência de energia dramaticamente. Como um resultado desta restrição, existem duas amplas opções para suportar DMA em um sistema de operação gerenciado:

[0079] Operações de pinagem especiais são utilizadas contra regiões de memória para instruir o coletor de lixo para não realocar objetos especificados. Isto permite que as operações de DMA vejam um instantâneo consistente de memória afetada enquanto estas executam.

[0080] As operações de DMA ocorrem em regiões de memória especiais as quais não estão sujeitas à coleta de lixo.

[0081] A primeira proposta pode substancialmente prejudicar a eficiência do coletor de lixo já que lidar com regiões de memória pinadas complica o processo de compactação e reduz a sua eficiência. A segunda proposta evita este problema, mas pode levar a uma excessiva cópia de memória já que uma lógica especializada é necessária para transferir os dados entre regiões de memória normais e as regiões de memória amigáveis a DMA especiais.

[0082] Uma arquitetura de acesso de memória unificada fornece um meio sistemático para referenciar a memória, seja esta uma memória gerenciada normal ou regiões de memória amigáveis a DMA especiais. Isto torna possível para os programadores manipularem os dados em regiões de memória amigáveis a DMA diretamente em um modo completamente seguro, evitando tanto a necessidade de pinar objetos quanto copiar entre a memória normal e memória amigável a DMA.

[0083] Em um ambiente de linguagem gerenciada, os dados brutos são tipicamente mantidos em matrizes. O ambiente de linguagem gerenciada (por exemplo, o sistema gerenciado 1200) diretamente compreende as matrizes, permitindo acesso a elemento de matriz individuais e assegurando que os programadores não possam exceder os limites da matriz. Sendo gerenciadas pelo ambiente de linguagem, as matrizes estão restritas a serem localizadas no monte gerenciado.

[0084] No sistema gerenciado 1200 da Figura 12, o armazenamento temporário imutável 1219 está localizado fora do monte gerenciado e assim sob circunstâncias normais não seria diretamente acessível de programas gerenciados. Ler e escrever da memória I/O normalmente seria feito utilizando um pacote de I/O com operações leitura e escrita explícita as quais induzem uma cópia implícita entre a memória normal no monte gerenciado e a memória I/O.

[0085] O sistema gerenciado inclui uma abstração (aqui referida como "abrangência") a qual provê um mecanismo para diretamente acessar o armazenamento temporário imutável 1219 de um componente de código gerenciado. Referindo à Figura 12, a porção de memória gerenciada 1211 inclui uma variedade de objetos, incluindo a abstração abrangência 1240 abstratamente representada. As abrangências podem seguramente ser criadas para prover um acesso direto a qualquer de armazenamento temporário de I/O em um modo muito similar a como as matrizes funcionam. Ainda, as abrangências podem ser construídas para referenciar a memória gerenciada. As abstrações de software construídas no topo de abrangências podem, portanto, ser agnósticas à localização da memória subjacente da abrangência. Isto provê a última história de composição, permitindo que as abstrações sejam designadas em um modo natural para operar sobre a memória gerenciada (por exemplo, as porções de memória 1211 até 1218) ou do armazenamento temporário imutável 1219.

[0086] As abrangências são criadas interagindo com o armazenamento subjacente para a abrangência. Por exemplo, o armazenamento temporário imutável 1219 pode prover chamadas de método para retornar abrangências que referenciam os armazenamentos temporários imutáveis controlados pela abrangência diretamente. Similarmente, as matrizes provêm métodos que retornam abrangências que apontam para estas ou porções destas. Uma vez que uma abrangência foi materializada, esta pode ser passada adiante e utilizada grandemente como as matrizes são utilizadas em linguagens gerenciadas normais.

[0087] Uma sutiliza específica com as abrangências refere-se ao gerenciamento de tempo de vida do armazenamento subjacente. Um dos benefícios primário de um ambiente de programação gerenciado já que o coletor de lixo assume a responsabilidade de detectar quando os objetos não são mais referenciados e o seu armazenamento pode ser reciclado. Isto é o que acontece quando as matrizes não são mais úteis, por exemplo.

[0088] Quando a memória subjacente a uma abrangência está fora do monte coletado de lixo normal, então o tempo de vida daquela memória deve ser gerenciado cuidadosamente de modo que as abrangências criadas que referenciam a memória não sobrevivam ao próprio armazenamento de memória. Isto pode ser disposto em um número de modos, tal como utilizando contadores de referência na memória subjacente ou limitando o tempo de vida das abrangências estas próprias.

[0089] Em uma modalidade, um objeto de abrangência contém um apontador especialmente anotado para a região de memória que este representa. O coletor de lixo compreende estes apontadores especiais e trata-os especialmente. Durante uma operação de coleta de lixo, se o coletor de lixo encontrar um apontador especial este considera o endereço que o apontador contém. Se o coletor de lixo detectar que o apontador aponta para fora do monte gerenciado, o coletor de lixo ignora o apontador completamente daquele ponto em diante. Se ao invés, o apontador for descoberto apontar dentro do monte gerenciado, o coletor de lixo trata o apontador como uma referência para um objeto gerenciado e com isto automaticamente ajusta o valor do apontador na eventualidade que o objeto subjacente seja realocado.

[0090] As abrangências podem ser criadas para representar sub- regiões de outras abrangências. Isto torna as abrangências um modo muito conveniente para esculpir um monte de uma maior região de memória em um modo seguro e barato sem fazer cópias. A abrangência resultante se assemelha a qualquer outra abrangência mesmo se esta for mascarada para um subconjunto da memória de outra abrangência.

CASTING DE TIPO DE TIPO SEGURO

[0091] Um papel primário de linguagens de programação gerenciadas é impor uma segurança de tipo a qual impede que um programa tome um endereço arbitrário na memória e manipule-o como um objeto. Por exemplo, o sistema gerenciado 1200 da Figura 12 inclui um sistema de tipo 1222 que assegura a segurança de tipo. Todos os objetos são adquiridos explicitamente e o endereço de cada objeto é controlado firmemente pelo coletor de lixo (por exemplo, o coletor de lixo 1221). Em tal sistema, a memória não sob o controle direto do coletor de lixo não pode ser utilizada diretamente pelo código de aplicação. Ao invés, a memória acaba precisando ser copiada da memória especial de volta para a memória controlada pelo coletor de lixo antes desta poder ser utilizada, o que é ineficiente.

[0092] Conforme os dados fluem para dentro e para fora de um sistema através de operações de DMA, os dados manipulados pelos dispositivos de DMA tipicamente têm alguma forma inerente. Por exemplo, quando escrevendo dados através de DMA, alguma estrutura de dados no monte coletado de lixo tipicamente contém os dados que precisam ser escritos. Uma etapa "serialização" é então utilizada para transcrever os dados naquelas estruturas para a forma necessária para a operação de DMA. Esta etapa de serialização é tediosa, tendente a erros, e ineficiente. A serialização e desserialização são usualmente parte e parcela de linguagens de programação gerenciadas.

[0093] Alavancando a abstração de abrangência, um modelo de uso geral permite os programadores diretamente interagir com as regiões de memória de DMA utilizando semântica orientada em objeto. Um suporte de casting de tipo especial torna possível o programador ver as regiões de memória de DMA como objetos e com isto diretamente ler e escrever na memória em um modo natural, maximizando a eficiência, aperfeiçoando a exatidão e simplificando a tarefa do programador. O modelo estende além de meramente a memória de DMA e suporta uma semântica de casting de tipo estendido para a memória coletada de lixo normal também.

[0094] Para manter a segurança de tipo, não é possível nem desejável permitir o casting de tipo entre tipos arbitrários. Ao invés, regras específicas existem que restringem o conjunto de tipos permitidos que podem ser envolvidos neste casting de tipo estendido. As regras são bastante amplas, no entanto, e terminam funcionando perfeitamente para o tipo de dados usualmente envolvidos em operações de DMA.

[0095] Em uma linguagem de programação gerenciada, sempre que a memória estiver alocada é designado um dado tipo. O tipo determina a significância de diferentes porções do bloco de memória e as operações que podem ser executadas em relação ao bloco memória. O tipo não pode ser mudado para o bloco de memória até que a memória torne-se inativa e é reciclada através de um processo de coleta de lixo processo. O tempo todo, o ambiente de linguagem é responsável para alocar, digitar, e reciclar blocos de memória.

[0096] O casting de tipo é a capacidade de tratar alguma memória como um tipo outro que aquele que é conhecido ser pelo ambiente gerenciado. O casting de tipo é comum em linguagem de programação nativa, mas as linguagens gerenciadas geralmente não oferecem o casting de tipo. Ao invés, os ambientes gerenciados provêm mecanismos de conversão de tipo que tornam possível copiar um tipo de valor em outro tipo. Por exemplo, é possível converter um valor inteiro para um valor de ponto flutuante. Isto é sempre feito através de cópia, no entanto - a localização de memória original permanece inalterada.

[0097] De acordo com os princípios aqui descritos, o casting de tipo é introduzido como um instrumento de uso geral em linguagens gerenciadas. Restrições são aplicadas para assegurar que a segurança de tipo seja preservada, como posteriormente explicado.

[0098] Em um sistema de operação gerenciado, a memória utilizada para as operações de I/O deve ou ser objetos pinados ou ser regiões de memória dedicadas a I/O. Como anteriormente mencionado, pinar os objetos na memória para impedi-los de mover é dispendioso e leva a muitos problemas em um ambiente de lixo coletado. Os princípios aqui descritos utilizam uma memória de I/O dedicada no modo de armazenamentos temporários imutáveis (tal como o armazenamento temporário imutável 330 das Figuras 3A, 3B e 5).

[0099] A memória I/O está fora do alcance do subsistema de memória gerenciada. O ambiente gerenciado não controla o tipo desta memória e com isto não é possível diretamente acessar este tipo de memória de um programa gerenciado. Ao invés, um código de conexão especial (isto é, cola) normalmente seria utilizado de modo a permitir que esta memória seja lida ou escrita utilizando chamadas explícitas. Acessar qualquer tipo de dados estruturados dentro destes armazenamentos temporários de I/O envolve um código tremendamente ineficiente, ou envolve copiar dados para e da memória de I/O para a memória gerenciada normal, o que é também ineficiente.

[0100] Considere um armazenamento temporário imutável adquirido de um dispositivo de rede. Neste armazenamento temporário, existe um cabeçalho de TCP que contém informações de protocolo de rede. Existem basicamente dois modos que os dados no cabeçalho de TCP podem ser utilizados em uma linguagem de programação gerenciada. A tabela abaixo mostra ambas as propostas e as etapas envolvidas em cada uma.

[0101] Obter o objeto de cabeçalho de TCP utilizável é consideravelmente mais rápido com o casting de tipo então isto é com a proposta tradicional. A nova proposta imita o que acontece em um sistema de operação nativo, onde a matemática de apontador é possível e é aproveitada frequentemente neste tipo de cenário. A matemática de apontador não está disponível em linguagens de programação gerenciadas, mas o casting de tipo de tipo seguro fornece a mesma funcionalidade.

[0102] Variações são possíveis na proposta tradicional, o que leva a mais ou menos overhead. Por exemplo, é possível que o armazenamento temporário de memória em questão esteja diretamente disponível para o programador e assim pode ser acessado mais eficientemente do que utilizando os métodos de Ler/Escrever. No entanto, neste caso o programador é ainda responsável para transformar uma sequência de bytes em um objeto de nível mais alto o que é tedioso, tendente a erro, e funciona deficientemente.

[0103] O que torna o casting de tipo possível e a assegura que a segurança de tipo é preservada que o casting de tipo é somente possível com tipos que são projetados para permiti-lo. De modo a participar em casting de tipo, os tipos: 1) são tipos de valor (em oposição a tipos de referência), 2) são compostos somente de outros tipos os quais suportam o casting de tipo, 3) não são compostos de referências, 4) são definidos utilizando um layout de memória específico, e 5) toleram qualquer padrão de bit em qualquer de seus campos.

[0104] Estas restrições significam que de modo a ser utilizado para casting de tipo, um tipo não pode conter referência a outros objetos. Resulta que estas restrições perfeitamente descrevem as características de tipos definidos para representar formatos de dados como os cabeçalhos de TCPs e um vasto conjunto de outras tais estruturas de dados.

[0105] Como descrito, o casting de tipo seguro pode ser utilizado para ler ou escrever em armazenamentos temporários de I/O os quais estão localizados fora do alcance do ambiente de memória gerenciada, e pode também ser utilizado para ver a memória gerenciada como um tipo diferente. Especificamente esta técnica é útil para ver matrizes de bytes como instâncias de um ou mais tipos mais ricos ao invés.

[0106] A Figura 13 apresenta uma matriz de bytes gerenciada normal a qual tem duas abrangências distintas que apontam para esta e que permitem que a aplicação de porções de vista da matriz como diferentes tipos. Qualquer número de abrangências pode ser criado deste modo, cada um com tipos distintos. As abrangências podem livremente sobrepor, referindo potencialmente à mesma região de memória como tipos diferentes.

[0107] A regra que diz que qualquer padrão de bits deve ser tolerável em qualquer de seus campos é importante para a confiabilidade do modelo. Quando utilizando o casting de tipo, instâncias de objetos de outro modo parecendo normais são introduzidas no ambiente sem ter tido o construtor de tipo executado. Normalmente, um construtor executa a validação de argumentos de entrada e serve finalmente restringir o conjunto de valores permitidos que compõem um objeto. Mas com o casting de tipo, é possível criar um objeto do nada vendo uma abrangência de memória existente como se fosse um tipo diferente.

[0108] A proposta tradicional de copiar dados em um objeto distinto no monte gerenciado provê uma oportunidade para validar os dados conforme estes são empurrados para dentro do construtor do objeto gerenciado. Isto significa que em um sistema da vida real, versões inválidas do objeto gerenciado nunca existem dentro do sistema, o construtor assegura que somente versões válidas podem ser criadas. Contraste isto com o casting de tipo onde qualquer padrão de bits pode aparecer. Se existirem valores os quais são semanticamente inválidos, estes não podem ser detectados já que a construção de objeto não acontece.

[0109] A solução para o problema de exatidão é introduzir uma camada de abstração adicional no software. Especificamente, se tomarmos o exemplo de ler um cabeçalho de TCP novamente, pode- se imaginar que o desenvolvedor definiu dois tipos distintos: RawTcpHeader e ValidTcpHeader.

[0110] Os dados no armazenamento temporário de entrada seriam tipo de cast para um RawTcpHeader. Dado este objeto, então um método de AcquireValidTcpHeader pode ser invocado. Este método validaria os campos no RawTcpHeader e retornaria uma nova instância de ValidTcpHeader a qual atuaria como um invólucro trivial ao redor de um RawTcpHeader e diria para o detentor que ele tem um cabeçalho garantido válido em mãos. Isto é tudo feito sem uma cópia, meramente a criação de um objeto de passagem o qual é o tipo de valor de ValidTcpHeader.

[0111] A presente invenção pode ser incorporada em outras formas específicas sem afastar de seu espírito ou características essenciais. As modalidades devem ser consideradas em todos os aspectos somente como ilustrativas e não restritivas. O escopo da invenção é, portanto, indicado pelas concretizações. Todas as mudanças as quais vêm dentro do significado e faixa de equivalência das concretizações devem ser abrangidas dentro de seu escopo.

Claims (10)

1. Sistema, caracterizado pelo fato de que compreende: uma memória gerenciada que tem uma pluralidade de porções de memória gerenciadas, cada uma correspondendo a uma entidade de computação gerenciada; um armazenamento temporário imutável localizado fora da memória gerenciada, em que uma porção de memória gerenciada específica da pluralidade de porções de memória gerenciadas inclui um ou mais objetos coletáveis como lixo que são acessíveis para a entidade de computação gerenciada específica correspondente, mas não para as outras entidades de computação, a porção de memória gerenciada específica também incluindo uma ou mais referências ao armazenamento temporário imutável; e um componente de coleta de lixo configurado para gerenciar os um ou mais objetos coletáveis de lixo na porção de memória gerenciada específica, mas também configurado para não executar nenhuma ação sobre as uma ou mais referências ao armazenamento temporário imutável.

2. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que a memória gerenciada é um monte gerenciado.

3. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que o armazenamento temporário imutável é protegido de ter os seus dados mudados durante o tempo de vida do armazenamento temporário imutável.

4. Sistema, de acordo com a reivindicação 3, caracterizado pelo fato de que o armazenamento temporário imutável é protegido de ter o seu endereço físico mudado durante o tempo de vida do armazenamento temporário imutável.

5. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que pelo menos uma das uma ou mais referências é um elemento de matriz.

6. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que pelo menos uma dentre as uma ou mais referências inclui um endereço de pelo menos uma porção do armazenamento temporário imutável.

7. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que a porção de memória gerenciada específica é uma primeira porção de memória gerenciada, e a entidade de computação específica é uma primeira entidade de computação da pluralidade de entidades de computação, uma segunda porção de memória gerenciada da pluralidade de porções de memória gerenciadas também inclui um ou mais objetos coletáveis de lixo que são acessíveis para a segunda entidade de computação correspondente, mas não para as outras entidades de computação gerenciadas, a segunda porção de memória gerenciada também incluindo uma ou mais referências ao armazenamento temporário imutável.

8. Método para executar coleta de lixo por um sistema, sendo o sistema caracterizado pelo fato de que compreende: uma memória gerenciada que tem uma pluralidade de porções de memória gerenciadas, cada uma correspondendo a uma entidade de computação gerenciada; um armazenamento temporário imutável localizado fora da memória gerenciada, em que uma porção de memória gerenciada específica da pluralidade de porções de memória gerenciadas inclui um ou mais objetos coletáveis como lixo que são acessíveis para a entidade de computação gerenciada específica correspondente, mas não para as outras entidades de computação, a porção de memória gerenciada específica também incluindo uma ou mais referências ao armazenamento temporário imutável; e um componente de coleta de lixo, o método compreendendo as etapas de: gerenciar, pelo componente de coleta de lixo, os um ou mais objetos coletáveis de lixo na porção de memória gerenciada específica; e abster-se, pelo componente de coleta de lixo, de executar qualquer ação sobre as uma ou mais referências ao armazenamento temporário imutável.

9. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que outras porções de memória gerenciadas da memória gerenciada também incluem uma referência ao item fora da memória gerenciada.

10. Método, de acordo com a reivindicação 13, caracterizado pelo fato de que ainda compreende a etapa de: executar a coleta de lixo em objetos que não referenciam itens fora da porção de memória gerenciada.

Images