Olá Pessoal, tudo bom?

Continuando a descrição sobre a Arquitetura da Java Virtual Machine, dentro do subsistema Runtime Data Area, vamos descrever sobre a parte do Method Area. Como você pode suspeitar essa área está relacionada com o armazenamento das informações sobre os métodos, parâmetros e variáveis estáticas de cada método. Lembrando que esse artigo continuará a utilizar alguns conceitos sobre arquitetura de sistemas operacionais, assim termos desconhecidos podem surgir no contexto desse artigo. Peço nesses casos que me envie comentários a respeito desses termos, para que eu possa complementar o artigo e responder suas duvidas.

Runtime Data Area

Relembrando…

No artigo sobre a Runtime Data Area, foi apresentada a Figura 01. Nessa figura foram exibidos alguns subsistemas existentes dentro dessa área.

Method Area

Dentro de uma instância da JVM as informações sobre os Tipos (Classes, Interfaces, Enums) são armazenados em uma área lógica chamada Method Area. Como já vimos anteriormente, para carregar as informações sobre um determinado Tipo, a JVM utiliza-se do subsistema Class Loader, o qual utiliza-se de um arquivo .class do tipo desejado e envia essas informações para o subsistema Runtime Data Area, mais precisamente a parte de Method Area. Como veremos mais adiante, o loading dessas informações não ocorre somente para classes, mas também para blocos estáticos, os quais podem conter métodos e instâncias de objetos.

A especificação da JVM não explicita como deverá ser a forma de representar cada tipo do Java, pois isso é decisão de cada desenvolvedor da JVM. Por exemplo, para tipos de quantidades multibytes, como BigInteger ou BigDecimal, a especificação da JVM indica que eles devem ser representados nos arquivos .class no padrão Big-endian order (byte mais significativo aparece por primeiro). No momento em que esses dados são importados para a Method Area, através do Class Loader, a JVM poderá armazená-los em qualquer formato, pois se o sistema operacional for escrito sobre uma arquitetura que utiliza o padrão Little-endian order, muito provavelmente a construção da method area ocorrerá nesse padrão.

A JVM se utiliza das informações que estão armazenadas na Method Area, sendo projetadas de acordo com sua utilização. Se a JVM for utilizada em um ambiente com baixa memória, isso significa que a implementação dessa parte deverá ser menos rápida, mas mais compacta. Se for o contrário, poderão ocorrer pontos redundantes dentro da Method Area, para aumentar a velocidade de execução da JVM. Assim o desenvolvedor da JVM possui a liberdade de utilizar qualquer tipo de estrutura desde que atenda a especificação desta. Um ponto importante é que todas as threads compartilham a mesma method area, assim as estruturas que são utilizadas dentro dessa área devem ser thread-safe, evitando colisões ou deadlocks.

O tamanho da method area não necessita ser fixo, pois conforme a necessidade da execução da JVM essa área poderá ser contraída/expandida. Além disso, não é necessário estar uma área contínua da memória, podendo estar alocada na Heap, até mesmo na própria área heap da JVM. Desenvolvedores poderão setar o tamanho mínimo e máximo, além do inicial para a method area.

Por fim, a área ainda pode sofrer intervenções do garbage collector, removendo as classes que não estão mais sendo referenciadas pela aplicação.

Armazenamento dos Tipos

Ao realizar o loading de um tipo, as seguintes informações deverão ser armazenadas na Method Area:

• O nome completo do tipo (Pacote onde está localizado o tipo + o nome do tipo)
• O nome completo do tipo super direto (Tipo Pai) do tipo que está sendo carregado (Exceto se esse tipo que está sendo carregado for uma interface ou a classe java.lang.Object, que não possui super)
• O tipo do tipo sendo carregado (Class, Interface ou Enum)
• Os modificadores do tipo (public, abstract, final, synchronize, entre outros aplicáveis ao tipo)

Lembrando que dentro dos arquivos .class, qualquer nome de um tipo Java é representado pelo nome completo. Por exemplo, se estiver sendo criado um atributo da classe String, no arquivo .class da classe será representado como java.lang.String. Outra modificação que ocorre é a substituição dos pontos por barras, assim o exemplo do atributo String ficaria como java/lang/String. Além das informações citadas acima, a JVM ainda poderá armazenar as seguintes informações para cada tipo:

• A Constant Pool do tipo
• Informações do atributo
• Informações do método
• Todas os atributos static declarado no tipo, exceto constantes (final)
• A referência para o Class Loader do tipo
• A referência para o arquivo .class do tipo

Constant Pool

Essa estrutura está contida dentro da Method Area e para facilitar o entendimento é muito parecida com um Set ordenado, onde temos um index e o value. Dessa forma, todos os literais (incluso string, integer e constantes de ponto flutuante), e referencias simbólicas (ponteiros) para tipos, atributos e métodos. Assim é possível perceber que a constant pool é uma estrutura de dados que irá armazenar a definições de quase todos os tipos declarados dentro da execução de um programa Java, tendo assim um papel central na linkagem dinâmica da linguagem.

Esse set possui um value que segue o padrão de codificação, conforme mostra a classe cp_info:

A informação referente ao atributo tag, indica que cada tipo adicionado dentro da constant pool deverá pertencer a um dos itens listados na Tabela 1 abaixo:

Constant Type	Value
CONSTANT_Utf8	1
CONSTANT_Integer	3
CONSTANT_Float	4
CONSTANT_Long	5
CONSTANT_Double	6
CONSTANT_Class	7
CONSTANT_String	8
CONSTANT_Fieldref	9
CONSTANT_Methodref	10
CONSTANT_InterfaceMethodref	11
CONSTANT_NameAndType	12
CONSTANT_MethodHandle	15
CONSTANT_MethodType	16
CONSTANT_InvokeDynamic	18

Tabela 01 – Tags da constant pool ((https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.4-140))

finnaly{

Em um próximo artigo estarei apresentando um exemplo de utilização da method area, não perca!

Duvidas ou sugestões? Deixe seu feedback! Isso ajuda a saber a sua opinião sobre os artigos e melhorá-los para o futuro! Isso é muito importante!

Até um próximo post!