Resumo de Java Programme

Como a "memory leak" manifestam-se em programas Java. A maior parte dos programadores sabe que uma das belezas em usar uma linguagem como o Java é que não mais têm de se preocupar com a aquisição e libertação de memória. Criamos objectos e o Java trata de removê-los quando já não são necessários pelo aplicativo usando um mecanismo chamado "garbage collection". Isto significa que o Java resolveu um dos desagradáveis problemas que infestam outras linguagens de programação -- o temido problema de "memory leak". Será que sim? Antes de entrar em mais detalhes, vamos começar por rever a forma como o "garbage collection" funciona. O trabalho do "garbage collector" é encontrar objectos que já não são necessários ao aplicativo e removê-los uma vez determinado que já não podem ser acedidos ou referidos. O "garbage collector" inicia este processo em nós raiz, classes que persistem durante todo o tempo de vida do aplicativo e efectua varrimento de todos os nós que são referidos. Enquanto percorre os nós, vai tomando nota de quais objectos têm referências activas. Qualquer classe que não esteja sendo referida é elegível para ser tratada pelo processo de "garbage collection". Os recursos de memória usados por esses objectos podem ser retornados à máquina virtual Java (JVM) quando os objectos são apagados. Portanto, é verdade que o código Java não necessita que o programador seja responsável pela limpeza de memória e é igualmente verdade que os objectos não usados são alvo de "garbage collection", ocorrendo isto de forma automática.
No entanto, o aspecto chave a ter em conta é que um objecto só é contabilizado como não usado quando não for mais referido. A figura 1 ilustra este conceito. Este pedido é para especificação de uma extensão "real-time". Esta extensão destina-se a às plataformas EmbeddedJavaTM, PersonalJavaTM, JavaOS for Business, JavaOS for Consumer e Enterprise Java (quando implantado num RTOS). A especificação necessitará de actualizações e/ou adições à especificação de máquina virtual Java e à especificação da linguagem (pelo menos a nível semântico).
Antevemos que essas modificações sejam retro compatíveis com a base actual instalada. A especificação aumentará a plataforma JavaTM com um conjunto de extensões "standard" que permitirá a construção de sistemas exibindo comportamento "real time". Irá trazer vantagens da plataforma Java -- portabilidade de código binário, carregamento dinâmico de código, suporte de ferramentas, fiabilidade, segurança e simplicidade -- a um segmento importante da indústria: sistemas de "real time" e "soft real time". Esta extensão é necessária uma vez que as garantias e APIs fornecidas pela plataforma "standard" Java não satisfazem as necessidades dos sistemas "real time". Por exemplo, os sistemas "real time" necessitam de garantias fortes e determinísticas e/ou controle nas àreas de escalonamento de "threads", sobrecarga de sincronização, ordem de enfileiramento de "locks", inicialização de classes, latência máxima de interrupções e características de "garbage collection". Essas necessidades não são satisfeitas pela plataforma "standard" Java e não existe qualquer outra extensão que as abranja. Propomos o desenvolvimento de uma extensão "standard" Java para "real time" e igualmente o desenvolvimento de implementação de referência. A especificação endereçará muitos aspectos, incluindo semântica do processo de "garbage collection", sincronização, escalonamento de "threads", interface JVM-RTOS e gestão de tempo com alta resolução. teconologia subjacente necessária à implementação da especificação é na essência uma máquina virtual Java construída de forma a suportar as garantias determinísticas de seu comportamento "real time". Um componente central desta VM é um processo de "garbage collection" que actue em "real time". Em adição ao GC, a VM necessitará ainda de suportar as outras garantias e APIs que aparecem na especificação. Esta VM será apenas implementável sobre plataformas adequadas, como é o caso de sistemas operativos "real time".

Resumos Relacionados