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@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