[HACKERS] Bytecode and virtual machine
Jonah, What do you see as the advantages of using a VM and bytecode? Regarding Antlr etal, are there any that generate C code. I am more familiar with the java parsers. If we can't generate C this is probably a non-starter. Dave On 28-Jun-05, at 5:58 PM, Jonah H. Harris wrote: Dave, I lean with you and Tom. While running it over the same libpq protocol would be helpful in some ways, it would have a lot of drawbacks and would really change the function of libpq. I think a separate debugging protocol is in order. Also, as far as bytecode comments go, let's separate them from this thread. I have a pretty sweet hand-written stack-based VM that understands PL/SQL, but it's kinda old and written using PCCTS 1.33 (a recursive descent parser). It has compilation, decompilation, and full debugging capabilities. Unfortunately, PCCTS is no longer maintained as Terrence Parr (the originator) has since moved to ANTLR. ANTLR currently does not generate C code although I have done some starting work on it (ANTLR currently generates Python, Java, or C++). I don't suggest we really reuse one of the current VMs as it would require a lot more support and coordination. Let's take the bytecode discussion off this thread and move it to another. There is certainly a good and bad side to using bytecode and I would be glad to discuss it in another thread. Dave Cramer wrote: Pavel, I am in agreement with Tom here, we should use a separate port, and protocol specifically designed for this. My understanding is that this protocol would be synchronous, and be used for transferring state information, variables, etc back and forth whereas the existing protocol would still be used to transfer data back and forth Dave On 28-Jun-05, at 10:36 AM, Pavel Stehule wrote: On Tue, 28 Jun 2005, Tom Lane wrote: Pavel Stehule [EMAIL PROTECTED] writes: What do you think you need for enhanced protocol ? What I need? Some like synchronous elog(NOTICE,''), which can return some user's interaction, if it's possible. I didn't find how I do it with current set of messages. But my knowleadges of protocol are minimal. It'd probably be smarter to manage the debugging across a separate connection, so that you could carry out debugging without requiring sophisticated support for it inside the client program. If it's single-connection then it will be essentially impractical to debug except from a few specialized clients such as pgadmin; which will make it hard to investigate behaviors that are only seen under load from a client app. I don't think it. Debug process halt query process in bouth variants - remote | protocol. Remote debugging has one advance. I can monitor any living plpgsql process, but I have to connect to some special port, and it can be problem. Protocol debugging can be supported libpq, and all clients libpq can debug. But is problem if PostgreSQL support bouth variants? btw: debuging have to be only for some users, GRANT DEBUG ON LANGUAGE plpgsql TO .. For me, is better variant if I can debug plpgsql code in psql console. Without spec application. I don't speak so spec application don't have to exists (from my view, ofcourse). Maybe: set debug_mode to true; -- if 't' then func stmt has src reset function myfce(integer, integer); -- need recompilation create breakpoint on myfce(integer, integer) line 1; select myfce(10,10); dbg \l .. list current line \c .. continue \n .. next stmt \L .. show src \s .. show stack \b .. switch breakpoint \q .. quit function select myvar+10 .. any sql expression variable .. print variable \c myfce - 10 that's all. Maybe I have big fantasy :). Regards Pavel + small argument: if psql support debug mode, I don't need leave my emacs postgresql mode. I don't know exactly how to cause such a connection to get set up, especially remotely. But we should try to think of a way. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Bytecode and virtual machine
Hey Dave, I see a few of the advantages and disadvantages as follows: ADVANTAGES - Faster execution (a single parse/compile) - The ability for companies/people to write PL code and not directly share the source (though disassembly is always possible) - Built-in debugging support (could be added to something like PL/pgSQL, but would work better if built into the system from the ground-up) - Support for PL profiling (great for some of the newbie PL writers and would be useful for finding performance problems when packages come around) - Better/faster exception handling DISADVANTAGES - Generated bytecode would have to be platform independent - Maintenance of the VM itself (how many people would be able to pick up development/support) - Platform support for the VM (not really that big of an issue if it's done right) I have experience writing both stack and register based VMs but I believe that a stack-based VM would be a great way to implement PLs. Sure, a register-based VM sometimes runs faster than a stack-based machine, but it is also a great deal more complex. Just a couple thoughts :) -Jonah Dave Cramer wrote: Jonah, What do you see as the advantages of using a VM and bytecode? Regarding Antlr etal, are there any that generate C code. I am more familiar with the java parsers. If we can't generate C this is probably a non-starter. Dave On 28-Jun-05, at 5:58 PM, Jonah H. Harris wrote: Dave, I lean with you and Tom. While running it over the same libpq protocol would be helpful in some ways, it would have a lot of drawbacks and would really change the function of libpq. I think a separate debugging protocol is in order. Also, as far as bytecode comments go, let's separate them from this thread. I have a pretty sweet hand-written stack-based VM that understands PL/SQL, but it's kinda old and written using PCCTS 1.33 (a recursive descent parser). It has compilation, decompilation, and full debugging capabilities. Unfortunately, PCCTS is no longer maintained as Terrence Parr (the originator) has since moved to ANTLR. ANTLR currently does not generate C code although I have done some starting work on it (ANTLR currently generates Python, Java, or C++). I don't suggest we really reuse one of the current VMs as it would require a lot more support and coordination. Let's take the bytecode discussion off this thread and move it to another. There is certainly a good and bad side to using bytecode and I would be glad to discuss it in another thread. Dave Cramer wrote: Pavel, I am in agreement with Tom here, we should use a separate port, and protocol specifically designed for this. My understanding is that this protocol would be synchronous, and be used for transferring state information, variables, etc back and forth whereas the existing protocol would still be used to transfer data back and forth Dave On 28-Jun-05, at 10:36 AM, Pavel Stehule wrote: On Tue, 28 Jun 2005, Tom Lane wrote: Pavel Stehule [EMAIL PROTECTED] writes: What do you think you need for enhanced protocol ? What I need? Some like synchronous elog(NOTICE,''), which can return some user's interaction, if it's possible. I didn't find how I do it with current set of messages. But my knowleadges of protocol are minimal. It'd probably be smarter to manage the debugging across a separate connection, so that you could carry out debugging without requiring sophisticated support for it inside the client program. If it's single-connection then it will be essentially impractical to debug except from a few specialized clients such as pgadmin; which will make it hard to investigate behaviors that are only seen under load from a client app. I don't think it. Debug process halt query process in bouth variants - remote | protocol. Remote debugging has one advance. I can monitor any living plpgsql process, but I have to connect to some special port, and it can be problem. Protocol debugging can be supported libpq, and all clients libpq can debug. But is problem if PostgreSQL support bouth variants? btw: debuging have to be only for some users, GRANT DEBUG ON LANGUAGE plpgsql TO .. For me, is better variant if I can debug plpgsql code in psql console. Without spec application. I don't speak so spec application don't have to exists (from my view, ofcourse). Maybe: set debug_mode to true; -- if 't' then func stmt has src reset function myfce(integer, integer); -- need recompilation create breakpoint on myfce(integer, integer) line 1; select myfce(10,10); dbg \l .. list current line \c .. continue \n .. next stmt \L .. show src \s .. show stack \b .. switch breakpoint \q .. quit function select myvar+10 .. any sql expression variable .. print variable \c myfce - 10 that's all. Maybe
