Geração de código dos monitores do java

Hum, isso é coisa para o Osvaldo Doederlein. Nem vou tentar olhar no fonte do JDK que não vou achar onde é que isso é implementado em C - ou melhor, como é que o HotSpot faz isso.

Fabrício Cozer Martins:

Olá,
alguém sabe ou tem alguma fonte de estudo sobre como o compilador java gera os códigos que lidam com o mecanismo de monitores ?

Você se refere ao javac, gcj ou ecj? Eles simplemente geram instruções monitor enter e monitor exit no bytecode dos métodos. Os métodos wait, notify e notifyAll não recebem tratamento especial.

Hum, estava pensando no que o HotSpot fazia com esses bytecodes monitorenter e monitorexit. Acho que mirei no problema errado.

hun … blza o monitorenter e o monitorexit ainda seriam níveis mais altos, queria saber de fato como o javac, ou outro, traduz isso em semáforos ? Queria ver se daria pra ter alguma visão do código é feito pra isso, ou se não, quem ficaria responsável pra tratar isso, a jvm ?

Conforme o Louds disse, o compilador gera apenas os bytecodes “monitorenter” e “monitorexit”.
Esses bytecodes são interpretados e/ou compilados pela JVM, e ela está à vontade para gerar locks, spin locks, usar primitivas de sincronização do sistema operacional, o que for necessário para que isso funcione. Só que os detalhes exatos (para o Windows, por exemplo) eu não conheço, preciso consultar alguma referência - ou ver o fonte do JDK
Ela pode fazer otimizações à vontade com eles, por exemplo, pode simplesmente não criar um lock se isso for provado necessário. Mas se um lock é gerado usando-se WaitforSingleObject ou outra API eu não tenho a menor idéia.

Nada como dar uma olhadinha no fonte - existe um fonte chamado hotspot\src\cpu\i486\vm\c1_MacroAssembler_i486.cpp (baixe os fontes do JDK completos) que contém a descrição do que o HotSpot gera. Não é muito trivial…

As JVMs modernas usam o já comum esquema de thinlocks com fat lock upgrade.

Isso significa que para o caso comum, sem contenção, basta uma operação atomic-test-and-set para adquirir o monitor. Caso outra thread possua o lock para esse objeto então ocorre um upgrade e uma primitiva de lock do SO é associada a esse objeto.

Se você quiser uma descrição bem detalhada disso sugiro ler os papers do pessoal da Sun sobre o assunto (procura no citeseer por thinlocks) ou então leia a tese de doutorado do Etienne Gagnon sobre a SableVM.

No caso do Pentium a JVM gera a instrução CMPXCHG para o “atomic-test-and-set”, e um jump condicional para um label que ela chama de “slow_case” para essa chamada ao SO. Se a máquina for multiprocessada ela também tem de fazer a coerência dos caches.

Obrigado pela referência, Louds.

valeu mestres! vou procurar sobre isso que vocês mencionaram aqui!

thingol:

No caso do Pentium a JVM gera a instrução CMPXCHG para o “atomic-test-and-set”, e um jump condicional para um label que ela chama de “slow_case” para essa chamada ao SO. Se a máquina for multiprocessada ela também tem de fazer a coerência dos caches.

Obrigado pela referência, Louds.

Sim, no caso do P4 e Athlon64 um read/write barrier são usados em volta dessas operações.