Resposta simplista:
Seu objeto fica desreferenciado assim que chegar na última linha do while, pois a variável sai de escopo, portanto o garbage collector pode remove-lo, desalocando a memória ocupada por ele. Em seguida, o while reinicia e um novo objeto é criado. Aloca-se novamente memória e roda-se o contrutor sobre ela.
Resposta detalhada:
Todo objeto é criado na região de vida curta do garbage collector. Apenas objetos que sobrevivam a muito tempo de execução são movidos para a área de vida longa.
Caso um objeto de vida curta seja excluído, não há liberação física de memória. Sua área fica disponível, para que um outro objeto de vida curta a habite. Como no seu código, um novo objeto de mesmo tamanho irá ser criado na sequência, essa mesma área será reaproveitada e, ao invés de reservar novamente memória, o garbage collector só irá rodar o construtor para limpar aquele endereço previamente reservado.
Dessa forma, seu programa terá um custo de alocação e desalocação próximo de 0 para esse tipo de situação (afinal, efetivamente o java só fica usando a mesma área de memória, e não criando e recriando objetos). É por isso que um programa que tenha uma estrutura como essa, que cria e destrói um mesmo objeto num loop, tem uma excelente performance em java, e uma péssima performance em C++ (a menos, claro, que vc implemente sua própria política de alocação de memória).
Vale lembrar que alocar e desalocar memória é um custo altíssimo, e por isso esse tipo de estratégia é tão eficiente. Os projetistas da Sun, ao pesquisar sobre o comportamento dos objetos, perceberam que era muitíssimo comum criações e destruições dessa forma (mais comum até do que a existência de objetos de vida longa), e isso motivou essa otimização no gc.
A resposta simplista ainda é correta pois, conceitualmente, toda essa ginástica é apenas uma inteligente otimização. Na prática, para nós programadores mortais, o que o java parece estar fazendo é simplesmente alocar e reservar memória novamente.
Mais informações: