Serei o único a olhar para o GC como uma mera personificação de um comportamento nativo da utilização da RAM?
Por mais explicações que leia/oiça acerca do mítico, defeituoso, GC continuo a não vé-lo como uma sub-rotina, aplicação, mecanismo ou qquer outra "entidade" própria. Para o mim o mais simples e olhar para a memoria tal e qual como ela funciona. Espaço virtual onde se armazena informação de forma "aleatória", isto significa que a informação la encontrada só se encontra "protegida" e disponível enquanto existir pelo menos 1 apontador para o local onde se encontra. Uma vez perdidos todos os apontadores para um mesmo espaço de memoria, esse espaço passa a estar disponível para armazenar nova informação. Isto significa que a informação em si nunca é apagada, apenas rescrita por cima, uma e outra vez sempre que deixa de ter apontadores. Ficar sem memoria não se trata do facto da memoria em si ter informação escrita em todos os seus blocos, isto é a norma após alguns segundos depois de ligar o PC e arrancar o SO, na realidade o que se passa e que sempre que é feito um pedido a RAM para armazenar nova informação é excluindo todos os blocos para onde ainda existem apontadores. O suposto GC do flash player tem exactamente este comportamento o que me leva a concluir que não existe qqer GC propriamente dito. Na melhor das hipóteses cada vez que guardamos um valor em memoria via AS é gerado um apontador "global" e armazenado numa lista e caberia ao tal GC limpar este apontador sempre que internamente todos os outros apontadores fossem removidos, mas a primeira vista não vejo qqer vantagem num sistema destes. Ainda assim independentemente de existir ou não um GC defeituoso é sempre bom entender que mesmo com um CG a funcionar na perfeição a memoria continuará sempre a funcionar da mesma forma e como tal teremos sempre de ter o máximo cuidado em gerir os recursos que usamos nas nossas aplicações quando a performance e consumo de recursos são uma prioridade. Lembrem-se que só pq parece que, ou se tem a certeza de, ter limpo todos os apontadores não significa necessariamente que o tenhamos feito, antes de se acusar um GC defeituoso. A dupla chamada ao localConnection mais depressa me soa um bug que de alguma forma limpa apontadores globais, e provavelmente faz outras coisas que não queremos que faça, do que me convença que dispara um tal GC por engano... Carol wrote: > As questões sobre o garbage collector (GC) têm vindo a assombrar-me > desde o início da minha curta experiência com Flex. Após a leitura de > inúmeros artigos (ver links abaixo) e um contacto directo com um > developer da Adobe, concluí que o GC actual tem alguns bugs que > impedem uma libertação total da memória para o sistema operativo. O > actual GC foi criado ainda na altura em que as aplicações flash eram > ainda programas que seriam utilizados durante um curto período de > tempo e num browser. Deste modo, passado um bocado acabaríamos por > navegar para fora da página da aplicação ou fecharíamos o browser, > libertando assim a memória. Acontece que agora, e cada vez mais, temos > muitas aplicações flash/flex/air que são supostas ficar em execução > durante longos períodos de tempo e é agora que nos apercebemos > realmente da falta que nos faria um GC mais robusto. > > Muito resumidamente, o GC funciona da seguinte maneira: > - Apenas os objectos que não tenham qualquer referência é que poderão > ser libertados. Isto significa que mesmo que tenhamos colocado um > objecto a null, se este tiver, por exemplo, um listener pendurado (que > não tenha sido removido) o GC não vai apagar esse objecto. Daí a > importância de removermos todas as referências a um objecto quando > queremos que ele seja apagado. > - O GC só irá libertar memória numa altura indeterminada. Ou seja, > todos os objectos que tenhamos "apagado" (removido as referências) só > vão ser realmente apagados quando o GC passar e, infelizmente, não > sabemos quando é que isso acontece exactamente. Nota-se que nas > alturas em que é necessário criar novos objectos o GC parece passar > mas o algoritmo é muito incerto. > Existem vários artigos que mostram um "truque" para obrigar o GC a > passar (fazendo duas chamadas seguidas a uma localConnection). Este > truque pode ser usado quando ainda estamos em fase de desenvolvimento > para detectar fugas de memória mas nunca deve usado em versões release > do programa. > > Pela conversa que tive com o developer da adobe o GC será melhorado > numa futura versão do AIR (talvez já na próxima, esperemos). Por > enquanto a única coisa que podemos fazer é continuar a seguir as boas > práticas de programação (libertando todos os objectos quando já não > precisamos deles, parando todos os sons, videos, timers, removendo > todos os listeners, etc) e esperar que tudo funcione bem. > > Para quem esteja interessado neste assunto aconselho a leitura dos > seguintes artigos: > http://www.gskinner.com/blog/archives/2006/06/as3_resource_ma.html > http://www.gskinner.com/blog/archives/2006/07/as3_resource_ma_1.html > http://www.gskinner.com/blog/archives/2006/08/as3_resource_ma_2.html > http://www.gskinner.com/blog/archives/2006/09/garbage_collect.html > http://gskinner.com/talks/resource-management/ > http://www.adobe.com/devnet/flashplayer/articles/garbage_collection.html# > http://blogs.adobe.com/aharui/2007/03/garbage_collection_and_memory.html > > Boas libertações de memória ;) > > CT > > On 15 Maio, 17:18, Miguel Vaz <[email protected]> wrote: > >> Boa tarde, >> >> Tenho umas questões sobre bons procedimentos nos seguintes aspectos: >> >> - Garbage collector - Pelo que fui lendo sobre este estranho personagem, o >> garbage collector funciona sobre itens (componentes, etc) que não estejam >> ligados a nenhum processo de..bem, processamento. Situações como a da >> existência de um modelo poderão afectar esta situação? Ou seja, imaginem um >> componente criado dinamicamente, com ligações a variáveis de modelo, como é >> suposto acontecer, a remoção desse componente poderá entrar para a lista de >> uma posterior garbage collection? Tenho dúvida visto que, apesar do >> componente ser removido, fica a existir uma ligação intrínseca entre este e >> as variáveis do modelo? É uma ligação efectiva que poderá impedir a garbage >> collection? >> >> - Num ambiente MVC existindo um componente/popup A sempre presente, que cria >> outros componentes/popups (B, C...), poderá ser considerado mau procedimento >> se, de um desses componentes (B,C..), eu fizer uma chamada directa para o >> componente A sempre presente (criado inicialmente e nunca mais removido, >> mantendo uma var no modelo com a sua referÊncia para poder endereçar de >> outros lados)? Fico com dúvida por não se tratar propriamente de andar a >> navegar em referências dinâmicas, mas sim em endereçar directamente algo >> estático (uma função public no componente A) e sempre presente. Isto >> contraposto a gerar um evento de um desses componentes secundários que será >> apanhado pelo tal componente estático, e então devidamente processado. >> >> Perdoem o email longo, mas são questões que me perseguem (solvo seja). >> >> MV >> > > > > > --~--~---------~--~----~------------~-------~--~----~ Recebeu esta mensagem porque está inscrito em Grupo "Mailing List da Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" do Grupos Google. Para enviar mensagens para este grupo, envie um email para [email protected] Para anular a inscrição neste grupo, envie um email para [email protected] Para mais opções, visite este grupo em http://groups.google.com/group/riapt?hl=pt-PT -~----------~----~----~----~------~----~------~--~---
