BR112015030302B1

BR112015030302B1 - Método e sistema para depuração de código nativo através da transição da execução em modo nativo para a execução em modo interpretado, e meio de armazenamento legível por computador

Info

Publication number: BR112015030302B1
Application number: BR112015030302-1A
Authority: BR
Inventors: Mikhail Koltachev; Nikhil Khandelwal; Akrosh Gandhi
Original assignee: Microsoft Technology Licensing, Llc
Priority date: 2013-06-06
Filing date: 2014-06-03
Publication date: 2022-04-19
Also published as: KR102171050B1; WO2014197406A1; JP6573875B2; RU2668973C2; MX2015016740A; AU2014275115B2; CN105683924A; US10127138B2; JP2016529582A; KR20160018522A; CA2913730A1; RU2015152048A; EP3005121B1; AU2014275115B9; AU2014275115A1; EP3005121A1; CN105683924B; RU2015152048A3; US20140366007A1; BR112015030302A2

Abstract

SISTEMA, MÉTODO E DISPOSITIVO PARA DEPURAÇÃO DE CÓDIGO NATIVO ATRAVÉS DA TRANSIÇÃO DA EXECUÇÃO EM MODO NATIVO PARA A EXECUÇÃO EM MODO INTERPRETADO. A presente invenção refere-se a um depurador em modo duplo que pode depurar o código nativo ou código interpretado. A transição entre os modos pode ser acionada pelas condições de esgotamento definidas. Um programa pode ser depurado fixando-se um depurador e compilando-se o programa no código nativo sob o depurador. Em pontos definidos no programa, a depuração pode transitar do modo nativo para o modo interpretado. A depuração do código nativo pode parar, o estado atual pode ser capturado, e um intérprete pode ser exemplificado. Uma pilha de intérprete pode ser criada e pode ser populada com o estado atual capturado. As operações de depuração que envolvem o controle de execução: pausar a execução, continuar a execução, entrar, sair ou passar por uma seção do código e, assim por diante, podem ocorrer no modo interpretado, que é tipicamente mais fácil para a implementação. As operações de depuração que envolvem a inspeção e a modificação de variáveis podem ocorrer no modo nativo.

Description

ANTECEDENTES

[001] Um compilador pode produzir o código executável compi lando-se o código fonte no código que pode ser executado por um processador particular. Esse tipo de código específico a processador é referido como "código nativo", as instruções de máquina que podem ser executadas por um tipo particular de processador, mas não por qualquer tipo de processador. Outro tipo de compilador pode receber o código fonte e produzir um código intermediário ou código de byte de máquina virtual que não é específico a processador. O código intermediário é tipicamente recebido por um compilador de linguagem intermediária (por exemplo, um compilador just-in-time (JIT)), e compilado para o código nativo logo antes de o programa ser executado. O código intermediário não é específico à plataforma.

[002] Um intérprete lê o código fonte ou o código intermediário e executa a declaração de código através da declaração sem traduzir o código para código nativo. Tipicamente, a interpretação de código é mais lenta do que a execução do código nativo. A interpretação do código é tipicamente mais lenta do que a compilação JIT do código intermediário em código nativo e a execução do código nativo.

[003] A implementação de um depurador para código interpreta do é tipicamente menos complexa do que a implementação de um de- purador para código nativo. No entanto, o tempo de resposta é tipicamente mais rápido para um depurador para código nativo do que para um depurador para código interpretado. Um depurador tipicamente fornece a um usuário a habilidade de execução de controle de um pro- grama para entrar ou sair de uma função, passar por uma função, pausar e continuar a execução, inspecionar o valor atual de uma variável ou pilha local, e assim por diante.

SUMÁRIO

[004] Um depurador em modo duplo conforme descrito no pre sente documento pode depurar o código nativo que representa um programa. Em resposta à detecção de uma condição de esgotamento de depuração definida no programa que é depurado, o depurador pode parar a depuração do código nativo que representa o programa e pode transitar para depurar o código interpretado correspondente que representa o programa. No modo nativo, o depurador pode depurar o código nativo que representa o programa. As operações de depuração que fornecem inspeção e/ou modificação de valores atuais de variáveis de programa e/ou informações de pilha podem ser executadas em modo nativo. Na depuração em modo nativo, cada momento em que uma variável é salva em um registro (por exemplo, quando uma variável for definida no programa), o valor também pode ser salvo em um local de pilha para a função. As variáveis para uma função que é depurada podem ser armazenadas em uma área de local específico da pilha reservada para o programa que é depurado. A mesma área da pilha pode ser usada durante a compilação no código nativo para o derramamento (spilling) (isto é, onde há mais variáveis vivas do que o dispositivo de computação tem registros, as variáveis podem ser "derramadas" dos registros para a memória). Os locais de pilha podem ser usados pelo depurador para obter e alterar valores de variáveis.

[005] Em resposta à detecção de uma condição de esgotamento, a depuração do código nativo que representa o programa pode parar. O intérprete pode receber o código interpretado que representa o programa, o código interpretado recebido que corresponde ao código nativo que é depurado e pode continuar a depuração do código interpre- tado para o programa, em execução em modo interpretado. Por exemplo, as operações de depuração que controlam a execução do programa que é depurado podem ser executadas em modo interpretado. As operações de controle de execução podem ser implementadas através de interrupção assíncrona, escalonamento, ponto de interrupção e/ou interrupção em operações de execução. A depuração em modo de intérprete pode ser usada para depurar a função mais superior (a função cujos valores variáveis estão localizados no quadro mais superior da pilha) enquanto usa o modo nativo para depurar outras partes do programa.

[006] O depurador pode transitar da depuração em modo nativo para a depuração em modo interpretado em pontos de esgotamento definidos. Um mecanismo de esgotamento associado ao depurador pode receber uma gravação de esgotamento que compreende o estado atual do código nativo em execução sob o depurador. O mecanismo de esgotamento pode exemplificar uma instância de um intérprete, criar um quadro de pilha de intérprete para a instância do intérprete e pode preencher o quadro de pilha de intérprete criado para a instância do intérprete com valores da gravação de esgotamento. A depuração do programa pode continuar no código interpretado correspondente análogo para o programa. Os pontos de esgotamento de depuração são locais no programa nos quais a depuração em modo nativo pode transitar para a depuração em modo interpretado, contanto que determinadas condições de esgotamento sejam satisfeitas. Os pontos de esgotamento de depuração como no início de uma função, na borda traseira de um loop, quando uma função retornar, quando uma chamada para uma função do auxiliar ou biblioteca retornar, ou quando uma declaração de depurador for encontrada, podem ser definidos para o programa. Quando um ponto de esgotamento de depuração for encontrado em uma sessão de depuração, a situação de marcadores de depuração de tempo de funcionamento e de verificações de profundidade de pilha de quadros de pilha pode ser usada para determinar se as condições de esgotamento de depuração forem satisfeitas. Se as condições de esgotamento de depuração forem satisfeitas, o código que corresponde ao código nativo em execução sob o depura- dor pode ser enviado para a intérprete e a depuração pode prosseguir com o código interpretado correspondente.

[007] Este Sumário é fornecido para introduzir uma seleção de conceitos de uma forma simplificada que será ainda mais descrita abaixo na Descrição Detalhada. Este Sumário não se destina a identificar recursos chaves ou recursos essenciais da matéria reivindicada, nem se destina a ser usado para limitar o escopo da matéria reivindicada.

BREVE DESCRIÇÃO DOS DESENHOS

[008] Nos desenhos:

[009] A Figura 1a ilustra um exemplo de um sistema 100 que in clui um aplicativo de navegador que renderiza páginas dos documentos recebidos;

[0010] A Figura 1b ilustra um exemplo de um sistema 200 que compreende um mecanismo de tempo de funcionamento que pode transferir da execução de código compilado para a interpretação de código de acordo com os aspectos da matéria revelada no presente documento;

[0011] A Figura 1c ilustra um exemplo de um sistema 300 que compreende um mecanismo de tempo de funcionamento que pode transferir da execução de código compilado para a interpretação de código de acordo com os aspectos da matéria revelada no presente documento;

[0012] A Figura 1d ilustra um exemplo de um sistema 400 que po de depurar o código transitando-se do modo nativo para o modo inter- pretado de acordo com os aspectos da matéria revelada no presente documento;

[0013] A Figura 2 ilustra um exemplo de um método 250 que tran sita da depuração de código nativo para a depuração de código interpretado de acordo com os aspectos da matéria revelada no presente documento;

[0014] A Figura 3 é um diagrama de blocos de um exemplo de um ambiente de computação de acordo com os aspectos da matéria revelada no presente documento; e

[0015] A Figura 4 é um diagrama de blocos de um exemplo de um ambiente de desenvolvimento integrado (IDE) de acordo com os aspectos da matéria revelada no presente documento.

DESCRIÇÃO DETALHADA Visão geral

[0016] Um programa pode ser depurado compilando-se o mesmo para código nativo e depurando-se o código nativo. Em pontos definidos no programa, a depuração pode transitar do modo nativo para modo interpretado, e a depuração pode continuar com o código interpretado. As operações de depuração que envolvem o controle de execução: pausar a execução, continuar a execução, entrar, sair ou passar por uma seção do código e assim por diante, podem ocorrer no modo interpretado. As operações de depuração que envolvem a inspeção e a modificação de variáveis podem ocorrer no modo nativo. O depurador em modo duplo pode combinar a velocidade de depuração em modo nativo com a simplicidade de depuração em modo interpretado. Depuração de Código Nativo através da Transição da Execução em Modo Nativo para a Execução em Modo Interpretado

[0017] A Figura 1a ilustra um exemplo de um ambiente de nave gação de rede 100, de acordo com alguns aspectos da matéria revela- da no presente documento. Conforme mostrado na Figura 1a, o ambiente 100 pode incluir um ou mais dentre: um dispositivo de computação 102, um servidor 104, uma rede 106 e um aplicativo de navegador 108. O ambiente de navegação de rede 100 pode incluir outros componentes conhecidos na técnica.

[0018] O dispositivo de computação 102 pode ser qualquer tipo de dispositivo de computação estacionário ou móvel, que inclui um computador do tipo desktop (por exemplo, um computador pessoal, etc.), um computador móvel ou dispositivo de computação (por exemplo, um dispositivo Palm®, um dispositivo Blackberry® da RIM, um assistente pessoal digital (PDA), um computador do tipo laptop, um computador do tipo notebook, um computador do tipo tablet (por exemplo, um iPad™ da Apple), um netbook, etc.), um telefone móvel (por exemplo, um telefone celular, um telefone inteligente como um iPhone da Apple, um telefone Android™ do Google, um telefone Windows® da Microsoft, etc.), ou outro tipo de dispositivo móvel. O servidor 104 pode ser implementado em um ou mais sistemas de computador, inclusive um ou mais servidores, que podem ser qualquer tipo de dispositivo de computação descrito no presente documento ou, de outro modo, conhecido que tenha a capacidade de possibilitar a funcionalidade correspondente aqui descrita.

[0019] O dispositivo de computação 102 e o servidor 104 podem ser acoplados de modo comunicativo pela rede 106. A rede 106 pode incluir um ou mais enlaces de comunicação e/ou redes de comunicação, como uma PAN (rede de área pessoal), uma LAN (rede de área local), uma WAN (rede de área ampla), ou uma combinação de redes, como a Internet. O dispositivo de computação 102 e o servidor 104 podem ser acoplados de modo comunicativo à rede 106 com o uso de vários enlaces, inclusive enlaces com fio e/ou sem fio, como LAN sem fio de IEEE 802.11 (WLAN), enlaces sem fio, Interoperabilidade de Mundial para enlaces de Acesso por Micro-ondas (Wi-MAX), enlaces de rede celular, enlaces de rede de área pessoal sem fio (PAN) (por exemplo, enlaces de Bluetooth™), enlaces de Ethernet, enlaces de USB, etc.

[0020] O aplicativo de navegador 108 pode ser um programa que pode ser executado em dispositivo de computação 102. O aplicativo de navegador 108 pode possibilitar que os recursos de informações de rede sejam recuperados, apresentados, e percorridos. Um recurso de informações ou objeto podem ser recuperados pelo aplicativo de navegador 108 com o uso de um endereço de rede, como um identificador de recurso uniforme (URI). Os exemplos de recursos de informações incluem páginas da rede, imagens, vídeos e outras formas de conteúdo. Os hiperlinks que estão presentes nos recursos de informações possibilitam que os usuários naveguem facilmente seus navegadores para os recursos relacionados. Os exemplos de aplicativo de navegador 108 incluem, mas sem limitação, Internet Explorer®, de-senvolvido pela Microsoft Corp. de Redmond, Washington, Mozilla Firefox®, desenvolvido pela Mozilla Corp. de Mountain View, California, Safari®, desenvolvido pela Apple Inc. de Cupertino, Califórnia e Google® Chrome da Mountain View, Califórnia.

[0021] O aplicativo de navegador 108 pode recuperar um docu mento 112 a partir de um servidor 104 através da rede 106. O documento 112 pode ser um documento da rede que inclui código de uma linguagem de marcação, como linguagem de marcação de Hyper Text (HTML), HTML dinâmico (DHTML), HTML extensível (XHTML), linguagem de marcação extensível (XML), etc. O documento 112 pode incluir objetos de DOM (modelo de objeto de documento) 114 e um ou mais script(s) 116. Os objetos de DOM 114 podem incluir um ou mais objetos representados no documento 112 de acordo com a convenção de DOM, que é uma plataforma cruzada e convenção independente de linguagem para representar e interagir com os objetos. Os objetos de DOM 114 podem incluir objetos que estejam diretamente incluídos no documento 112, e/ou são referidos pelo documento 112 e separadamente recuperados a partir do servidor 104 ou outro servidor. O(s) Script(s) 116 incluem o código formatado de acordo com uma linguagem dinâmica (por exemplo, JavaScript, VBScript, AJAX, Python, Perl, etc.) que possibilita que alterações sejam feitas aos objetos de DOM 114, inclusive alterações com base nos fatores como entrada de usuário, condições ambientais (por exemplo, o momento do dia ou outras variáveis), etc. O código de script(s) 116 pode acessar e modificar ob-jetos de objetos de DOM 114 na saída sem retornar para o servidor 104.

[0022] O aplicativo de navegador 108 pode receber (por exemplo, carga) o documento 112. O aplicativo de navegador 108 pode incluir um mecanismo de navegador (por exemplo, um mecanismo de leiaute ou mecanismo de renderização) que formata as informações do documento 112 e exibe as informações formatadas. Por exemplo, conforme mostrado na Figura 1a, o aplicativo de navegador 108 pode gerar uma página 118 com base no documento 112 que é exibido por um visor 110 do dispositivo de computação 102. O aplicativo de navegador 108 pode ser configurado para executar um ou mais scripts 116 que são embutidos no documento 112, ou que são separados, mas associados ao documento 112.

[0023] A Figura 1b ilustra um diagrama de blocos de um sistema 200 de acordo com alguns aspectos da matéria revelada no presente documento. O sistema 200 pode incluir um ou mais computadores ou dispositivos de computação como dispositivo de computação 102, o que inclui um ou mais processadores como processador 143, etc. memória 145, um controlador de execução 309, um intérprete 311, um compilador como um compilador JIT (just-in-time) 313, armazenamen- to 315, um executor de código de máquina 317 e um mecanismo de esgotamento 337. O controlador de execução 309, intérprete 311, compilador como um compilador JIT 313, armazenamento 315, executor de código de máquina 317, e o mecanismo de esgotamento 337 pode ser implementado como um ou mais módulos de programa que, quando carregados na memória 145, fazem com que os um ou mais processadores 143, etc. realizem as ações atribuídas ao controlador de execução 309, intérprete 311, compilador como um compilador JIT 313, executor de código de máquina 317 e mecanismo de esgotamento 337, respectivamente. O sistema 200 pode incluir outros componentes conhecidos na técnica que não são mostrados.

[0024] O controlador de execução 309, intérprete 311 e/ou compi lador JIT 313 podem receber o código de byte gerado a partir do código fonte. O código fonte pode ser qualquer código fonte escrito em uma linguagem de programação, como, mas sem limitação, linguagens de script dinâmicas como, mas sem limitação. JavaScript, VBScript, Python, e assim por diante. O código fonte pode ser analisado e o código de byte pode ser gerado a partir do código fonte analisado. Com base no código de byte 325 e no perfil, o controlador de execução de heurística ou outras informações 309 possibilita que um dentre o intérprete 311 e o compilador JIT 313 opere um código de byte 325. O intérprete 311 pode ser configurado para interpretar o código de byte 325 quando possibilitado por um sinal de controle de intérprete recebido do controlador de execução 309. O compilador JIT 313 pode ser configurado para compilar o código de byte 325 quando possibilitado por um sinal de controle de compilador recebido do controlador de execução 309.

[0025] Quando o intérprete 311 for possibilitado por um sinal de controle de intérprete, o intérprete 311 pode interpretar e executar o código de byte 325. O intérprete 311 pode ser implementado como um intérprete de JavaScript, um intérprete de VBScript, um intérprete de Python ou como um intérprete para uma outra linguagem dinâmica ou linguagem de script dinâmica mencionada no presente documento ou de outro modo conhecida. Dessa maneira, o código fonte pode ser pelo menos parcialmente executado pela operação do intérprete 311. Semelhantemente, em resposta ao recebimento de um sinal de controle de compilador capacitador, o compilador JIT 313 pode compilar o código de byte 325. O compilador JIT 313 pode ser implementado como um compilador de JavaScript, um compilador de VBScript, um compilador de Python ou como um compilador para uma outra linguagem dinâmica ou linguagem de script dinâmica mencionada em outro lugar no presente documento ou de outro modo conhecida. O compilador JIT 313 é re-ferido como um compilador "just in time", devido ao fato de as porções de código de byte específicas poderem ser compiladas pelo compilador JIT 313 à medida que o código de byte compilado é necessário (por exemplo, será executado iminentemente), em vez de pré-compilar o código de byte 325 em sua totalidade antes da execução. O compilador JIT 313 pode gerar o código de byte compilado 333, que tem a forma de código ou instruções executáveis por máquina.

[0026] O compilador JIT 313 pode realizar as otimizações de códi go, com base em suposições conforme descrito acima. O compilador JIT 313 pode inserir um ou mais pontos de esgotamento predeterminados no código de byte compilado que o mesmo gera. Para cada ponto de esgotamento, uma tabela de esgotamento como a tabela de esgotamento 303, etc. pode ser criada, em que o local de variáveis, um local no código de byte 325 ou no código fonte que corresponde ao local de ponto de esgotamento e outras informações, podem ser gravadas. A tabela de esgotamento 303, etc. pode descrever onde encontrar variáveis na pilha ou no registro. O compilador JIT 313 pode gerar as uma ou mais tabelas de esgotamento e pode salvar as mesmas com o código de byte compilado otimizado (por exemplo, como código de máquina). A tabela de esgotamento pode ser otimizada evitando-se a extensão dos tempos de vida de variáveis desnecessariamente codificando-se as informações na tabela de esgotamento. Por exemplo, se for conhecido que o valor de variável x é a constante 10, no tempo de esgotamento, x=10 pode ser codificado na tabela de esgotamento para que o valor 10 não precisa estar na memória ou em um registro para ser retornado. Semelhantemente, quando mais de uma variável tiver o mesmo valor, (por exemplo, x = y;) no ponto de esgotamento o mesmo local pode ser usado na tabela de esgotamento para todos as variáveis que têm o mesmo valor se essas informações forem codificadas na tabela de esgotamento (por exemplo, o mesmo local na tabela de esgotamento pode ser usado para x e y). Essas técnicas podem tornar a alocação de registro mais eficiente. O código de byte compilado otimizado pode ser armazenado no armazenamento 315 como código de byte compilado 333 para o acesso durante a execução subsequente do programa pelo sistema 200.

[0027] Quando o código de byte compilado otimizado for executa do, o código de byte compilado otimizado 333 pode ser recebido pelo executor de código de máquina 317 (que pode ser um ou mais processadores como o processador 143, etc.). A execução do código de byte compilado pode ser associada a um quadro de compilador 341 na pilha 335. A suposição ou as suposições subjacentes em que as otimizações se basearam podem ser determinadas para serem válidas ou inválidas em cada ponto de esgotamento. Em resposta à determinação de que a(s) suposição(ões) são válidas, o código compilado otimizado pode continuar a ser executado. Em resposta à determinação de que a(s) suposição(ões) é(são) inválida(s), a execução do código compilado otimizado pode ser parada. A tabela de esgotamento para aquele ponto de esgotamento pode ser passada para o mecanismo de esgo- tamento 337. O mecanismo de esgotamento 337 pode restaurar o estado (por exemplo, valor) de variáveis necessárias pelo intérprete. O mecanismo de esgotamento pode criar um novo quadro (por exemplo, quadro de intérprete 339) para a pilha 335. Se uma variável necessária pelo intérprete tiver se tornado inativa, o mecanismo de esgotamento 337 pode retornar com uma variável alterando-se o estado da variável de inativo para ativo. O mecanismo de esgotamento 337 pode exemplificar uma instância do intérprete 311, passar para o intérprete o local no código de byte que corresponde ao ponto de esgotamento no código compilado otimizado e o quadro de intérprete recentemente criado que inclui os valores de todas as variáveis ativas restauradas. Por isso, o código fonte do qual o código de byte 325 foi gerado pode, então, ser parcialmente executado através da operação do compilador JIT 313 e do executor de código de máquina 317 e parcialmente executada pelo intérprete 311.

[0028] A Figura 1c ilustra outro exemplo de um sistema, o sistema 300 de acordo com os aspectos da matéria revelada no presente documento. Um sistema 300 pode incluir um dispositivo de computação como o dispositivo de computação 102 que compreende um ou mais processadores como o processador 142, etc., a memória 144 e um mecanismo de tempo de funcionamento que inclui um ou mais dentre os seguintes: uma interface de mecanismo 302, um analisador 304, um gerador de código de byte 306, um controlador de execução 308, um intérprete 310, um compilador como, mas sem limitação, um compilador JIT (just-in-time) 312, armazenamento 314, um executor de código de máquina 316, um mecanismo de esgotamento 336 e uma biblioteca de script 318. O sistema 300 pode incluir outros componentes conhecidos na técnica que não são mostrados.

[0029] Conforme mostrado na Figura 1c, a interface de mecanismo 302 pode receber o código fonte de script 208. A interface de meca- nismo 302 pode estar presente ou não presente. O analisador 304 pode ser configurado como uma interface para o mecanismo de tempo de funcionamento em vez de ter a interface de mecanismo 302 presente. Quando presente, a interface de mecanismo 302 pode ser uma interface de comunicação que fornece um ou mais métodos para fazer interface com um hospedeiro com o mecanismo de tempo de funcionamento da Figura 1c. De acordo com alguns aspectos da matéria revelada no presente documento, a interface de mecanismo 302 pode ser implantada de acordo com o IActiveScript desenvolvido pela Microsoft Corporation de Redmond, Washington. A interface de mecanismo 302 pode fornecer o código fonte 208 para o analisador 304.

[0030] O analisador 304 pode receber e analisar o código fonte 208. O analisador 304 pode realizar a geração de token ou análise léxica no código fonte 208, de modo que o código fonte 208 é formatado para símbolos ou tokens. O analisador 304 pode realizar a verificação de erro nos tokens para determinar se as expressões permissíveis são formadas, esses erros de sintaxe não estão presentes, etc. o analisador 304 pode emitir o código fonte analisado como código fonte analisado (não mostrado). O código fonte analisado pode ter qualquer forma adequada, o que inclui ser gerado pelo analisador 304 como código AST (árvore de sintaxe abstrata), o que inclui uma representação de árvore da estrutura sintática abstrata do código fonte 208, conforme seria conhecido pelas pessoas versadas na(s) técnica(s) relevante(s).

[0031] O gerador de código de byte 306 pode receber o código fonte analisado. O gerador de código de byte 306 pode ser configurado para converter o código fonte analisado em código de byte, o que inclui conjuntos de instruções configurados para a execução eficiente por um intérprete, assim como para a compilação adicional em código de máquina. O código de byte gerado pode representar o código fonte analisado como códigos numéricos e parâmetros opcionais correspon- dentes. O gerador de código de byte 306 pode emitir o código de byte gerado (não mostrado). O código de byte pode ter qualquer forma adequada, inclusive ser gerado pelo gerador de código de byte 306 na forma de p-código (código portátil), como seria conhecido pelas pessoas versadas na(s) técnica(s) relevante(s).

[0032] O controlador de execução 308, o intérprete 310 e o compi lador JIT 312 podem, cada um, receber o código de byte gerado. O intérprete 310 ou executor de código de máquina 316 pode incluir o gerador de perfil 204. O gerador de perfil 204 pode ser configurado para analisar o código de byte gerado para coletar as estatísticas e as informações adicionais em relação ao código fonte 208. O gerador de perfil 204 pode gerar informações de perfil 320, as quais podem incluir as informações coletadas e as quais podem ser armazenadas no armazenamento 314.

[0033] O controlador de execução 308 pode acessar informações de perfil 320, e pode ser acoplado de modo comunicativo ao intérprete 310 e ao compilador JIT 312. Com base no código de byte gerado e nas informações de perfil 320, o controlador de execução 308 pode possibilitar que um dentre o intérprete 310 e o compilador JIT 312 opere no código de byte gerado. O intérprete 310 pode ser configurado para interpretar o código de byte gerado quando possibilitado por um sinal de controle de intérprete recebido do controlador de execução 308. O compilador JIT 312 pode ser configurado para compilar o código de byte gerado quando possibilitado por um sinal de controle de compilador recebido do controlador de execução 308. Por exemplo, durante uma primeira execução do código fonte 208, as informações de perfil 320 podem não existir ainda. Em tal caso, o controlador de execução 308 pode possibilitar que o intérprete 310 interprete o código de byte gerado e gere informações de perfil 320. Durante uma execução subsequente de código fonte 208 (por exemplo, mais tarde, duran te a mesma primeira execução do código fonte 208 e/ou durante uma execução subsequente de código fonte 208), o controlador de execução 308 pode possibilitar que o intérprete 310 interprete posições de código fonte 208 e pode possibilitar que o compilador JIT 312 compile outras porções de código fonte 208, com base nas informações de perfil 320.

[0034] Quando o intérprete 310 for possibilitado pelo sinal de con trole de intérprete, o intérprete 310 pode interpretar e executar o código de byte gerado. O intérprete 310 pode ser implementado como um intérprete de JavaScript, um intérprete de VBScript, um intérprete de Python ou como um intérprete para uma outra linguagem dinâmica mencionada no presente documento ou de outro modo conhecida. Dessa maneira, o código fonte 208 pode ser pelo menos parcialmente executado pela operação do intérprete 310.

[0035] Quando o compilador JIT 312 for possibilitado por um sinal de controle de compilador, o compilador JIT 312 pode compilar código de byte gerado. O compilador JIT 312 pode ser implementado como um compilador de JavaScript, um compilador de VBScript, um compilador de Python ou como um compilador para uma outra linguagem dinâmica mencionada em outro lugar no presente documento ou de outro modo conhecida. O compilador JIT 312 é referido como um compilador "just in time", devido ao fato de as porções de código de byte específicas poderem ser compiladas pelo compilador JIT 312 à medida que o código de byte compilado é necessário (por exemplo, será executado iminentemente), em vez de pré-compilar o código de byte em sua totalidade antes da execução. O compilador JIT 312 pode gerar o código de byte compilado 332, que pode ter a forma de código ou instruções executáveis por máquina.

[0036] O compilador JIT 312 pode realizar as otimizações de códi go, com base em suposições, conforme descrito acima. O compilador JIT 312 pode inserir um ou mais pontos de esgotamento predeterminados no código de byte compilado que o mesmo gera. Para cada ponto de esgotamento, uma tabela de esgotamento como a tabela de esgotamento 303, etc. pode ser criada, em que o estado de variáveis pode ser gravado, um local no código de byte gerado que corresponde ao local de ponto de esgotamento. A tabela de esgotamento pode descrever onde encontrar variáveis na pilha ou no registro do código de máquina. O compilador JIT 312 pode gerar tabelas de esgotamento e pode salvar as mesmas com o código de byte compilado otimizado 332 (por exemplo, código de máquina). O código de byte compilado 332 otimizado pode ser armazenado no armazenamento 314 como código de byte compilado 332 para o acesso durante a execução subsequente do programa pelo sistema 300.

[0037] Quando o código de byte compilado otimizado for executa do, o código de byte compilado otimizado 332 pode ser recebido pelo executor de código de máquina 316 (que pode ser um ou mais processadores como o processador 142, etc.). A suposição ou as suposições subjacentes em que as otimizações se basearam podem ser verificadas para validade ou invalidade em cada ponto de esgotamento. Em resposta à determinação de que a(s) suposição(ões) são válidas, o código de byte compilado otimizado 332 pode continuar a ser executado. Em resposta à determinação de que a(s) suposição(ões) é(são) inválida(s), a execução do código compilado otimizado pode ser parada. A tabela de esgotamento para aquele ponto de esgotamento pode ser passada para o mecanismo de esgotamento 336. O mecanismo de esgotamento 336 pode restaurar o estado (por exemplo, valor) de variáveis necessárias pelo intérprete. Se uma variável necessária pelo intérprete tiver se tornado inativa, o mecanismo de esgotamento 336 pode retornar com uma variável alterando-se o estado da variável de inativo para ativo. O mecanismo de esgotamento 336 pode exemplifi- car uma instância do intérprete 310, passar para o intérprete o local no código de byte que corresponde ao ponto de esgotamento no código compilado otimizado, nas variáveis e seus locais. Por isso, o código fonte do qual o código de byte foi gerado pode, então, ser parcialmente executado através da operação do compilador JIT 312 e do executor de código de máquina 316, e pode ser parcialmente executado pelo intérprete 310.

[0038] O uso de esgotamentos pode possibilitar inúmeras otimiza ções. Uma variável em muitas linguagens de programação dinâmicas pode ser uma data, uma cadeia, um arranjo, um número inteiro, e assim por diante. Em algumas linguagens dinâmicas, um objeto é criado para a variável e o local armazenado no registro e, subsequentemente, na tabela compreende um ponteiro para o objeto. O próprio objeto pode armazenar a descrição do objeto e os dados para o objeto. Assim, se a variável a for uma cadeia, um objeto pode ser criado para a cadeia, um ponteiro para o objeto pode ser armazenado, e o próprio objeto pode identificar que a variável a é uma cadeia e pode especificar a própria cadeia (por exemplo, "Hello World"). Uma otimização para esse esquema para o caso em que se supõe que a variável baseada em dados de perfil seja um número inteiro é armazenar o próprio número inteiro na variável em vez do ponteiro para o objeto criado para o número inteiro ou um valor codificado para representar e descrever esse número inteiro objeto. Um esquema para codificar objetos inteiros diretamente é usar um dos bits da palavra para armazenar um indicador que denota que o valor é um número inteiro. Assim, no caso de um processador de 32 bits, um bit dos 32 bits pode indicar que os conteúdos dos outros 31 bits representam o valor de número inteiro, ou podem indicar que os conteúdos dos outros 31 bits não representam o valor de número inteiro.

[0039] A Figura 1d ilustra um exemplo de um sistema 400 que po- de depurar o código nativo transitando-se da execução em modo nativo para a execução em modo interpretado de acordo com os aspectos da matéria revelada no presente documento. Todo ou partes do sistema 400 podem residir em um ou mais computadores ou dispositivos de computação como os computadores descritos abaixo em relação à Figura 3. O sistema 400 pode compreender um sistema conforme ilustrado na Figura 1b e/ou na Figura 1c, ao qual um depurador, etc. con-forme descrito no presente documento foi adicionado. O sistema 400 ou as partes do mesmo podem ser fornecidos como um sistema independente ou como um plug-in ou suplemento. O sistema 400 pode executar em todo ou em parte em um computador de desenvolvimento de software como o computador de desenvolvimento de software descrito em relação à Figura 4. Todo ou partes do sistema 400 podem ser operados pelas ferramentas de desenvolvimento de programa. Por exemplo, todo ou partes do sistema 400 podem ser executados dentro de um ambiente de desenvolvimento integrado (IDE) como, por exemplo, o IDE conforme descrito mais completamente em relação à Figura 4, ou pode ser um outro IDE. O sistema 400 pode ser executado total ou parcialmente fora de um IDE. O sistema 400 pode operar dentro de ou pode ser associado a um navegador como, por exemplo, Internet Explorer® da Microsoft, Firefox da Mozilla, ou qualquer navegador conhecido agora ou desenvolvido no futuro. Será observado que o sis-tema 400 não é restrito à operação dentro de um navegador ou em associação ao mesmo.

[0040] Um sistema 400 ou as partes do mesmo podem incluir in formações obtidas a partir de um serviço (por exemplo, na nuvem) ou pode operar em um ambiente de computação de nuvem. Um ambiente de computação de nuvem pode ser um ambiente em que os serviços de computação não são possuídos, mas são fornecidos sob demanda. Por exemplo, as informações podem residir em diversos dispositivos em uma nuvem em rede e/ou os dados podem ser armazenados em diversos dispositivos dentro da nuvem.

[0041] Um sistema 400 pode incluir um ou mais processadores como processador 142, etc., memória 144 e um ou mais dentre os seguintes: um compilador de linguagem 404, um compilador JIT 408, um mecanismo de esgotamento 414, um depurador 416, um intérprete 418 e/ou um visor de depurador 420 que pode exibir informações de depuração. O compilador de linguagem 404, o compilador JIT 408, o mecanismo de esgotamento 414, o depurador 416 e o intérprete 418 podem ser implementados como um ou mais módulos de programa que quando carregados na memória 144 fazem com que os um ou mais processadores 142, etc. realizem as ações atribuídas ao compilador de linguagem 404, ao compilador JIT 408, ao mecanismo de es-gotamento 414, ao depurador 416 e/ou ao intérprete 418 respectivamente. O sistema 400 pode incluir outros componentes conhecidos na técnica que não são mostrados.

[0042] Conforme mostrado na Figura 1d, o sistema 400 pode inclu ir um compilador de linguagem, como o compilador de linguagem 404. O compilador de linguagem 404 pode ser um compilador que recebe o código fonte escrito em uma linguagem de programação específica e gera a linguagem intermediária como a linguagem intermediária (IL) 406 da mesma. Partes ou todo o código fonte podem ser processados pelo compilador de linguagem 404 para criar o código de linguagem intermediária como IL 406. O compilador de linguagem 404 pode receber o código fonte como código fonte 402 ou porções do mesmo. O código fonte 402 pode ser escrito em qualquer linguagem de programação. O código fonte 402 ou as porções do mesmo podem ser interpretados enviando-se o código fonte 402 para o intérprete 418. Assim, as partes do código fonte 402 podem ser compiladas. As partes do có-digo fonte 402 podem ser interpretadas. Se uma parte do programa é compilada ou interpretada, pode ser com base na heurística de desempenho: se uma parte de programa específica for executada mais rápido no modo nativo, a mesma pode ser compilada para o modo nativo, se uma parte de programa específica for executada mais rápida no modo interpretado, a mesma pode ser interpretada.

[0043] Conforme mostrado na Figura 1d, o sistema 400 pode inclu ir um compilador JIT, como o compilador JIT 408. O compilador JIT 408 pode receber a linguagem intermediária como IL 406 e pode gerar o código nativo como o código nativo 410 do mesmo. O código nativo 410 pode ser carregado em um processo como o processo 412 para execução. O compilador JIT 408 pode ser implementado como um compilador de JavaScript, um compilador de VBScript, um compilador de Python ou como um compilador para uma outra linguagem dinâmica ou linguagem de script dinâmica mencionada em outro lugar no presente documento ou de outro modo conhecida. O compilador JIT 408 é referido como um compilador "just in time" devido ao fato de as porções de programa específicas poderem ser compiladas pelo compilador JIT 408 à medida que o código nativo compilado é necessário (por exemplo, será executado iminentemente), em vez de pré-compilar o código nativo em sua totalidade antes da execução. O compilador JIT 408 pode gerar o código nativo compilado, o qual tem a forma de código ou instruções executáveis por máquina.

[0044] O compilador JIT 408 pode realizar as otimizações de códi go, com base em suposições conforme descrito acima. O compilador JIT 408 pode inserir um ou mais pontos de esgotamento de depuração definidos no código compilado que o mesmo gera. Os pontos de esgotamento de depuração são locais no programa nos quais a depuração em modo nativo pode transitar para a depuração em modo interpretado, contanto que determinadas condições de esgotamento de depuração sejam satisfeitas. Os pontos de esgotamento de depuração como no início de uma função, na borda traseira de um loop, quando uma função retornar, quando uma chamada para uma função do auxiliar ou biblioteca retornar ou quando uma declaração de depurador for encontrada, podem ser definidos para o programa. Quando um esgotamento de depuração ocorrer, a execução do código nativo pode parar. O estado atual do programa em execução em modo nativo pode ser capturado em uma gravação de esgotamento de depuração que pode gravar o ponto de execução atual, um local no código fonte 402 que corresponde ao local de ponto de esgotamento de depuração, aos valores variáveis e onde os valores variáveis estão localizados no registro e/ou onde os valores variáveis estão localizados na pilha. A gravação de esgotamento de depuração para aquele ponto de esgotamento de depuração pode ser passada para o mecanismo de esgotamento.

[0045] Conforme mostrado na Figura 1d, o sistema 400 pode inclu ir um mecanismo de esgotamento, como o mecanismo de esgotamento 414. O mecanismo de esgotamento 412 pode receber uma ou mais gravações de esgotamento de depuração. O mecanismo de esgotamento 414 pode restaurar o estado (por exemplo, valor) de variáveis necessárias pelo intérprete. O mecanismo de esgotamento 414 pode criar um novo quadro para a pilha. Se uma variável necessária pelo intérprete tiver se tornado inativa, o mecanismo de esgotamento 414 pode retornar com uma variável inativa alterando-se o estado da variável de inativo para ativo. O mecanismo de esgotamento 414 pode exemplificar uma instância do intérprete 418, passar para o intérprete o local no código fonte que corresponde ao ponto de esgotamento de depuração no código nativo e o quadro de intérprete recentemente criado que inclui os valores de todas as variáveis ativas restauradas. Se o local de esgotamento de depuração estiver localizado dentre de uma seção de código como uma função, o ponto no qual a depuração continua em modo interpretado pode ser no começo da seção da depura- ção de código (por exemplo, a depuração pode continuar no início da função em vez de no ponto no qual o ponto de esgotamento de depuração foi encontrado).

[0046] Quando um esgotamento de depuração for acionado, a de puração do código nativo pode parar. A execução do código nativo pode parar. O estado pode ser capturado em uma gravação de esgotamento de depuração que grava o ponto de execução atual, os valores variáveis e onde os valores variáveis estão localizados. Os valores variáveis podem ser armazenados nos registros da CPU ou podem ser armazenados na pilha nativa. A gravação de esgotamento de depuração para aquele ponto de esgotamento pode ser passada para o mecanismo de esgotamento 414. O mecanismo de esgotamento 414 pode restaurar o estado (por exemplo, valor) de variáveis necessárias pelo intérprete em uma pilha criada para o intérprete. O mecanismo de esgotamento 414 pode criar um novo quadro de intérprete para a pilha. Se uma variável necessária pelo intérprete tiver se tornado inativa, o mecanismo de esgotamento 414 pode retornar com uma variável alterando-se o estado da variável de inativo para ativo. O mecanismo de esgotamento 414 pode exemplificar uma instância do intérprete 418, passar para o intérprete o local no código fonte que corresponde ao ponto de esgotamento de depuração no código nativo e o quadro de intérprete recentemente criado que inclui os valores de todas as variáveis ativas restauradas.

[0047] Conforme mostrado na Figura 1d, o depurador como o de- purador 416 pode receber o código nativo para a depuração. Um de- purador conforme descrito no presente documento pode ser executado em modo nativo, o que significa que o depurador pode realizar as operações de depuração no código nativo. O depurador de acordo com alguns aspectos da matéria descrita no presente documento pode fornecer valores atuais de variáveis de programa e informações de pilha para exibição em um visor de depurador. As operações de depuração que incluem a inspeção de variáveis, a avaliação de expressão e a modificação de valores podem usar o quadro nativo na pilha de chamadas. Sempre que uma variável for salva em um registro (por exemplo, quando uma variável for definida no programa), o valor também pode ser salvo em um local de pilha para a função. Para manter rastro do local do valor da variável local específica, de acordo com os aspectos da matéria descrita no presente documento, toda vez que uma variável local for definida (isto é, um valor é atribuído à variável local), a mesma pode ser escrita em um local de pilha. Os locais de pilha usados para as variáveis locais para uma função podem ser agrupados de modo que haja uma região de pilha em que as variáveis locais para uma função podem ser encontradas. Assim, um valor atual de qualquer variável local para uma função específica está sempre em um local de pilha correspondente, mesmo se o código nativo estiver usando um registro para a variável. A mesma área da pilha pode ser usada para o derramamento (spilling) (isto é, onde há mais variáveis vivas do que o dispositivo de computação tem registros, as variáveis podem ser "derramadas" dos registros para a memória). Os locais de pilha podem ser usados pelo depurador para obter e alterar valores de variáveis. Para suportar a modificação de valores no depurador, um indicador pode estar localizado adjacente à área da pilha em que as variáveis locais estão armazenadas. O indicador pode ser um sinalizador que, quando o conjunto indicar que uma variável local na função está sendo depurada, foi alterada pelo usuário. A função depurada pode ser a função no quadro de pilha mais superior ou uma função em um quadro de pilha abaixo. Por exemplo, supõe-se que um ponto de interrupção seja encontrado. Um usuário pode alterar o valor de uma variável local que pertence a uma função associada a um quadro de pilha do que não é o quadro de pilha atual, enquanto executa a função no modo nativo. Um sinalizador que indica que uma variável local na função foi alterada será definido no quadro de pilha associado a uma função cuja variável local foi alterada pelo usuário.

[0048] Os metadados de função incluem informações que se refe rem a como muitas variáveis locais são usadas na função. De acordo com alguns aspectos da matéria descrita no presente documento, para obter o valor de uma variável local, o depurador pode determinar o valor de uma variável local através da leitura do valor nos locais de pilha que residem no deslocamento do local de início na pilha igual ao identificador da variável local. Para alterar o valor de uma variável local, o depurador pode escrever um novo valor para o local de pilha correspondente, e pode definir um sinalizador de variável local alterada (localizada na pilha próxima de uma área em que as variáveis locais podem ser armazenadas) para indicar que uma variável local na função foi alterada.

[0049] Quando a execução retornar para a função que é executa da em modo nativo, o mecanismo de esgotamento pode verificar o sinalizador de variável local alterada. No caso em que um valor de variável local foi alterado para o quadro de pilha que corresponde à função à qual a execução retorna, o sinalizador será definido, e o esgotamento para o modo interpretado será acionado. Durante o esgotamento, os valores de variáveis locais podem ser restaurados a partir de locais de pilha (em vez de a partir dos registros), e o depurador que é executado no modo interpretado irá receber o valor para o qual a variável local modificada foi alterada.

[0050] O depurador pode transitar da execução em modo nativo para a execução em modo interpretado em pontos definidos no programa chamado pontos de esgotamento de depuração. Os pontos de esgotamento de depuração incluem, mas sem limitação, o seguinte: no início de uma função, na borda traseira de um loop (por exemplo, após um contador ser incrementado e o contador ter sido verificado por estar fora de alcance), quando retornar de uma chamada para uma função, quando retornar de uma chamada para uma biblioteca, quando retornar de uma chamada para uma função do auxiliar, quando uma declaração de linguagem de depurador for encontrada, e assim por diante. Um depurador conforme descrito no presente documento pode ser executado em modo interpretado. No modo interpretado, o depu- rador pode depurar o código interpretado. Por exemplo, as operações de depuração que controlam a execução do programa que é depurado podem ser executadas em modo interpretado. As operações de controle de execução podem ser implementadas por meio de interrupção assíncrona, escalonamento, ponto de interrupção e/ou interrupção em operações de execução.

[0051] Uma interrupção assíncrona pode ocorrer, por exemplo, quando um usuário em uma sessão de depuração pausar a execução (por exemplo, ativando-se uma opção de pausa em uma interface de usuário de depurador). Uma pausa pode ocorrer a qualquer momento. À medida que se espera que o depurador interrompa a execução do programa em um tempo responsável após uma ação do usuário. O fornecimento de uma resposta oportuna para uma ação do usuário pode ser feito inserindo-se verificações em locais no código que inclui, mas sem limitação: no início de uma função, em um loop, etc. Em resposta, o depurador pode definir um sinalizador de transição que quando define as forças transitam da depuração em modo nativo para a depuração em modo interpretado. Um sinalizador de transição para cada thread no processo pode ser fornecido. Quando se executa o código nativo, entra-se em uma função ou vai para o início de um loop, o sinalizador de transição pode ser examinado. Se o sinalizador de transição for definido, o esgotamento de depuração pode ser acionado, e a execução pode transitar da depuração em modo nativo para a depura- ção em modo interpretado. O código fonte análogo à função pode ser recuperado e enviado para o intérprete. O depurador pode detectar a interrupção assíncrona e pode limpar o sinalizador de transição. A interrupção assíncrona pode ser completada interrompendo-se (parando-se) a execução e exibindo-se o estado de programa atual no visor de depurador.

[0052] Uma operação de etapa pode ser uma ação direcionada ao usuário que entra em uma função, sai de uma função ou passa por uma função ou instrução. No início de cada operação de depuração de etapa, o depurador pode definir um sinalizador de tipo de etapa e um sinalizador de base de quadro de etapa. O sinalizador de base de quadro de etapa pode ser definido para a base de quadro de pilha de função atual. O sinalizador de quadro de etapa pode ser usado para verificar a profundidade de pilha para a recursão de detecção. De acordo com alguns aspectos da matéria revelada no presente documento, a transferência para o modo de intérprete não é feita quando a execução deixar a mesma função no topo do quadro como quando a operação de etapa tiver se iniciado na pilha. Por exemplo, considera- se um local atual na função A e o usuário tende a sair quando teria que retornar para a função B, o chamador da função A. Se a função A chamar uma outra função, que seria a função A ou a função B, quando o controle retornar de volta para a função A ou a função B ou para uma outra função enquanto o quadro de pilha original da função A, quando a etapa for iniciada, ainda estiver na pilha, o esgotamento de depuração não é acionado.

[0053] Para uma operação de saída, o depurador pode definir o sinalizador do tipo de etapa para saída. A execução do programa pode continuar. Quando a execução retornar da função atual para uma outra em execução em modo nativo, o mecanismo de esgotamento pode determinar se o sinalizador do tipo de etapa e o sinalizador de quadro de etapa são definidos. Se for o caso, a base de quadro de pilha atual pode ser comparada ao valor armazenado no sinalizador de quadro de etapa. Se a base de quadro de pilha atual for maior do que o valor armazenado no sinalizador de quadro de etapa, supondo-se que a pilha aumente em direção aos endereços menores, a profundidade de pilha diminuiu. Em resposta a uma diminuição na profundidade de pilha, o esgotamento para o modo de intérprete pode ser acionado. O depura- dor pode transitar para a depuração de código interpretado. A execução pode parar, e o estado de programa atual pode ser exibido no visor de depurador.

[0054] Quando o código nativo inserir outra função que é executa da em modo nativo ou se uma operação de entrada for feita na última declaração da função que resulta no retorno da função, o esgotamento verifica se esses sinalizadores ocorrem e o esgotamento para a depuração em modo de intérprete é acionado. O depurador opera em modo interpretado e pode exibir o estado de programa atual no visor de de- purador.

[0055] Para as operações de depuração de passagem, a função para passagem não é forçada para ser executada em modo de intérprete, e, tipicamente, é executada em modo nativo. O esgotamento só pode ser acionado quando a operação de etapa estava na última declaração da função atual e resulta em um retorno da função. Em resposta a uma diminuição na profundidade de pilha, o esgotamento para a depuração em modo de intérprete é acionado. O depurador pode exibir o estado de programa atual no visor de depurador.

[0056] Quando o usuário definir um ponto de interrupção em uma função, o depurador pode atualizar os metadados de função incrementando-se um contador que rastreia o número de pontos de interrupção na função. Quando a função for executada (ou a função começar a execução ou a função chamar uma outra função e a função chamada retornar de volta para a função de chamada), as condições que acionam o esgotamento de depuração são verificadas. Se o ponto de interrupção apto para a função atual para a função atual for maior do que zero, o esgotamento de depuração pode ser acionado e o depurador pode transitar para a execução em modo interpretado. O depurador pode parar na declaração em que o ponto de interrupção é definido e pode exibir o ponto de execução atual no visor de depurador.

[0057] Se um ponto de interrupção na exceção/continuação após a exceção ser encontrada, o programa executado sob o depurador pode comunicar o evento de exceção para o depurador e pode continuar a execução a partir da próxima declaração que causou a exceção ou pode definir a execução para resumir em uma declaração específica e continuar a partir dessa declaração. Para notificar o depurador, o código nativo pode usar uma função de "throwing helper" de modo que todas as posições (throws) sejam roteadas através do mesmo. O depu- rador pode parar na declaração de que posicionou a exceção e pode exibir valores de variáveis no visor de depurador.

[0058] Para continuar para a próxima declaração, (no caso, o pro grama estava em execução em modo nativo quando a exceção foi po-sicionada), o compilador pode identificar todos os lugares no programa em que a exceção pode ocorrer. As exceções podem ser posicionadas por uma declaração de posição explícita, quando uma chamada for feita para uma função do auxiliar ou quando uma chamada for feita para uma função de biblioteca. Por exemplo, a declaração para apagar JavaScript que apaga uma propriedade de um objeto, pode posicionar uma exceção se o objeto for nulo ou indefinido. A exceção é posicionada devido a um objeto nulo ou indefinido não tem quaisquer propriedades. No presente, o "auxiliar" se refere a uma função implantada na linguagem (por exemplo, no mecanismo JavaScript), tipicamente em código nativo, e é usado para realizar alguma operação ou construto de linguagem, como para apagar uma propriedade de um objeto. A "função de biblioteca" se refere a uma função que implanta uma rotina de biblioteca. Por exemplo, o JavaScript tem inúmeros objetos de biblioteca, como "cadeia". O objeto "cadeia" tem inúmeras operações, inclusive string. concat, por exemplo. A string. concat não é uma rotina de linguagem pura. Em algumas linguagens pode não ser razoável para distinguir entre uma função de biblioteca e uma função de auxiliar, mas em algumas linguagens como, mas sem limitação, JavaScript as mesmas diferem no sentido a seguir: uma chamada de biblioteca é tecnicamente a mesma que uma chamada de função de script (isto é, usuário) e, então, pode ser interceptada. Por exemplo, um usuário po-de atribuir uma função de script à string. concat. A próxima vez que a string. concat for chamada, o mecanismo irá chamar a função de usuário atribuído novamente da função string. concat original. As funções de auxiliar não podem ser interceptadas e são tipicamente chamadas diretamente no código nativo/compilado.

[0059] Para continuar após uma exceção ocorrer no código nativo, cada chamada de auxiliar e cada chamada de biblioteca pode ser envolvida em um bloco de declaração try-catch. Na parte "try" do bloco try-catch, uma função de auxiliar pode ser chamada. Os valores retornados pela função de auxiliar podem ser salvos em uma variável local. Na parte "catch" do bloco try-catch se uma opção de "continuar após exceção" for possibilitada no depurador em modo interpretado, um sinalizador de exceção e continuação pode ser definido. Após a parte "catch" do bloco try-catch, o valor do auxiliar original pode ser retornado. A verificação de esgotamento de depuração para continuar após uma exceção pode ser inserida após cada retorno de cada chamada para uma chamada de função de auxiliar ou após cada retorno de uma chamada para uma biblioteca. A verificação de esgotamento de depu-ração pode verificar o sinalizador de exceção e continuação e pode acionar um esgotamento de depuração para o modo de intérprete se o sinalizador for definido. O depurador pode transitar para o modo de intérprete que possibilita que o controle de execução continue dentro do depurador. Por exemplo, se a resposta do usuário para "interromper na exceção" fosse para passar por uma instrução, o depurador passaria para a próxima declaração. Se a resposta do usuário para "interromper na exceção" fosse para continuar, o depurador continuaria a execução do resto da função no modo interpretado.

[0060] Um depurador pode exibir informações de depuração em um dispositivo de exibição de depurador como o visor de depurador 420. O depurador pode exibir informações da pilha de chamadas, valores de variáveis locais, etc. no visor de depurador.

[0061] A Figura 2 ilustra um método 250 que pode transitar da de puração em modo nativo para a depuração em modo interpretado de acordo com os aspectos da matéria revelada no presente documento. O método descrito na Figura 2 pode ser praticado por um sistema como, mas sem limitação, o descrito em relação à Figura 1d. Embora o método 250 descreva uma série de operações que são realizadas em uma sequência, deve-se compreender que o método 250 não é limitado pela ordem da sequência. Por exemplo, algumas operações podem ocorrer em uma ordem diferente daquela descrita. Além disso, uma operação pode ocorrer concorrentemente com outra operação. Em alguns casos, nem todas as operações descritas são realizadas.

[0062] Em operação, um sistema como o sistema descrito na Figu ra 1d pode operar conforme segue. Na operação 251, os pontos de esgotamento de depuração podem ser definidos para um programa. Os pontos de esgotamento de depuração são pontos no programa em que uma transição da depuração em modo nativo para a depuração em modo interpretado pode ocorrer. Os pontos de esgotamento de depuração incluem, mas sem limitação, o seguinte: no início de uma função, na borda traseira de um loop (por exemplo, após um contador ser incrementado e o contador ter sido verificado por estar fora de alcance), quando retornar de uma chamada para uma função, quando retornar de uma chamada para uma biblioteca, quando retornar de uma chamada para uma função do auxiliar, quando uma declaração de linguagem de depurador for encontrada e assim por diante. Quando o programa for compilado, o processamento de depuração pode ser inserido nos pontos de esgotamento de depuração.

[0063] Na operação 252, uma sessão de depuração pode ser ini ciada. Quando uma sessão de depuração for iniciada, qualquer código nativo gerado anteriormente para o programa em execução no processo ao qual o depurador é fixado pode ser descarregado. Na operação 254, o código nativo de modo de depuração pode ser gerado a partir do programa ao qual o depurador é fixado. O código nativo de modo de depuração pode incluir o processamento associado à transição da depuração de código nativo para a depuração de código interpretado. O código nativo de modo de depuração pode ser carregado em um processo. Quando uma função for compilada no código nativo no modo de depuração, em cada ponto de esgotamento na função, uma ou mais verificações de condição de esgotamento podem ser inseridas no código nativo. As verificações de condição de esgotamento podem ser inseridas durante a fase de compilação que gera uma representação nativa interna do programa. As verificações de condição de esgotamento podem ser inseridas no código à medida que os dados para a gravação de esgotamento são capturados. As verificações de condição de esgotamento podem incluir a situação (definida ou não definida) ou valores de vários marcadores ou indicadores controlados pelo depurador.

[0064] Os indicadores ou sinalizadores de esgotamento de depu ração podem incluir, mas sem limitação: um indicador que, quando de- finido, indica que o depurador deve transitar do modo nativo para o modo interpretado, um indicador quem quando definido, indica que uma função tem um ponto de interrupção no mesmo, um indicador que especifica uma endereço de pilha para detectar a recursão, um indicador que indica um tipo de operação de etapa a ser realizada, um indicador que, quando definido, indica o tipo de operação de etapa (entrar, sair, passar) o depurador é realizado, um indicador na pilha que, quando definido, indica que um campo foi alterado no quadro de pilha atual e um indicador que, quando definido, é usado para injetar um esgotamento incondicional explícito.

[0065] Em operação 256, o código nativo pode ser executado no modo de depuração. Quando a execução alcançar um ponto de esgotamento de depuração, várias condições de esgotamento podem ser verificadas. As condições de esgotamento verificadas para um tipo de cenário de esgotamento de depuração podem diferir das condições de esgotamento verificadas para outros tipos de esgotamentos. Por exemplo, supõe-se que um usuário pause a execução de um programa que é executado sob o depurador no início de uma função ou na borda traseira de um loop (quando o contador para o loop for incrementado e o contador for verificado para estar dentro da faixa). O de- purador pode definir um sinalizador que força o código nativo ao esgotamento para o modo de intérprete quando o código nativo inserido no início da função ou na borda traseira do loop verificar para ver se o sinalizador que força o código nativo ao esgotamento para o modo de intérprete é definido. Supõe-se que, em vez disso, um usuário selecione uma opção em uma UI de depurador que insere uma função. O de- purador pode definir um sinalizador de etapa que indica qual tipo de operação de etapa foi solicitada. A verificação realizada pelo código nativo pode se esgotar em resposta à determinação de que o valor do sinalizador de etapa é definido para "entrar". Supõe-se que uma ação do usuário coloque um ponto de interrupção em algum lugar em uma função. O depurador pode incrementar um sinalizador que mantém rastro do número de pontos de interrupção na função. Se a contagem de ponto de interrupção na função atual for maior do que zero, o esgotamento é acionado, a execução vai para o modo interpretado.

[0066] Quando a execução alcançar o quadro que tem o ponto de interrupção, a execução do programa no código nativo para, o mecanismo de esgotamento recebe a gravação de esgotamento de depuração, a função é enviada para o intérprete e a depuração da função interpretada continua a partir do início da função. Na operação 260, em resposta à determinação de que pelo menos uma condição de esgotamento foi satisfeita na operação 258, a depuração em modo nativo pode parar e a depuração pode transitar para o modo interpretado. Uma transição da depuração do código nativo para depuração do código interpretado correspondente pode ser acionada por uma ação iniciada por usuário, ou pode ser acionada quando um esgotamento in-condicional explícito for encontrado.

[0067] Na operação 262, as variáveis do intérprete podem ser res tauradas a partir da gravação de esgotamento. Se qualquer condição de esgotamento for satisfeita, uma captura instantânea de estado de execução (local e valor de variáveis, local e valor de variáveis temporárias, e os valores de pilha podem ser feitos e persistidos em uma gravação de esgotamento de depuração. A gravação de esgotamento de depuração pode ser enviada para o mecanismo de esgotamento. O mecanismo de esgotamento pode exemplificar uma instância do intérprete e pode configurar o quadro de pilha de intérprete para o intérprete. Na operação 264, a depuração pode continuar no modo interpretado. Na operação 266, se nenhuma condição de esgotamento for detectada na operação 258, a depuração em modo nativo pode continuar.

Exemplo de um Ambiente de Computação Adequado

[0068] A fim de fornecer o contexto para vários aspectos da maté ria revelada no presente documento, a Figura 3 e a discussão a seguir são destinadas a fornecer uma breve descrição geral de um ambiente de computação adequado 510 em que várias modalidades da matéria revelada no presente documento podem ser implementadas. Embora a matéria revelada no presente documento seja descrita no contexto geral de instruções executáveis em computador, como módulos de programa, executadas por um ou mais computadores ou outros dispositivos de computação, aqueles versados na técnica irão reconhecer que as porções da matéria revelada no presente documento também podem ser implementadas em combinação com outros módulos de programa e/ou uma combinação de hardware e software. Em geral, os módulos de programa incluem rotinas, programas, objetos, artefatos físicos, estruturas de dados, etc. que realizam tarefas específicas ou implantam tipos de dados específicos. Tipicamente, a funcionalidade dos módulos de programa pode ser combinada ou distribuída conforme desejado em várias modalidades. O ambiente de computação 510 é apenas um exemplo de um ambiente operacional adequado e não está destinado a limitar o escopo de uso ou a funcionalidade da matéria revelada no presente documento.

[0069] Em referência à Figura 3, um dispositivo de computação na forma de um computador 512 é descrito. O computador 512 pode incluir pelo menos uma unidade de processamento 514, uma memória do sistema 516 e um barramento de sistema 518. A pelo menos uma unidade de processamento 514 pode executar instruções que são armazenadas em uma memória, como, mas sem limitação, a memória do sistema 516. A unidade de processamento 514 pode ser qualquer um dentre vários processadores disponíveis. Por exemplo, a unidade de processamento 514 pode ser uma unidade de processamento gráfico (GPU). As instruções podem ser instruções para implantar a funci- onalidade realizada por um ou mais componentes ou módulos discutidos acima ou instruções para implantar um ou mais dos métodos descritos acima. Os microprocessadores duplos e outras arquiteturas de multiprocessador também podem ser empregados como a unidade de processamento 514. O computador 512 pode ser usado em um sistema que suporta os gráficos de renderização em uma tela de exibição. Em um outro exemplo, pelo menos uma porção do dispositivo de computação pode ser usada em um sistema que compreende uma unidade de processamento gráfico. A memória do sistema 516 pode incluir memória volátil 520 e memória não volátil 522. A memória não volátil 522 pode incluir a memória apenas de leitura (ROM), ROM programável (PROM), ROM eletricamente programável (EPROM) ou memória flash. A memória volátil 520 pode incluir memória de acesso aleatório (RAM), que age como a memória cache externa. O barramento de sistema 518 acopla artefatos físicos de sistema, o que inclui a memória do sistema 516 à unidade de processamento 514. O barramento de sistema 518 pode ser de quaisquer tipos diversos que incluem um bar- ramento de memória, controlador de memória, barramento periférico, barramento externo ou barramento local e pode usar qualquer variedade de arquiteturas de barramento disponíveis. O computador 512 pode incluir um armazenamento de dados acessível pela unidade de processamento 514 por meio do barramento de sistema 518. O armazenamento de dados pode incluir instruções executáveis, modelos em 3D, materiais, texturas, e assim por diante, para a renderização de gráficos.

[0070] O computador 512 inclui, tipicamente, uma variedade de mídias legíveis por computador, como mídia volátil e não volátil, mídia removível e não removível. A mídia legível por computador pode ser implantada em qualquer método ou tecnologia para o armazenamento de informações, como instruções legíveis por computador, estruturas de dados, módulos de programa ou outros dados. As mídias legíveis por computador incluem mídia de armazenamento legível por computador (também referida como mídia de armazenamento em computador) e mídia de comunicação. A mídia de armazenamento em computador (tangível) inclui, mas não sem limitação, RAM, ROM, EEPROM, memória flash ou outra tecnologia de memória, CDROM, discos versáteis digitais (DVD) ou outro armazenamento em disco óptico, cassetes magnéticos, fita magnética, armazenamento em disco magnético ou outros dispositivos de armazenamento magnético que podem armazenar os dados desejados e que podem ser acessados por computador 512. A mídia de comunicação inclui mídia como, mas sem limitação, sinais de comunicações, ondas de portadora moduladas ou qualquer outra mídia intangível que possa ser usada para comunicar as informações desejadas e que podem ser acessadas por computador 512.

[0071] Será observado que a Figura 3 descreve o software que pode agir como um intermediário entre os usuários e os recursos de computador. Esse software pode incluir um sistema operacional 528 que pode ser armazenado no armazenamento em disco 524 e que pode alocar recursos do computador 512. O armazenamento em disco 524 pode ser uma unidade de disco rígido conectada ao barramento de sistema 518 através de uma interface de memória não removível como a interface 526. As aplicações de sistema 530 levam a vantagem do gerenciamento de recursos operando-se o sistema 528 através de módulos de programa 532 e dados de programa 534 armazenados na memória do sistema 516 ou no armazenamento em disco 524. Será observado que os computadores podem ser implementados com vários sistemas operacionais ou combinações de sistemas operacionais.

[0072] Um usuário pode inserir comandos ou informações no computador 512 através de dispositivo(s) de entrada 536. Os dispositivos de entrada 536 incluem, mas sem limitação, um dispositivo apon- tador como um mouse, trackball, caneta stylus, teclado sensível ao toque, teclado, microfone, sistemas de reconhecimento de voz e de reconhecimento de gesto, e semelhantes. Esses e outros dispositivos de entrada se conectam à unidade de processamento 514 através do barramento de sistema 518 por meio de porta(s) de interface 538. Uma(s) porta(s) de interface 538 pode(m) representar uma porta serial, porta paralela, barramento serial universal (USB), e semelhantes. Ou- tro(s) dispositivos(s) 540 pode(m) usar o mesmo tipo de portas como fazem os dispositivos de entrada. O adaptador de saída 542 é fornecido para ilustrar que há alguns dispositivos de saída 540 como monitores, alto-falantes e impressoras que exigem adaptadores específicos. Os adaptadores de saída 542 incluem, mas sem limitação, vídeo e placas de som que fornecem uma conexão entre o dispositivo de saída 540 e o barramento de sistema 518. Outros dispositivos e/ou sistemas ou dispositivos como computador(es) remoto(s) 544 podem fornecer tanto capacidades de entrada quanto de saída.

[0073] O computador 512 pode operar em um ambiente de rede que usa conexões lógicas com um ou mais computadores remotos, como um(uns) computador(es) remoto(s) 544. O computador remoto 544 pode ser um computador pessoal, um servidor, um roteador, um PC com rede, um dispositivo par ou outro nó de rede comum, e inclui tipicamente muitos ou todos os elementos descritos acima em relação ao computador 512, embora apenas um dispositivo de armazenamento de memória 546 tenha sido ilustrado na Figura 3. O(s) computa- dor(es) remoto(s) 544 pode(m) ser logicamente conectados por meio de conexão(ões) de comunicação 550. A interface de rede 548 abrange redes de comunicação como redes de área local (LANs) e redes de área ampla (WANs), mas também inclui outras redes. A(s) cone- xão(ões) de comunicação 550 se refere(m) ao hardware/software empregado para conectar a interface de rede 548 ao barramento 518. A(s) conexão(ões) de comunicação 550 pode(m) ser internas ou externas ao computador 512 e inclui(em) tecnologias internas e externas como modems (telefone, cabo, DSL e sem fio) e adaptadores ISDN, placas de Ethernet e assim por diante.

[0074] Será observado que as conexões de rede mostradas são apenas exemplos e outros meios de estabelecimento de um enlace de comunicações entre os computadores podem ser usados. Uma pessoa versada na técnica pode observar que um computador 512 outro dispositivo de cliente pode ser instalado como parte de uma rede de computadores. Nesse sentido, a matéria revelada no presente documento pode pertencer a qualquer sistema de computador que tem qualquer número de unidades de armazenamento ou memória, e qualquer número de aplicações e processos que ocorrem através de qualquer número de unidades de armazenamento ou volumes. Os aspectos da matéria revelada no presente documento podem se aplicar a um ambiente com computadores servidores e computadores clientes instalados em um ambiente de rede, que tem armazenamento remoto ou local. Os aspectos da matéria revelada no presente documento também podem se aplicar a um dispositivo de computação independente, que tem a funcionalidade de linguagem de programação, capacidades de interpretação e execução.

[0075] A Figura 4 ilustra um ambiente de desenvolvimento integra do (IDE) 600 e Ambiente de Tempo de Funcionamento de Linguagem Comum 602. Um IDE 600 pode permitir que um usuário (por exemplo, desenvolvedor, programador, designer, codificador, etc.) para projetar, codificar, compilar, testar, executar, editar, depurar ou construir um programa, conjunto de programas, sites da web, aplicativos da web e serviços da web em um sistema de computador. Os programas de software podem incluir código fonte (componente 610), criado em uma ou mais linguagens de código fonte (por exemplo, Visual Basic, Visual J#, C++. C#, J#, Java Script, APL, COBOL, Pascal, Eiffel, Haskell, ML, Oberon, Perl, Python, Scheme, Smalltalk e semelhantes). O IDE 600 pode fornecer um ambiente de desenvolvimento de código nativo ou pode fornecer um desenvolvimento de código gerenciado que é executado em uma máquina virtual ou pode fornecer uma combinação dos mesmos. O IDE 600 pode fornecer um ambiente de desenvolvimento de código gerenciado com o uso do framework Microsoft. NET™. Um componente de linguagem intermediária 650 pode ser criado a partir do componente de código fonte 610 e do componente de código nativo 611 com o uso de um compilador de fonte específica de linguagem 620 com o uso de uma ferramenta de modelagem 652 e armazenamento de modelo 653 e o componente de código nativo 611 (por exemplo, instruções executáveis em máquina) é criado a partir do componente de linguagem intermediária 650 com o uso do compilador de linguagem intermediária 660 (por exemplo, compilador just-in-time (JIT)), quando o aplicativo for executado. Ou seja, quando um aplicativo de linguagem intermediária (IL) for executado, é compilado enquanto é executado na linguagem de máquina adequada para a plataforma na qual é executada tornando, desse modo, o código portátil através de diversas plataformas. Alternativamente, em outras modalidades, os programas podem ser compilados para a linguagem de máquina de código nativo (não mostrada) adequada para sua plataforma destinada.

[0076] Um usuário pode criar e/ou editar o componente de código fonte de acordo com as técnicas de programação de software conhecidas e as regras sintáticas e lógicas específicas associadas a uma linguagem fonte específica por meio de uma interface de usuário 640 e um editor de código fonte 651 no IDE 600. Portanto, o componente de código fonte 610 pode ser compilado por meio de um compilador fonte 620, por meio de qual uma representação de linguagem intermediária do programa pode ser criada, como a montagem 630. A montagem 630 pode compreender o componente de linguagem intermediária 650 e metadados 642.

[0077] Os projetos de aplicativo podem ter a capacidade de serem validados antes do posicionamento.

[0078] As várias técnicas descritas no presente documento podem ser implementadas em conjunto com hardware ou software ou onde adequado, com uma combinação de ambos. Assim, os métodos e o aparelho descritos no presente documento ou determinados aspectos ou porções dos mesmos podem assumir a forma de código de programa (isto é, instruções) incorporados em mídia tangível, tais como disquetes, CD-ROMs, unidades rígidas ou qualquer outro meio de armazenamento legível por máquina em que, quando o código de programa é carregado em uma máquina e executado pela mesma, tal como um computador, a máquina se torna um aparelho para praticar os aspectos da matéria revelada no presente documento. Conforme usado no presente documento, o termo "meio de armazenamento legível por máquina" deve ser tomado para excluir qualquer mecanismo que forneça (isto é, armazene e/ou transmita) qualquer forma de sinais propagados. No caso de execução de código de programa em computadores programáveis, o dispositivo de computação pode incluir, em geral, um processador, um meio de armazenamento legível pelo processador (inclusive memória volátil e não volátil e/ou elementos de armazenamento), pelo menos um dispositivo de entrada e pelo menos um dispositivo de saída. Um ou mais programas que podem utilizar a criação e/ou a implementação de aspectos de modelos de programação específicos de domínio, por exemplo, através do uso de um API de processamento de dados ou semelhantes, podem ser implementados em uma linguagem de programação orientada a objetos ou processual de alto nível para se comunicar com um sistema de computador. Entretanto, o(s) programa(s) pode(m) ser implementado(s) em lin guagem de máquina ou montagem, se desejado. De qualquer maneira, a linguagem pode ser uma linguagem compilada ou interpretada e combinada com implantações de hardware.

[0079] Embora a matéria tenha sido descrita em linguagem específi ca aos recursos estruturais e/ou ações metodológicas, deve-se compreender que a matéria definida nas reivindicações anexas não é, necessariamente, limitada aos recursos ou ações específicas descritas acima.

Claims

1. Sistema compreendendo: pelo menos um processador de um dispositivo de computação; uma memória do dispositivo de computação; e um código de byte (325) gerado a partir de um código fonte; um depurador que compreende pelo menos um módulo de programa carregado na memória que faz com que o pelo menos um processador: em uma compilação de modo de depuração do módulo de programa, insirir pelo menos um ponto de esgotamento em um código nativo gerado por um compilador do bytecode, caracterizado pelo fato de que o pelo menos um ponto de esgotamento é um local no código nativo em que a depuração de código nativo pode transitar para a depuração do modo interpretado, desde que certas condições de esgotamento sejam satisfeitas; execute o código nativo; e em resposta à detecção em um ponto de esgotamento que pelo menos uma condição de esgotamento de depuração foi satisfeita, transitar a partir da depuração do código nativo no modo nativo para a depuração do código de byte interpretado, correspondente ao código nativo que está sendo depurado, no modo interpretado.

2. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende: pelo menos um módulo de programa carregado na memória, que faz com que o pelo menos um processador: receba o estado atual do código nativo em execução sob o depurador; exemplifique uma instância de um intérprete; crie um quadro de pilha de intérprete para a instância do in- térprete; e preencha o quadro de pilha de intérprete para o intérprete exemplificado com o estado atual do código nativo.

3. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende: pelo menos um módulo de programa carregado na memória que faz com que o pelo menos um processador: receba locais de esgotamento definidos para o programa que compreende pelo menos um dentre: no início de uma função, em uma borda traseira de um loop, quando uma função retornar, quando uma chamada para uma função auxiliar retornar, quando uma chamada para uma biblioteca retornar ou quando uma declaração de depurador for encontrada.

4. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende: pelo menos um módulo de programa carregado na memória que faz com que o pelo menos um processador: transite para depurar o código interpretado que representa o programa em resposta ao recebimento de uma operação de controle de execução.

5. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende: pelo menos um módulo de programa carregado na memória que faz com que o pelo menos um processador: execute uma operação de depuração no modo nativo, sendo que a operação de depuração modifica um valor atual de um modo nativo variável que compreende depurar o código nativo que representa o programa.

6. Método caracterizado pelo fato de que compreende: gerar um código de byte (325) a partir de um código fonte; receber através de um processador de um dispositivo de computação pelo menos um ponto de condição de esgotamento de depuração para um código de byte, sendo que o pelo menos um ponto de condição de esgotamento de depuração é um local em código nativo gerado a partir do código de byte no qual a depuração transita da depuração do código nativo em código nativo para a depuração do código interpretado para o programa em resposta à determinação de que pelo menos uma condição de esgotamento de depuração foi satisfeita; iniciar uma sessão de depuração para o programa; gerar com um compilador o código nativo a partir do código de byte para a depuração; executar o código nativo gerado sob um depurador; em resposta à determinação de que a condição de esgotamento de depuração associada a um ponto de esgotamento foi satisfeita, continuar (260) a execução do código de byte correspondente ao código nativo sendo depurado no modo interpretado sob depurador; restaurar (262) variáveis de intérprete que correspondem às variáveis associadas ao código nativo executado; e retomar (264) a depuração do programa no modo interpretado em um ponto no qual a depuração do código nativo parou.

7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que ainda compreende: receber o pelo menos um ponto de esgotamento de depuração para o programa, sendo que o pelo menos um ponto de esgotamento de depuração compreende um dentre: no início de uma função, em uma borda traseira de um loop, quando uma função retornar, quando uma chamada para uma função auxiliar retornar, quando uma biblioteca retornar, ou quando uma declaração de depurador for encontrada no código nativo.

8. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que ainda compreende: transitar para a depuração de modo interpretado em reposta ao recebimento de uma operação de depuração que compreende uma operação de controle de execução que compreende um dentre uma operação de interrupção assíncrona, uma operação de etapa, um ponto de interrupção, ou uma interrupção na operação de exceção.

9. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que ainda compreende: determinar, em resposta a uma diminuição na profundidade da pilha, que uma condição de esgotamento de depuração foi satisfeita, compreendendo a comparação de uma base de quadros de pilha atual a um sinalizador de quadro de etapas definido pelo depurador.

10. Meio de armazenamento legível por computador caracterizado pelo fato de que compreende o método conforme definido em qualquer uma das reivindicações 6 a 9.