From:	SMTP%"leichter@lrw.com"  4-MAR-1995 08:56:28.95
To:	EVERHART
CC:	
Subj:	Re: Boehm GC for OpenVMS AXP

From: Jerry Leichter <leichter@lrw.com>
X-Newsgroups: comp.os.vms
Subject: Re: Boehm GC for OpenVMS AXP
Message-ID: <9503040209.AA07925@uu3.psi.com>
Date: Fri,  3 Mar 95 21:02:50 EDT
Organization: Info-Vax<==>Comp.Os.Vms Gateway
X-Gateway-Source-Info: Mailing List
Lines: 60
To: Info-VAX@Mvb.Saic.Com

	...I am indeed interested in pursuing this, as well as looking into
	accessing dirty page information from the VM system in order to enable
	incremental collection.  The gist of several responses I have received
	is  that this can be done by walking some internal VMS data
	structures, but  that there's no API for it and it has to run in
	kernel mode (or the VMS  equivalent thereof).  What's worse, these
	data structures are apparently  processor-dependant (ie. differ
	between AXP and VAX).

There's an undocumented, unsupported system service that provides this
information:  $GETPTI (Get Page Table Information).  It's not even mentioned
in the Internals and Data Structures book - I found it in the listings once, a
couple of versions back.  Here's the header from it, taken from LIB.REQ on
a VMS V5.5-2 system:

!   $GETPTI
!
!     Get Page Table Information
!
!      $GETPTI  [inadr],[retadr],[acmode],[mask],[pagcnt]
!
!      inadr    = address of two longwords containing starting
!       and ending virtual address to operate on
!
!      retadr   = address of two longwords into which starting
!       and ending address of pages operated on is returned
!
!      acmode   = access mode against which ownership is checked
!
!      mask     = mask of page table information control bits
!
!      pagcnt   = minimum page count
!

I have no idea what this does!  You'd have to check the VMS listings.  I
suspect the call may exist for the Debugger, which changes the protection
on pages to implement watchpoints.  It may be used elsewhere, for all I
know.

			       I'm not too  awfully concerned about VAX
	support myself, but it seems a shame to  gratuitously break it.  And
	besides, I have no idea what it takes to  persuade VMS to let me
	frolic around in "P1 space".

Appropriate privileges.  You'd want to do this using a user-defined system
service.

	The shared library problem exists in Unix, too, and the collector has
	provisions for registering any arbitrary number of "root segments" to
	scan if the information can be gotten from the OS.  In practice,
	however, it is often not necessary for the collector to be so
	cautious-- at least with system-supplied shared libs which aren't
	taking advantage of GC anyway.  So long as a little care is taken not
	to have a reference held in the data segment of the shared lib be the
	only "live" reference to a GC-allocated object, there's no problem.
	Things like strtok() can be hazardous, for instance.

Also, as I pointed out in a previous message, the standard I/O system.

							-- Jerry
