Re: 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 <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,
>>>> 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(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?
>>
>> 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