Re: Bytecode and virtual machine

From: "Jonah H(dot) Harris" <jharris(at)tvi(dot)edu>
To: Dave Cramer <pg(at)fastcrypt(dot)com>
Cc: Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, Denis Lussier <denis(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bytecode and virtual machine
Date: 2005-06-29 16:40:16
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hey Dave,

I see a few of the advantages and disadvantages as follows:

- 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

- Generated bytecode would have to be platform independent
- Maintenance of the VM itself (how many people would be able to pick up
- 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 :)


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(at)kix(dot)fsv(dot)cvut(dot)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,
>>>> 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(at)postgresql(dot)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?
> ---------------------------(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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2005-06-29 17:07:10 Re: Proposal: associative arrays for plpgsql (concept)
Previous Message Stephen Frost 2005-06-29 16:31:03 Change Ownership Permission Checks