| From: TLE::GRANIT::GRANIT::MRGATE::"DASMTS::PMDF::zso.dec.com::mvb" "18-Mar-1997 1133 -0500" 18-MAR-1997 11:31:10.43
To: TLE::BRENDER
CC:
Subj: Dynamic Procedure Descriptors
From: NAME: Monty VanderBilt <[email protected]@PMDF@INTERNET>
To: NAME: 'Ronald Brender' <ronald.brender@zko>
Ron,
It's time to open up a discussion about dynamic procedure descriptors in
the notes conference. I would appreciate it you would post the opening
note with some context. I've included some of the details and questions
here. Feel free to rearrange and edit and add however you want. We have
assigned the implementation to Florence Lee, a relatively new developer
at NTSG, who will be working on this full-time under my guidance.
Here are the proposed additions to the NT API to support dynamic
procedure descriptors.
//
// Function table entry structure definition.
//
typedef struct _RUNTIME_FUNCTION {
ULONG BeginAddress;
ULONG EndAddress;
PEXCEPTION_ROUTINE ExceptionHandler;
PVOID HandlerData;
ULONG PrologEndAddress;
} RUNTIME_FUNCTION, *PRUNTIME_FUNCTION;
/* Add a set of dynamic procedure descriptors. The array of procedure
descriptors described by FunctionTable will be copied into an internal
data structure usable by the exception dispatching mechanism. The
FunctionTable entries need not be sorted in any particular order. The
dynamic procedure descriptors will be searched only after a search
through the static procedure descriptors associated with all current
process images has failed.
*/
>VOID
>RtlFunctionTableAdd (
> PRUNTIME_FUNCTION FunctionTable,
> ULONG EntryCount
> );
>
/* Remove a FunctionTable entry previously defined by
RtlFunctionTableAdd */
>VOID
>RtlFunctionTableDelete (
PRUNTIME_FUNCTION FunctionTable
> );
Questions:
- What type of PD checking should be performed?
- What if a FunctionTable entries overlaps another procedure descriptor
(static or dynamic)?
- Can the caller-supplied PD specify the Descriptor Type?
- Can the caller-supplied PD specify the Exception Mode bits?
- What fields should be compared to qualify as a match for
RtlFunctionTableDelete? I'm thinking just compare BeginAddress,
EndAddress and ProloqEndAddress
- We are planning on implementing the set of dynamic PDs as a balanced
btree in order to support fast insertion, removal and searching.
Although fast searching isn't necessarily required for exception
dispatching, fast removal requires fast searching capability to find the
matching PD.
- Would it be useful to have RtlFunctionTableQuery()? If yes, should it
only query the dynamic set of PD or the static ones also?
- Would it be useful to have a way to clear out all dynamic PDs such as
RtlFunctionTableDelete( NULL )?
These were your remarks on the intended purpose of dynamic PDs. They
should probably be included in the context for this discussion.
- High performance sort packages
Given a textual (interactively presented?) relational expression, sort a
large data base. For performance, the expression is dynamically compiled to
a call-back routine this is called by the basic sort algorithm.
Characteristics: Single DPD at a time that is added/deleted per sort
request.
- High performance data base queries
Similar to above except the action language is much more general that
just relational predicates.
Characteristics: Single DPD at a time that is added/deleted per request.
- Server versions of above
Single DPD (or small number) *per thread* per request.
- Interactive languages (or incrementally compiled variantions)
Might include JAVA. Modest amounts of code produced "on the fly",
sometimes based on adaptive incremental strategies.
Chararacteristics: Handfuls to a few hundred DPDs that tend to accumulate
overtime, tend to last a while, are not often deleted.
- Debuggers that support "dynamic patching" (breakpoints with associated
actions)
Code can be patched into an image during debugging. For performance,
some or all such patches may be compiled to machine code rather than
interpreted.
Characteristics: Like other interactive languages -- Handfuls (to at most
a few hundred) DPDs that tend to accumulate over time, tend to last a
while, are not often deleted.
General conclusions:
1) For high performance, it is important that addition and deletion
be cheap.
2) Since exceptions are (should be) assumed to be unusual, fast lookup
is less important. That is, maintaining a sorted list is less
important than 1).
3) The number of DPDs active at any given time should be small to modest,
further favoring 1) under the premise that lookups (2) will not be
exorbitant in any case.
RFC-822-headers:
Received: from rust.zso.dec.com by dasmts.imc.das.dec.com (PMDF V5.0-7 #16470)
id <[email protected]> for
[email protected]; Tue, 18 Mar 1997 10:29:26 -0500 (EST)
Received: from ntmail4.zso.dec.com by rust.zso.dec.com
(5.65/DECwest-CLUSTRIX-mwd-12Dec94) id AA26513; Tue, 18 Mar 1997 07:30:32 -0800
Received: by ntmail4.zso.dec.com with SMTP
(Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
id <[email protected]>; Tue, 18 Mar 1997 07:30:31 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
|
| From: MOIRA::BRENDER "Ron 603-881-2088; DTN 381-2088 18-Oct-1996 1520 -0400" 18-OCT-1996 15:23:09.28
To: ORAREP::NOMAHS::NOVA::FISHER
CC: BRENDER
Subj: RE: nt calling standard?
Ed,
Following is the complete set of e-mails as best as I can locate...
Ron
================================================================================
From: GEMGRP::GROVE "Rich Grove" 29-JAN-1996 08:12:26.38
To: BRENDER
CC:
Subj: run-time registration of routines on WNT?
From: RUST::"[email protected]" 26-JAN-1996 16:24
To: 'Rich Grove' <gemgrp::grove>
CC:
Subj: FW: Rtl routine to register a function
Rich,
Neither Kim nor I had a pointer for Dan (the attached mail). Do you?
Thanks,
M
----------
From: [email protected][SMTP:[email protected]]
Sent: Friday, January 19, 1996 6:18 AM
To: [email protected]
Cc: [email protected]
Subject: RE: Rtl routine to register a function
Hi Myles,
I posed this question to Roland but he must have just left on vacation.
His watchmail mention you as a possible contact.
As background you should know that Rdb generates code on the fly and
jumps to it. The person porting this code generation to Alpha NT needs
some info about procedure descriptors in relation to the generated
functions. We have copies of the calling standard and we've looked
at the Visual C++ on-line docs. If you could point us in the right
direction I'd appreciate it.
Thanks,
..Dan
From: NOVA::NOVA::FISHER "pls rep to '[email protected]' 16-Jan-1996
0658" 01/16/96 07:06:29
To: STOCKS
CC: FISHER
Subj: Rtl routine to register a function
In order for unwind to occur properly in a routine which is called
by a gen'd code routine, the unwind will have to be able to figure
out what the epilog of the gen'd code routine is. I have not seen
any documentation of any routines which can be used to tell NT
where the procedure descriptors are for gen'd routines. I have seen
the documentation for RtlLookupFunctionEntry.
Do you know of any such routines?
ed
================================================================================
From: GEMGRP::BRENDER "Ron 603-881-2088; DTN 381-2088 29-Jan-1996 0824 -0400" 29-JAN-1996 08:30:01.84
To: TVB
CC: BRENDER
Subj: WNT Rtl routine to register a function
Tom,
Once upon a time, way back in the early days of the WNT calling standard,
we included proposed routines to be used to "register" run-time generated
routines to the run-time system so that they could be used with full
exception handling support. If I recall correctly, this got dropped for
WNT because MS was not interested. (Have I got this history right?)
Anyway, is there anything of this ilk currently available in WNT? If not,
is this an appropriate time to try and correct that omission? (Since this
is now an Oracle "request", maybe MS will be more interested?)
Ron
--------------------------------------------------------------------------------
From: GEMGRP::GROVE "Rich Grove" 29-JAN-1996 08:12:26.38
To: BRENDER
CC:
Subj: run-time registration of routines on WNT?
From: RUST::"[email protected]" 26-JAN-1996 16:24
To: 'Rich Grove' <gemgrp::grove>
CC:
Subj: FW: Rtl routine to register a function
Rich,
Neither Kim nor I had a pointer for Dan (the attached mail). Do you?
Thanks,
M
----------
From: [email protected][SMTP:[email protected]]
Sent: Friday, January 19, 1996 6:18 AM
To: [email protected]
Cc: [email protected]
Subject: RE: Rtl routine to register a function
Hi Myles,
I posed this question to Roland but he must have just left on vacation.
His watchmail mention you as a possible contact.
As background you should know that Rdb generates code on the fly and
jumps to it. The person porting this code generation to Alpha NT needs
some info about procedure descriptors in relation to the generated
functions. We have copies of the calling standard and we've looked
at the Visual C++ on-line docs. If you could point us in the right
direction I'd appreciate it.
Thanks,
..Dan
From: NOVA::NOVA::FISHER "pls rep to '[email protected]' 16-Jan-1996
0658" 01/16/96 07:06:29
To: STOCKS
CC: FISHER
Subj: Rtl routine to register a function
In order for unwind to occur properly in a routine which is called
by a gen'd code routine, the unwind will have to be able to figure
out what the epilog of the gen'd code routine is. I have not seen
any documentation of any routines which can be used to tell NT
where the procedure descriptors are for gen'd routines. I have seen
the documentation for RtlLookupFunctionEntry.
Do you know of any such routines?
ed
================================================================================
From: MOIRA::BRENDER "Ron 603-881-2088; DTN 381-2088 30-Jan-1996 1055 -0400" 30-JAN-1996 11:09:52.62
To: US2RMC::"[email protected]"
CC: BRENDER
Subj: RE: Run-time registration of routines
Ed,
Once upon a time, there was a proposal to include routines for run-time
registration of run-time generated code in the WNT call standard but it got
dropped because of lack of interest by folks at Microsoft. I have no idea
whether they might be more interested at this time or not...
There is one possibility that might be worth looking at if all you want to
do is have the run-time generated code raise an exception that will be
handled in normal code *and* the run-time generated code is all "leaf routines"
(calls no other normal code).
There is a rule that says that if a PC is not mapped by any code range
discriptor at the time of an exception, then R26 must hold a "return PC"
to a routine that is mapped. So, if the generated code can be arranged to
- leave the return address in R26
(calls to other generated code can use some other register)
- use only temporary (scratch) registers [so all preserved registers stay
unaffected]
- call the generated code thru a jacket routine that assures a "heavy
weight frame" (one that uses a frame pointer) [probably write in C
and use alloca(), so that the unwinder can restore the stack pointer
from the FP value]
- stack can be allocated and used
then I think you should be able to raise an exception via GENTRAP to get out.
(You can't call RtlRaise 'cause you can't call out of the generated code!)
This is a bit off the top of my head, so it needs to be worked thru carefully
if it looks like it might be sufficient for your purposes. But, if you need
more capability then I am afraid you will need to pursue some kind of
enhancement to the base WNT system...
Ron
================================================================================
From: US2RMC::"[email protected]" "EFISHER.US.ORACLE.COM" 30-JAN-1996 12:38:10.35
To: moira::brender
CC: [email protected], [email protected], [email protected]
Subj: Re: RE: Run-time registration of routines
--Boundary-1562509-0-0
That will be a problem for us as well as some other of digital's customers.
Rdb's generated code calls routines which raise exceptions. We will
have to work something out though something much more of a hack might
work for now -- if I had to.
thanks,
ed
--Boundary-1562509-0-0
Content-Type: message/rfc822
Date: 30 Jan 96 11:08:49
From:"Ron 603-881-2088; DTN 381-2088 30-Jan-1996 1055 -0400" <[email protected]>
To: [email protected]
Subject: RE: Run-time registration of routines
Cc: [email protected]
Ed,
Once upon a time, there was a proposal to include routines for run-time
registration of run-time generated code in the WNT call standard but it got
dropped because of lack of interest by folks at Microsoft. I have no idea
whether they might be more interested at this time or not...
There is one possibility that might be worth looking at if all you want to
do is have the run-time generated code raise an exception that will be
handled in normal code *and* the run-time generated code is all "leaf routines"
(calls no other normal code).
There is a rule that says that if a PC is not mapped by any code range
discriptor at the time of an exception, then R26 must hold a "return PC"
to a routine that is mapped. So, if the generated code can be arranged to
- leave the return address in R26
(calls to other generated code can use some other register)
- use only temporary (scratch) registers [so all preserved registers stay
unaffected]
- call the generated code thru a jacket routine that assures a "heavy
weight frame" (one that uses a frame pointer) [probably write in C
and use alloca(), so that the unwinder can restore the stack pointer
from the FP value]
- stack can be allocated and used
then I think you should be able to raise an exception via GENTRAP to get out.
(You can't call RtlRaise 'cause you can't call out of the generated code!)
This is a bit off the top of my head, so it needs to be worked thru carefully
if it looks like it might be sufficient for your purposes. But, if you need
more capability then I am afraid you will need to pursue some kind of
enhancement to the base WNT system...
Ron
--Boundary-1562509-0-0--
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail11.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA20952; Tue, 30 Jan 96 12:26:57 -050
% Received: from inet-smtp-gw-1.us.oracle.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA19805; Tue, 30 Jan 1996 12:15:06 -050
% Received: from erdig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id JAA26142; Tue, 30 Jan 1996 09:13:46 -080
% Received: by erdig1.us.oracle.com (5.65v3.2/37.8) id AA15201; Tue, 30 Jan 1996 12:13:31 -050
% Message-Id: <[email protected]>
% Date: Tue, 30 Jan 1996 12:13:31 -0500
% From: "EFISHER.US.ORACLE.COM" <[email protected]>
% To: moira::brender
% Subject: Re: RE: Run-time registration of routines
% Cc: [email protected], [email protected], [email protected]
% X-Orcl-Application: In-Reply-To:UNX09.US.ORACLE.COM:[email protected]'s message of 30-Jan-96 11:07
% Mime-Version: 1.0
% Content-Type: multipart/mixed; boundary=Boundary-1562509-0-
================================================================================
From: RUST::"[email protected]" 31-JAN-1996 14:34:43.40
To: "'[email protected]'" <gemgrp::brender>
CC: Matt LaPine <[email protected]>,
Myles Connors
<[email protected]>,
Steve Jenness
<[email protected]>
Subj: RE: WNT Rtl routine to register a function
There have been only one or two requests for this since 1993. The
functionality does not currently exist in Windows NT. But this request is a
good enough reason to add it assuming there are no easy work-arounds.
Microsoft will accept it provided the specification is general (common
across all NT architectures) and the requesting application is not a hack in
the first place. Can you answer these:
* Is this intended to work for all supported NT architectures, or is this a
special for Alpha?
* How frequently will a dynamic procedure descriptor need to be created and
destroyed? (10s per second or 1000s?)
* What has been the solution on UNIX platforms?
* How many dynamic procedure descriptors are required at a time? (10s or
1000s?)
* Is the generated code intended to be executed by multiple threads?
* Is there a call to FlushInstructionCache?
* Is the generated code in a multi-process shared region?
* Will the thread that executes the generated code always be the thread that
created the generated code?
* Will the generated functions themselves need exception handlers or is
unwinding through the generated functions the only requirement?
* Is the generated code created in the heap (process shared) or the stack
(thread private)?
* Does the generated code follow the calling standard prologue and epilog
rules for unwinding?
Tom
>----------
>From: [email protected][SMTP:[email protected]]
>Sent: Monday, January 29, 1996 5:31 AM
>To: [email protected]
>Cc: [email protected]
>Subject: WNT Rtl routine to register a function
>
>Tom,
>
>Once upon a time, way back in the early days of the WNT calling standard,
>we included proposed routines to be used to "register" run-time generated
>routines to the run-time system so that they could be used with full
>exception handling support. If I recall correctly, this got dropped for
>WNT because MS was not interested. (Have I got this history right?)
>
>Anyway, is there anything of this ilk currently available in WNT? If not,
>is this an appropriate time to try and correct that omission? (Since this
>is now an Oracle "request", maybe MS will be more interested?)
>
>Ron
>
>----------------------------------------------------------------------------
>----
>From: GEMGRP::GROVE "Rich Grove" 29-JAN-1996 08:12:26.38
>To: BRENDER
>CC:
>Subj: run-time registration of routines on WNT?
>
>From: RUST::"[email protected]" 26-JAN-1996 16:24
>To: 'Rich Grove' <gemgrp::grove>
>CC:
>Subj: FW: Rtl routine to register a function
>
>Rich,
>
>Neither Kim nor I had a pointer for Dan (the attached mail). Do you?
>
>Thanks,
>M
>
>----------
>From: [email protected][SMTP:[email protected]]
>Sent: Friday, January 19, 1996 6:18 AM
>To: [email protected]
>Cc: [email protected]
>Subject: RE: Rtl routine to register a function
>
>Hi Myles,
>
>I posed this question to Roland but he must have just left on vacation.
>His watchmail mention you as a possible contact.
>
>As background you should know that Rdb generates code on the fly and
>jumps to it. The person porting this code generation to Alpha NT needs
>some info about procedure descriptors in relation to the generated
>functions. We have copies of the calling standard and we've looked
>at the Visual C++ on-line docs. If you could point us in the right
>direction I'd appreciate it.
>
>Thanks,
>
>..Dan
>
>From: NOVA::NOVA::FISHER "pls rep to '[email protected]' 16-Jan-1996
>0658" 01/16/96 07:06:29
>To: STOCKS
>CC: FISHER
>Subj: Rtl routine to register a function
>
>In order for unwind to occur properly in a routine which is called
>by a gen'd code routine, the unwind will have to be able to figure
>out what the epilog of the gen'd code routine is. I have not seen
>any documentation of any routines which can be used to tell NT
>where the procedure descriptors are for gen'd routines. I have seen
>the documentation for RtlLookupFunctionEntry.
>
>Do you know of any such routines?
>
>ed
>
>
>
>
>
================================================================================
From: MOIRA::BRENDER "Ron 603-881-2088; DTN 381-2088 01-Feb-1996 0831 -0400" 1-FEB-1996 08:38:14.01
To: US2RMC::"[email protected]"
CC: BRENDER
Subj: Re: RE: Run-time registration of routines
Ed,
Tom Van Baak at DECwest might be able to help you. He is the original
implementer of the WNT Alpha exception handling support so knows it very
thoroughly. He does pose a number of questions -- see forwared message
following.
I suggest you try working directly with him. but I would appreciate being
cc'ed so I can monitor what comes of this (an ECO to the WNT call standard
is one possible component of any new capability).
Thanks,
Ron
--------------------------------------------------------------------------------
From: RUST::"[email protected]" 31-JAN-1996 14:34:43.40
To: "'[email protected]'" <gemgrp::brender>
CC: Matt LaPine <[email protected]>,
Myles Connors <[email protected]>,
Steve Jenness <[email protected]>
Subj: RE: WNT Rtl routine to register a function
There have been only one or two requests for this since 1993. The
functionality does not currently exist in Windows NT. But this request is a
good enough reason to add it assuming there are no easy work-arounds.
Microsoft will accept it provided the specification is general (common
across all NT architectures) and the requesting application is not a hack in
the first place. Can you answer these:
* Is this intended to work for all supported NT architectures, or is this
a special for Alpha?
* How frequently will a dynamic procedure descriptor need to be created
and destroyed? (10s per second or 1000s?)
* What has been the solution on UNIX platforms?
* How many dynamic procedure descriptors are required at a time? (10s or
1000s?)
* Is the generated code intended to be executed by multiple threads?
* Is there a call to FlushInstructionCache?
* Is the generated code in a multi-process shared region?
* Will the thread that executes the generated code always be the thread
that created the generated code?
* Will the generated functions themselves need exception handlers or is
unwinding through the generated functions the only requirement?
* Is the generated code created in the heap (process shared) or the stack
(thread private)?
* Does the generated code follow the calling standard prologue and epilog
rules for unwinding?
Tom
>----------
>From: [email protected][SMTP:[email protected]]
>Sent: Monday, January 29, 1996 5:31 AM
>To: [email protected]
>Cc: [email protected]
>Subject: WNT Rtl routine to register a function
>
>Tom,
>
>Once upon a time, way back in the early days of the WNT calling standard,
>we included proposed routines to be used to "register" run-time generated
>routines to the run-time system so that they could be used with full
>exception handling support. If I recall correctly, this got dropped for
>WNT because MS was not interested. (Have I got this history right?)
>
>Anyway, is there anything of this ilk currently available in WNT? If not,
>is this an appropriate time to try and correct that omission? (Since this
>is now an Oracle "request", maybe MS will be more interested?)
>
>Ron
>
>----------------------------------------------------------------------------
>----
>From: GEMGRP::GROVE "Rich Grove" 29-JAN-1996 08:12:26.38
>To: BRENDER
>CC:
>Subj: run-time registration of routines on WNT?
>
>From: RUST::"[email protected]" 26-JAN-1996 16:24
>To: 'Rich Grove' <gemgrp::grove>
>CC:
>Subj: FW: Rtl routine to register a function
>
>Rich,
>
>Neither Kim nor I had a pointer for Dan (the attached mail). Do you?
>
>Thanks,
>M
>
>----------
>From: [email protected][SMTP:[email protected]]
>Sent: Friday, January 19, 1996 6:18 AM
>To: [email protected]
>Cc: [email protected]
>Subject: RE: Rtl routine to register a function
>
>Hi Myles,
>
>I posed this question to Roland but he must have just left on vacation.
>His watchmail mention you as a possible contact.
>
>As background you should know that Rdb generates code on the fly and
>jumps to it. The person porting this code generation to Alpha NT needs
>some info about procedure descriptors in relation to the generated
>functions. We have copies of the calling standard and we've looked
>at the Visual C++ on-line docs. If you could point us in the right
>direction I'd appreciate it.
>
>Thanks,
>
>..Dan
>
>From: NOVA::NOVA::FISHER "pls rep to '[email protected]' 16-Jan-1996
>0658" 01/16/96 07:06:29
>To: STOCKS
>CC: FISHER
>Subj: Rtl routine to register a function
>
>In order for unwind to occur properly in a routine which is called
>by a gen'd code routine, the unwind will have to be able to figure
>out what the epilog of the gen'd code routine is. I have not seen
>any documentation of any routines which can be used to tell NT
>where the procedure descriptors are for gen'd routines. I have seen
>the documentation for RtlLookupFunctionEntry.
>
>Do you know of any such routines?
>
>ed
>
>
>
>
>
================================================================================
From: MOIRA::BRENDER "Ron 603-881-2088; DTN 381-2088 20-May-1996 0958 -0400" 20-MAY-1996 10:01:36.67
To: RUST::"[email protected]"
CC: BRENDER
Subj: RE: WNT Rtl routine to register a function
Tom,
Just a curiosity question -- was there ever any follow up on this topic
(registering dynamically created functions) or did the whole matter just
get dropped?
I ask because if there is any motion, I'd like to make sure the NT Calling
Standard stays in sync.
Thanks,
Ron
================================================================================
From: RUST::"[email protected]" 20-MAY-1996 10:11:10.27
To: "'gemgrp::brender'" <gemgrp::brender>
CC:
Subj: RE: WNT Rtl routine to register a function
Hi Ron,
There were two independent requests last year. In neither case did they
respond to my questions. So I let it drop.
Last week, however, a third ISV asked about the same thing. They
have been very cooperative and so I plan to develop something for them.
I'll let you know how it goes.
What are you up to these days?
Tom
>----------
>From: brender[SMTP:brender]
>Sent: Monday, May 20, 1996 7:02 AM
>To: "[email protected]"
>Cc: [email protected]
>Subject: RE: WNT Rtl routine to register a function
>
>Tom,
>
>Just a curiosity question -- was there ever any follow up on this topic
>(registering dynamically created functions) or did the whole matter
>just
>get dropped?
>
>I ask because if there is any motion, I'd like to make sure the NT
>Calling
>Standard stays in sync.
>
>Thanks,
>Ron
>
================================================================================
From: GEMGRP::BRENDER "Ron 603-881-2088; DTN 381-2088 20-May-1996 1055 -0400" 20-MAY-1996 11:09:34.17
To: RUST::"[email protected]"
CC: BRENDER
Subj: RE: WNT Rtl routine to register a function
Tom,
Good -- I am pleased to hear that something is finally happening on this.
Seems like it has been needed for quite a while...
As you may recall, we had an interface proposal for this back in the early
days of the NT call standard. Are you thinking to just use that, or do you
have something else in mind?
In any case, I hope you'll post your thoughts and recommendations in the
ALPHA_CALLSTD notes file (start a new topic, of course) so we can all track
and comment on it.
I'll be happy to contribute by working out the detailed textual changes
for the call standard document as such, or you can do that yourself if you
like/prefer.
Looking forward,
Ron
p.s. Well, I'll in still in the GEM group but sorta between projects at the
moment. My work on debugging optimized code has been suspended for a while,
and I would much like to get back to that if the powers are willing. (Working
support is shipping on VMS as of V7, and detailed design for UNIX was just
about done when work was suspended so needs to be completed.) It would be nice
to see the NT community take an interest some day as well -- the GEM part is
98 per cent common across platforms; most of the needed work in is the debugger
with lesser changes needed in related object language aware tools like the
linker, dumpers, maybe most in the likes of OM.
================================================================================
From: MOIRA::BRENDER "Ron 603-881-2088; DTN 381-2088 21-May-1996 1050 -0400" 21-MAY-1996 10:56:23.58
To: RUST::"[email protected]"
CC: BRENDER
Subj: RE: WNT Rtl routine to register a function
Tom,
I happened to be talking to Marty Jack this morning over coffee. He is working
on dynamic ("just in time") compilation of Java byte code into Alpha machine
code and he needs some way to register routines for exception handling as well.
He says porting his stuff from UNIX to WNT should be trivial except for that.
If interested, you could follow up with him at JAMMER::Jack.
Ron
p.s. You may (or may not) remember Marty from when he worked on GEM and
was involved in some of the "NT performance war" work...
|
| A few comments on Monty's implementation sketch in .1.
I am NOT familiar with WNT's exception dispatching and unwinding code
internals. I am familiar with V/V and to a growing extent, D UNIX's.
I think that there is a mismatch between your treatment of
RUNTINE_FUNCTIONs and tables of RUNTIME_FUNCTIONs in the
RtlFunctionTableAdd and RtlFunctionTableDelete routines, and also
between those routines and your derived design goals of fast add and
delete at te expense of lookup speed.
You comment that you plan on copying the array of procedure descriptors
(RUNTIME_FUNCTIONs) into an internal datastructure. I don't see why;
just point to the intact table. For speed of use, particularly finding
what routines are covered by a table, that might put some possible
constraints on the table, particularly that it describe a contiguous set of
procedures. In practice I don't think that is an unreasonable
constraint. I think it rare that one would want to create a single
table describing procedures in disjoint chunks of memory.
Just pointing at the table makes the current RtlFunctionTableDelete
interface adequate. However, if you are really going to copy the
individual RUNTIME_FUNCTIONs into an internal form (later referred to as
a balanced binary tree), I think that RtlFunctionTableDelete becomes
much more difficult to implement, and I think that the current interface
definition is inadequate. Deleting the table when/if the PDs are
entered separately into the tree requires being able to walk the table
(array) passed to ...Delete. There is no count parameter. Also,
keeping the PDs in tables (and not copying the tables) removes your
questions about match criteria for the ...Delete. Match is address
match of the table.
If the tree really is a tree of *tables* instead of a tree of PDs, then
we're really close, and I only ask why copy?
What I am recommending is similar to what DU does for its code range
descriptors CRDs. Your PDs combine DU's CRD and RPD data structures.
We allow multiple procedures to share a RPD, which contains the frame
and prolog information, and distinguish similar procedures through the
CRDs, which is how one does PC lookup.
We track our CRD tables by a private structure called a
code_range_entry:
typedef struct code_range_entry {
pdsc_crd *pbase; //The address of the table being tracked
pdsc_count count; //How many entries in this table
pdsc_address first_addr; //Lowest address covered by this table
pdsc_address max_addr; //First address NOT covered by table
pdsc_address gp; //Used for looking up gp
struct code_range_entry *next;
} code_range_entry;
Lookup, insertion and deleting is relatively fast, and making it be a
balanced tree would make it faster. Note that optimizing for
insertion/deleting makes lookup ina tree no better than a singly linked
unordered list. On average you'll walk half the nodes. We require that
CRDs in a table be ordered, thus we can do a binary search of the table.
However, we make no ordering requirement on the list itself; thus
speeding insertion (and frequently deleting, on a last add, first delete
principle that is similar to what you would see in your database
scenarios. (also, for that scenario, it is likely that the exception
would be arising from that routine.)
If the overwhelming use is for single PD tables, than this is more
memory intensive than managing individual PDs in the tree. However, I'm
not sure that is the case overall, particularly if this starts seeing
widespread Java use.
On to some other of your questions:
What if the DPD overlaps another PD?
Specify that it must describe a disjoint PC range; do not check for it.
No PC should map to two PDs. If your current exception handling scheme
already requires this, ignore this paragraph...
Can a DPD specify the Descriptor Type and Exception Mode bits?
My naive opinion: why not?
What fields should be match fields for ...Delete?
Answered above.
Would RtlFunctionTableQuery() be useful?
What would it query, and what would the lookup key be? If the lookup
key is PC, then you must have it as part of the unwinding/exception
dispatcing code. Otherwise, I'd need to know more of what you're
thinking about.
Would it be useful to have a way to delete *all* DPDs?
In the hour since I first read this question, I haven't been able to
thing of a case where any executing user routine would be within its
rights to delete *all* the DPDs. It just isn't modular. Not even
main() knows about its entire context.
FWIW...
I hope this has been useful.
-Al
|
| My thoughts re the questions in .1 (more general comments at the end):
- What type of PD checking should be performed?
None.
- What if a FunctionTable entries overlaps another procedure descriptor
(static or dynamic)?
Undefined. For subsystem self-protection reasons, we can/should
specify that all static PDs are searched before any dynamic ones.
But beyond that it should be caveate programmer!
- Can the caller-supplied PD specify the Descriptor Type?
Yes.
- Can the caller-supplied PD specify the Exception Mode bits?
Yes.
- What fields should be compared to qualify as a match for
RtlFunctionTableDelete? I'm thinking just compare BeginAddress,
EndAddress and ProloqEndAddress
I agree with Al (see .4) here.
- We are planning on implementing the set of dynamic PDs as a balanced
btree in order to support fast insertion, removal and searching.
Although fast searching isn't necessarily required for exception
dispatching, fast removal requires fast searching capability to find the
matching PD.
See general comments below.
- Would it be useful to have RtlFunctionTableQuery()? If yes, should it
only query the dynamic set of PD or the static ones also?
I don't understand what purpose this would serve. I assume that
RtlLookupFunctionEntry will return the address of either a static
or dynamic entry (as appropriate to the PC), after which "full
knowledge" of the PD is immediately available.
- Would it be useful to have a way to clear out all dynamic PDs such as
RtlFunctionTableDelete( NULL )?
I would hold off on this. It should be easily enough for an
application/subsystem to keep track of any/all PDs that it creates/
adds, and it is not clear that it has any business deleting ones it
did not create/add.
The biggest strategy question would appear to be whether to copy the array
of presented PDs into some internal form (whether same or different) or
whether to use it "in place". Using it in place is clearly fastest to
insert/delete and assuming there are not many such arrays (which I rather
expect), then should not materially hurt lookup performance. In particular,
recall that the lookup will search the static PDs first, so that dynamic
PDs will not even be considered until after it is known that no static PDs
apply (with time proportional to the number of currently active DLLs, right?).
I don't recall what kind of performance characteristics Oracle
(however qualitative) has predicted (number of dynamic PDs, typical
lifetime). Is it their input that is behind your suggestion for
using a internal B-tree representation?
Perhaps a different concern is "safety", especially of the exception handling
code itself, in the face of user errors in the construction of the dynamic
PDs. First of all, these are *user* errors. Second, even the exception
handling subsystem can usefully protect itself and reliably catch any exceptions
that occur while it is active because it remains earlier in the search list
of exception (itself having static PDs). The two data points available,
- Digital Unix, where the analygous code range descriptors are used in place,
and
- OpenVMS, where handlers are inherently and always dynamic,
provide no history/experience that suggest that errors in building PDs are
any more serious to the correctness of an application than all the other kinds
of errors that an application might manifest. I would wager that there will
be far more user bugs in construction of the dynamically compiled code that is
described by the dynmaic PDs rather than the PDs themselves -- and there is
nothing that is going to help check/protect against that!
|