Re: Bytecode and virtual machine - Mailing list pgsql-hackers
From | Jonah H. Harris |
---|---|
Subject | Re: Bytecode and virtual machine |
Date | |
Msg-id | 42C2CEF0.3040308@tvi.edu Whole thread Raw |
In response to | Bytecode and virtual machine (Dave Cramer <pg@fastcrypt.com>) |
List | pgsql-hackers |
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 <stehule@kix.fsv.cvut.cz> 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 >>>> majordomo@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 >>> >> >> >> >> ---------------------------(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
pgsql-hackers by date: