Marcos Roriz $:

Pessoal, Geek, Anime, Jogos, Ciência da Computação e Open Source…

Archive for the ‘Ciência da Computação’ Category

Updates…

leave a comment »

Hello guys, sorry for the lack of updates, been a busy week here.
The progress so far is that I’m ending up the refactoring in Escher (already finished the core java pkgs) which lend me changing almost all classes in XPeer @ GNU Classpath, I’m waiting right now to submit this patch and some review of my mentor (Mario Torre) so I can make it a best refactoring.
So far:

  • Reintegrated Escher to XPeer @ GNU Classpath (First task)
  • Refactored Escher (Almost finishing)
  • Next → Generate the protocol code in a description way (Mario Torre gave the huge cool idea in generating on @nnotations :D)

One of the things that I changed in XPeer too was the lazy connection. IMHO there is no need to wait for someone to getDisplay() to make all the overhead of connecting to the Xserver. Since usually after the instantiation of the Xtoolkit class there will be use it I did the start right ahead. This change made *somehow* the start of the gui way faster. Am I missing the reason behind lazy connection?

Written by marcosroriz

July 3, 2010 at 6:57 pm

GNU Classpath/Escher and GSoC

with one comment

Hello everyone,

First of all, most of my posts will now be written on English. After all, the main reason for this change is to reach a higher number of users, as English is considered the universal language these days. The other reason is that I’m currently participating on Google Summer of Code for the GNU Classpath project. I’ll post here my progress on the program, including achievements, solutions to problems and future ideas. So to start off, I’m going to present you what is and what I’m doing for GNU Classpath.

GNU Classpath is a free software implementation of the Java standard library. Ok, what does that means? It’s a implementation of the standard Java API, things like Swing, Socket, Math, FileOutputStream, RMI and so on. It’s not a Java Runtime, i.e., it’s doesn’t do memory management, security, etc. The Java Runtime uses these class library to run the application. A full JVM according to Sun/Oracle standards is the sum of the class library and these runtime algorithms. Since the JVM is majority written in Java (classlib) the runtime implements very low-level things in C, like garbage collection.

Now a brief history of GNU Classpath. In the old days there were a bunch of FOSS projects that had a implementation of the runtime and the standard class library. Since each project implemented the same classes over and over, this turned out to become a incomplete and redundant implementation of the standard class library. So they united their efforts to produce ‘one’ class library, which is GNU Classpath. And they all implemented their runtime algorithms to manipulate this library. Cacao, Jikes, JamVM, Jamaica, IKVM, all this and others free JVM’s are used with GNU Classpath.

GNU Classpath Logo

GNU Classpath Logo

“Revive and Restructure the Escher project”. This is my GsoC task/proposal title. So what is this Escher? What’s the relationship with GNU Classpath? Escher is basically a client for the X Window System (X11) written entirely in Java. It was started and developed by Mario Torre (my mentor), Roman Kennke and Stephen Tse, they are all nice guys. Back to the story, inside GNU Classpath we have various graphics peers, including GTK, Qt and XPeer (which uses Escher). They all send requests to a X Server, when they are demanded to draw something, such as a Box or a Font. The Gtk is the default peer, Qt and XPeer is also dead. The thing here is to revive XPeer which basically means reviving Escher also, since both projects are intimately related. But why XPeer, what does it have that the other peers don’t? It’s because XPeer communicates directly with a X Server standalone. This is useful specially on a embedded scenario. These devices usually, almost all ways, doesn’t have a Gtk/Qt-Peer. So I’ll be doing a synchronization with the development of GNU Classpath, refactoring XPeer and Escher with design patterns and also start decoupling Escher for other back-ends, such as DirectFB. The coolest part is that GNU Classpath is on various architectures ranging from ARM to SPARC so we can manipulate graphics on all these architectures.

I’m very anxious/excited with GSoC. My mentor (Mario Torre) is really cool and he is very patient on teaching (he the most patient/kind FOSS developer ever!). He’s also the most badass developer that I’ve seen :D. The other guys from the channel are all kind/patient too. They are all awesome! I’m really excited with GNU Classpath/Escher with these guys! Tomorrow I’ll post more of what I’ve already done (this is the first week of coding), including the patches for synchronization, some refactoring and the repository that I’m using. From now on I’ll post here my progress :).

Written by marcosroriz

May 31, 2010 at 1:26 am

ClassLoader desmitificado.

with 3 comments

Até recentemente não dava muita importância no funcionamento da estrutura interna da plataforma Java até quando tive problemas que o Google não conhece. Para resolver meus problemas tive que mergulhar a fundo no interior da JVM. E apesar de ter vários materiais na rede é complicado compreender o linguajar e o funcionamento interno da mesma. Para começar entender o funcionamento do seu programa dentro da Máquina Virtual Java (Java Virtual Machine – JVM) é necessário compreender o coração da JVM  o ClassLoader (CL). De maneira simples, um CL é uma estrutura que tem como responsabilidade o carregamento dos seus bytecodes (.class). Cada ClassLoader contém o que ela pode carregar no seu classpath específico, isso é, o endereço (diretórios) das classes. Um classpath pode conter vários diretórios, sendo assim o CL irá procurar a classe no primeiro diretório especificado, se não achar irá pro segundo, assim suscetivamente até acabar a lista de diretórios do classpath. Porém o mais importante é entender como o CL carrega as suas classes e como ele é organizado internamente.

Antes de mais nada é necessário explicar que um tipo (classe) em java é identificado pelo seu nome e seu CL. Ou seja um objeto da classe Folha de CL 0x2bbd86 é diferente de um objeto da classe Folha de CL 0x813b2 pois apesar de serem da mesma classe esses possuem CL diferentes. O java faz isso para garantir a consistência de objetos internamente na JVM. Pois caso contrário poderia ocorrer um conflito entre um objeto Folha que representa uma árvore e sua atribuição a um objeto Folha que representa uma folha de pagamento. Ou seja, objetos originados de uma classe de mesmo nome pode não possuir estruturas idênticas.

Também é importante entender o processo chave de carregamento de classe, a delegação. Um ClassLoader possui ClassLoader pais e sempre irá fazer o seguinte:

  • A Classe sempre irá pedir a ClassLoader que o carregou para carregar suas dependências;
  • ClassLoader sempre irá delegar o carregamento da classe ao seu pai, para verificar se o mesmo quer carrregar a classe antes.

Agora iremos explicar a hierarquia dos ClassLoaders. Quando a JVM inicia ela não possui nenhuma classe carregada. A JVM usa o mecanismo de carregamento de classes conhecido como lazyness, preguiçoso, a JVM vai carregando as classes conforme é necessário. Porém existe um problema, o código que carrega uma classe é o ClassLoader que em si é uma classe em Java, se a JVM não possui nenhuma classe carregada como é que ela vai carregar as outras classes pois conforme a especificação Java uma classe só é carregada quando todas as suas dependências forem carregadas. Conforme novamente a especificação Java, ClassLoader herda de Object que em si deve ser carregado por uma ClassLoader o que leva a um dead-lock. A solução para isso é ter um ClassLoader que de fato não é escrito em Java e sim em código nativo. Esse CL nativo irá carregar as classes ClassLoader, AppClassLoader e ExtClassLoader. A árvore de CL é a hierarquia formada pelo agrupamento dos mesmos. Por padrão temos a seguinte hierarquia:

Hierarquia de ClassLoaders

O BootStrap é o CL nativo executado pela JVM o seu classpath encontra as classes do sistema, principalmente o runtime do Java. O ExtCL (Extension ClassLoader) tem como seu classpath frameworks ou aplicativos específicos do usuário, caso queira que esses sejam visíveis em toda a VM. O pai do ExtCL é o BootStrap. E por fim o AppClassLoader que é o CL que irá carregar sua aplicação e seu classpath é o especificado no manifest do jar ou o passado na linha de comando, e o pai desse é o ExtCL.

Faremos uma aplicação para demonstrar os conceitos vistos:

public class Info {
	public static void main(String args[]) {
		System.out.println("Boot class path: " + System.getProperty("sun.boot.class.path"));
		System.out.println("Extension class path: " + System.getProperty("java.ext.dirs"));
		System.out.println("AppClassPath: " + System.getProperty("java.class.path"));

		Info i = new Info();
		System.out.println("\nBoot CL: " + java.lang.Object.class.getClassLoader());
		System.out.println("App ClassLoader: " + i.getClass().getClassLoader());
	}
}

Resultado obtido:

[marcos@hades AUR]$ java Info
Boot class path: /opt/java/jre/lib/resources.jar:/opt/java/jre/lib/rt.jar:/opt/java/jre/lib/sunrsasign.jar:/opt/java/jre/lib/jsse.jar:/opt/java/jre/lib/jce.jar:/opt/java/jre/lib/charsets.jar:/opt/java/jre/classes
Extension class path: /opt/java/jre/lib/ext:/usr/java/packages/lib/ext
AppClassPath: .

Boot CL: null
App ClassLoader: sun.misc.Launcher$AppClassLoader@19134f4

Desse resultado podemos claramente ver o que foi explicado, o classpath do BootStrap é o “SDK” do Java, o do ExtClassLoader é o diretório de extensões e o da AppClassLoader é o passado no argumento na cli, caso não tenha sido passado ele assume que é o diretório local: ., ou lido do manifest do jar. E também vemos que quem carregou nossa classe principal foi o AppClassLoader. Também vemos que o bootstrap CL é representado por null.

Bem você já deve ter adivinhado por agora que somente esses três CL são pré-definidos sendo assim nós podemos adicionar e alterar classloaders nessa árvore. Isso garante flexibilidade e isolamento de código, algo muito utilizado em Servidores de Aplicação como o JBoss e Glassfish. O servidor vai isolar cada requisição criando classloader de modo que uma requisição não seja visível na “árvore” a outra, isso garante uma robustez e segurança muito grande a plataforma.

Outro grande exemplo da manipulação de classloaders é o escopo estático de uma variável. Uma variável tem seu escopo estático, isso é, visibilidade, do CL  que foi carregado pra baixo. Vejamos um exemplo abaixo:

import java.io.*;
import java.net.*;
public class EscopoEstatico {
	public static int instanceCount = 0;
	public EscopoEstatico() {
		System.out.println("Valor da instancia:" + ++instanceCount);
	}

	public static void main (String args[]) throws Exception {
		new EscopoEstatico();
		// Vamos criar um Cl novo e colocalo abaixo do bootstrap
		// Consequentemente a variavel static vai ser diferente lá
		// do que a especificada.
		URL urlArray = {new File(System.getProperty("user.dir")).toURL() };
		URLClassLoader cl = new URLClassLoader(urlArray, null);
		cl.loadClass("EscopoEstatico").newInstance();
	}
}

Resultado:

[marcos@hades AUR]$ java EscopoEstatico
Valor da instancia:1
Valor da instancia:1

O que fizemos pode ser visualizado na imagem abaixo:
O problema é que a variável estática não está definida no caminho definido pelo o outro CL, então é considerado um novo “escopo”.

Então um dos problemas que pode surgir é, dado que eu carrego uma requisição em classloaders diferente e de modo que os mesmos não tenham nenhum CL em Comum, todos sejam filhos de null como garantir a visibilidade dó código ao longo da JVM? Bem o que sabemos é que todos diretamente ou indiretamente tem um CL em comum, o CL bootstrap (null). Porém esse CL só carrega os runtimes da plataforma Java, por padrão. Poucos sabem que podemos editar, adicionar, sobrescrever o classpath do BootStrap. Você pode até mesmo sobrescrever a implementação de uma classe que não gosta do JDK, como a implementação da pilha, etc. Concluindo, a ideia é estender os jars visíveis a este adicionando os arquivos que você queria que seja visível na JVM inteira. Isso é feito utilizando as opções X (extended) da JVM.

[marcos@hades AUR]$ java -X
    -Xmixed           mixed mode execution (default)
    -Xint             interpreted mode execution only
    -Xbootclasspath:<directories and zip/jar files separated by :>
                      set search path for bootstrap classes and resources
    -Xbootclasspath/a:<directories and zip/jar files separated by :>
                      append to end of bootstrap class path
    -Xbootclasspath/p:<directories and zip/jar files separated by :>
.......

Como disse anteriormente você pode sobrescrever (-Xbootclasspath) ou adicionar no começo (/p de prefix) ou no fim (/a de append) jars ao classpath do Bootstrap. Você pode até mesmo sobrescrever classes do JDK. Vejamos um exemplo abaixo:

Copie o arquivo Integer.java do source do jdk (java/lang) e modifique seu construtor
Arquivo Integer.java:

public class Integer {
...
    public Integer(int value) {
		System.out.println("Vou dividir seu int por 2, pq sou mau =P");
		System.out.println("VALOR ANTES: " + value + " VALOR DEPOIS " + value/2 + "\n");
		this.value = value / 2;
    }
....
}

Crie um diretório temporário, como ~/temp e também crie ~/temp/java/lang. Note que ~ representa o diretório home do usuário.
Compile o arquivo Integer.java e copie o seus .class’s para o seguinte diretório, ~/temp/java/lang.
Agora vamos fazer um simples teste.
Arquivo Teste.java:

public class Teste {
	public static void main(String args[]) {
		System.out.println(System.getProperty("sun.boot.class.path"));
		new Integer(33);
	}
}

Compile e coloque esse arquivo no diretório ~/temp.
Agora execute a seguinte linha de comando:

[marcos@hades AUR]$ java -Xbootclasspath/p:. Teste
Vou dividir seu int por 2, pq sou mau =P
VALOR ANTES: 1 VALOR DEPOIS 0

Vou dividir seu int por 2, pq sou mau =P
VALOR ANTES: 2 VALOR DEPOIS 1

Vou dividir seu int por 2, pq sou mau =P
VALOR ANTES: 15 VALOR DEPOIS 7

.:/opt/java/jre/lib/resources.jar:/opt/java/jre/lib/rt.jar:/opt/java/jre/lib/sunrsasign.jar:/opt/java/jre/lib/jsse.jar:/opt/java/jre/lib/jce.jar:/opt/java/jre/lib/charsets.jar:/opt/java/jre/classes
Vou dividir seu int por 2, pq sou mau =P
VALOR ANTES: 33 VALOR DEPOIS 16

Vamos chamar agora sem modificar o classpath do bootstrap:

[marcos@hades AUR]$ java Teste
/opt/java/jre/lib/resources.jar:/opt/java/jre/lib/rt.jar:/opt/java/jre/lib/sunrsasign.jar:/opt/java/jre/lib/jsse.jar:/opt/java/jre/lib/jce.jar:/opt/java/jre/lib/charsets.jar:/opt/java/jre/classes

A própria JVM quando inicia executa algumas chamadas criando novos Integers, como podemos ver. Porém o grande resultado é que vemos que o diretório atual, representado por ., foi pré-fixado na classpath do BootStrap e não foi chamado o Integer normal do JDK. Isso garante uma flexibilidade enorme, pois podemos facilmente alterar qualquer implementação não desejada do JDK. Alguns hackers modificavam versões da classe System pois o método getEnv de pegar o PATH do usuário foi depreciado antigamente e não era possível chama-lo até recentemente (acho que adicionaram denovo no jdk 1.5-1.6). Porém a ideia principal é que podemos facilmente garantir uma classe escopo global na JVM colocando seu jar ou .class na lista de classpath do BootStrap.

No próximo tópico irei postar algumas modificações, manipulações e resultados de brincar com os classloaders.

Referências:
[1] Java Geek, Using the BootClasspath – http://www.javageeks.com/~tneward
[2] Inside the Java Virtual Machine – Bill Vernes – The McGraw-Hill Companies (1997)
[3] Inside Java™ 2 Platform Security: Architecture, API Design, and Implementation, Second Edition By Li Gong, Gary Ellison, Mary Dageforde

Written by marcosroriz

December 16, 2009 at 8:00 pm

Posted in Ciência da Computação, Java

Tagged with ,

Projeto GingaCDN

leave a comment »

Vou falar um pouco sobre o projeto de pesquisa no qual estou participando, o GingaCDN. “O Ginga Code Development Network ou simplesmente GingaCDN é uma rede de desenvolvedores de componentes e ferramentas para o middleware brasileiro Ginga.” Tá mais o que é esse Ginga? O Ginga é o middleware (uma ‘camada’ em cima do SO utilizada para as aplicações se comunicarem) que gerenciará a interatividade da Tv Brasileira. O Ginga vai ser instalado nos set-top-box (o conversor digital, ex: ‘a caixinha da NET’) das TV Digitais. O Ginga então irá fornecer esse ambiente ‘interativo’ para as aplicações. Ainda estou me familiarizando com o Ginga, então qualquer desvio aponte 🙂

As aplicações que podem ser executadas sobre o Ginga são divididas em duas categorias: procedurais e declarativas. Lembra de Linguagem de Programação? Existiam as linguagens procedurais, aquelas que realizam as instruções a serem executadas, como Java, C, C++. E também existem as linguagens declarativas, aquelas que apenas descrevem as instruções a serem executadas e não como faze-lá, como SQL, Prolog, XML.

O Ginga suporta ambos paradigmas de programação. Do lado procedural temos Java e do lado declarativo temos NCL (parecido com XML). A parte procedural é chamada Ginga-J e a declarativa é chamada Ginga-NCL. Além disso temos o GingaCC (Ginga Common Core). No qual as duas plataformas se comunicam. O GingaCC é feito em C, e nele é que se encontra as aplicações nativas do set-top-box e as rotinas que permitem a interatividade.

De maneira geral temos:

Ginga

Desenho abstrato do middleware Ginga

Dentro da pesquisa estão envolvidos várias universidade, daí o nome GingaCDN (Ginga Core Development Network) dentre elas várias universidades federais (UFPB, UFRGS, UFPEL, mais umas cinco…) e algumas particulares (PUC-RIO e PUC-MINAS). Cada universidade está responsável por algum(ns) componente(s) do Ginga. Na UFG estamos responsáveis pelo componente de comunicação entre aplicações do lado Ginga-J e gerenciador de aplicações.

As aplicações precisam se comunicar… e aí que entra o componente da UFG. Uma aplicação Ginga-J precisa se comunicar com outra, e além disso precisa comunicar com aplicações Ginga-NCL e aplicações nativas, GingaCC. Já viu a bagunça? Teremos que usar extensivamente JNI (Java Native Interface) para fazer as ‘traduções’ entre linguagens. Também usaremos IXC (InterXletCommunication), comunicação entre Xlets, que tratam de como as aplicações (no caso Xlets) irão conversar uma com as outras. Isso envolve comunicação remota de objetos, registros de objetos, stubs, entre outras coisas. É é isso que estamos trabalhando no momento…

Estou muito animado com a pesquisa, principalmente de se tratar de algo novo e interessante. Esse semestre irei fazer Redes 2 e Sistemas Distribuídos o que me dará uma boa base teórica para sustentar a pesquisa. E esqueci de falar que isso me renderá meu PFC? Essa pesquisa vai ser tudo de bom.

Written by marcosroriz

July 22, 2009 at 11:24 pm