Академический Документы
Профессиональный Документы
Культура Документы
Processor
História do Java em Real-Time
1992 Oak for *7
1995 Java for the Internet
1996 Nilsen: First Paper on Real-Time Java
1997 picoJava, PersonalJava
1998 EmbeddedJava, RTSJ Start
2003 JTime
• Garbage collector: Esta funcionalidade do Java a princípio pode parecer ser uma boa
ferramenta para um sistema em tempo-real. Afinal, liberaria recursos de memória – muitas
vezes escassos – para o sistema. Porém se, por exemplo, sua custosa execução entrasse
em ação no momento em que uma tarefa crítica do sistema tivesse que ser realizada. Esses
tipo de comportamento é inaceitável.
• Threads : Java tem um modelo inserido para concorrência, que simplifica a programação
concorrente porém a definição destas funcionalidades são muito vagas para sistemas de
tempo-real. O comportamento das threads é definido de forma muito fraca, permitindo por
exemplo, que processos de menor prioridade preemptem outros de maior prioridade ou
mesmo uma implementação sem preempção é permitida. Isto protege as threads de
problemas como starvation mas não é aceitável em sistemas de tempo real.
• Controle e acesso de memória: Java traz restrições no acesso a memória. E certo
desperdício quando por exemplo, faz alocação dinâmica de classes, a resolução e verificação
de classes é uma função complexa, consome memória e seu tempo de execução é
praticamente impossível de prever.
• Outros problemas: sincronização de recursos, tamanho das bibliotecas, etc.
ESPECIFICAÇÃO JAVA PARA TEMPO REAL
O sucesso e aceitação da linguagem e a proposta inicial do Java que era para sistemas
embarcados, foi criado um grupo de peritos para estudar o melhoramento de Java para
sistemas de tempo real. O RTJEG (Real-Time for Java Expert Group) publicou em
novembro de 2001 a especificação de Java para Tempo Real – Real Time Specification
for Java (RTSJ).
A Sun deixou a implementação desta especificação a cargo da empresa americana
TimeSys. Em 2003 saiu a primeira implementação comercial, com uma implementação
de referência (Reference Implementation – RI) e um Technology Compatibility Kit
(TCK). Em 2005 a versão 1.0.1 e a versão atual é a 1.0.2. A JSR-282 (Java
specification request) que implementa melhorias foi aceita para uma versão 1.1 da
especificação.
A RSSJ traz algumas modificações para tempo
real:
• Threads e escalonamento: Um escalonador preemptivo básico, é definido, com 28
prioridades. Podendo outros escalonadores (como EDF) serem carregados
dinamicamente. Novas classes de threads são definidas: RealtimeThread acessa
todas as regiões de memória e é afetada pelo coletor de lixo;
NoHeapRealtimeThread só acessa a memória do escopo e pode sempre preemptar
o coletor de lixo(nunca é atrasada por ele); AsyncEventHandlers para tratar eventos,
pode ter prioridade maior que o coletor. Todas elas acabam sendo eventos
escalonáveis.
• Memória: Como o Garbage collector é problemático em aplicações de tempo real, a
RSTJ define novas regiões de memória. Immortal memory é a memória
compartilhada por todas as threads, sem coletor de lixo e permanece até o término
do programa. Scooped memory memória onde os objetos são alocados até que a
última thread a “deixe”. Phisycal memory usada para controlar a alocação em
memórias com tempo de acesso diferentes. Raw memory para acesso de memória a
nível de byte e mapeamentos de I/O.
A RSSJ traz algumas modificações para tempo
real:
• Sincronização: Herança de prioridade para controlar inversão de prioridades
• Eventos assíncronos: para conectar com os Asynchronous Event Handlers. Os
eventos podem ser disparados arbitrariamente por um método fire(), por
temporizadores, por sinais ou por ocorrências.
• Transferência de controle assíncrona: exceções de interrupção podem ser lançadas
por cada thread em uma thread específica. É segura, pode ser desabilitada (por
default) ou ativada em determinada thread.
Java virtual machine (JVM);
• Java virtual machine (JVM);
• Um conjunto de instruções - os
bytecodes;
• Um formato binário - o arquivo de
classe;
• Um algoritmo para verificar o
arquivo de classe;
O JOP foi conduzido com sucesso
para vários FPGAs e placas
diferentes. As principais placas
FPGAs utilizadas são:
• Altera Cyclone EP1C6 ou
EP1C12;
• Xilinx Spartan-3;
• Altera Cyclone-II (placa Altera
DE2);
• Xilinx Virtex-4 (placa ML40x);
• Xilinx Spartan-3E (placa
Digilent Nexys 2);
Outros Sistemas em tempo real que utiliza o
JVM
• picoJava
• SUN, never released
• aJile JEMCore
• Available, RTSJ, two versions
• Komodo
• Multithreaded Java processor
• FemtoJava
• Application specific processor
Performance
picoJava aJile Komodo FemtoJava JOP
Predictability -- . - . ++
Size -- - + - ++
Performance ++ + - -- +
JVM conf. ++ + - -- .
Flexibility -- -- + ++ ++
Processadores FPGA
Processor Resources Memory fmax
[LC] [KB] [MHz]
JOP min. 1077 3.25 98
JOP typ. 1831 3.25 101
Lightfoot 3400 1 40
Komodo 2600 - 33/4
FemtoJava 2000 - 4
NIOS 2923 5.5 119
SPEAR 1700 8 80
Microcode
• Prioridade fixa; }
Entrada em SC
Herda Prioridade P1
Fim de Execução da Sessão
Crítica
Executando em
SC
Inversão de prioridade
• Protocolo de emulação de teto prioritário:
• Cada recurso possui uma prioridade teto (prioridade igual a da tarefa mais prioritária
que pode alocar o recurso).
• Se nenhum recurso compartilhado está bloqueado, quem requisita é atendido.
• Se alguma tarefa bloqueia outra mais prioritária, a menos prioritária herda sua
prioridade.
• No caso de haver recurso em uso:
• A tarefa que solicita só consegue acesso ao recurso solicitado se sua prioridade for maior
que a prioridade teto de todos os recursos em uso alocados por outras tarefas.
Protocolo de Prioridade Teto
Seja P1 > P2 > P3 Legenda para os recursos
RC1 (Prioridade Teto = P1)
RC2 (Prioridade Teto = P1)
RC3 (Prioridade Teto = P2)
Tempo de término
P1
P2
P3 P2 P3
Garbage Collection para JOP
• O coletor pode operar em dois modos:
• (1) como coletor de stop-the-world disparado na alocação quando o
heap está cheio, ou
• (2) como colecionador concorrente em tempo real executando no
seu próprio thread.
• O coletor em tempo real é programado periodicamente na menor
prioridade e dentro de cada período
Collector para JOP
•Flip -troca as synchronized (mutex) {
useA = !useA;
if (useA) {
funções de copyPtr = heapStartA;
fromSpace = heapStartB;
tospace e toSpace = heapStartA;
} else {
fromspace. copyPtr = heapStartB;
fromSpace = heapStartA;
toSpace = heapStartB;
}
allocPtr = copyPtr+semi size;
}
Collector para JOP int addr =
Native.rdMem(addrStaticRefs);
Root Marking -Todas as int cnt =
referências estáticas são Native.rdMem(addrStaticRefs+1);
empurradas para a pilha. Apenas for ( i=0; i<cnt; ++i) {
uma única operação push push(Native.rdMem(addr+i));
precisa ser atômico. À medida } if (Native.rdMem(ref+OFF GREY)!=0) {
que as pilhas do thread estão return;
vazias, não precisamos de uma }
varredura de pilhas de threads. if (Native.rdMem(ref+OFF GREY)==0) {
// pointer to former gray list head
Native.wrMem(grayList, ref+OFF
GREY);
grayList = ref ;
}
} else if (flags==IS OBJ){
// its a plain object
// get pointer to method table
for (;;) {
Collector para JOP // pop one object from the gray list
synchronized (mutex) {
flags = Native.rdMem(ref+OFF MTAB ALEN);
// get real flags
flags = Native.rdMem(flags+MTAB2GC INFO);
ref = grayList ; for ( i=0; flags!=0; ++i) {
if ( ref==GREY END) { if (( flags&1)!=0) {
Mark and Copy-Um break;
}
push(Native.rdMem(addr+i));
}
objeto é exibido da pilha, grayList = Native.rdMem(ref+OFF GREY);
// mark as not in list
flags >>>= 1;
}
todos os objetos Native.wrMem(0, ref+OFF GREY);
}
}
// now copy it − color it BLACK
// push all childs
referenciados, que // get pointer to object
int addr = Native.rdMem(ref);
int size = Native.rdMem(ref+OFF SIZE);
synchronized (mutex) {
VSIS
Aplicações
• Kippfahrleitung
• Na carga ferroviária, uma grande quantidade de tempo é
gasto no carregamento e descarga de vagões de mercadorias.
Hardware
O dispositivo TAL consiste em um módulo CPU FPGA e
uma placa de E / S. O módulo FPGA contém um
dispositivo Altera Cyclone, 1 MB de memória estática, 512
KB Flash e 32 MB NAND Instantâneo. A placa de E / S
contém várias portas de entrada e saída digitais
protegidas EMC, duas 20 portas de entrada mA, conexão
Ethernet e uma interface serial. Além disso, o dispositivo
executa o carregamento de uma bateria recarregável para
sobreviver a falhas de desligamento. Ao desligar,
um evento importante para um fornecedor de energia, um
alarme é enviado. A bateria recarregável também é
monitorado e o dispositivo se desliga quando o limite de
tensão mínimo é alcançado.
Este evento é enviado para o sistema SCADA antes que
o poder seja desligado.
TeleAlarm
http://www.jopdesign.com/thesis/index.jsp
http://www.jopdesign.com/download.jsp
http://www.jopdesign.com/docu.jsp