Changeset: 55585b20956e for MonetDB
URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=55585b20956e
Modified Files:
gdk/gdk_bat.mx
gdk/gdk_bbp.mx
gdk/gdk_posix.mx
gdk/gdk_relop.mx
gdk/gdk_utils.mx
Branch: default
Log Message:
Documentation changes, removing MIL stuff
This is a small list of MIL references that can be removed.
The batStamp was used in the MIL interpreter, it is unclear
we use/need it any further.
diffs (216 lines):
diff --git a/gdk/gdk_bat.mx b/gdk/gdk_bat.mx
--- a/gdk/gdk_bat.mx
+++ b/gdk/gdk_bat.mx
@@ -694,25 +694,21 @@
header and id). This is indicated by the parameter (writable = FALSE).
In other cases, we really want an independent physical copy (writable = TRUE).
-Note that in the MIL interpreter (as opposed to the C/C++ GDK API), the result
-of MIL-copy() will by default be BAT_READ, the default mode for all new BATs.
-However, changing the mode to BAT_WRITE will be a zero-cost operation if the
-BAT was copied with (writable = TRUE), such as done by MIL-copy().
+Changing the mode to BAT_WRITE will be a zero-cost operation if the
+BAT was copied with (writable = TRUE).
@end itemize
In GDK, the result is a BAT that is BAT_WRITE iff (writable == TRUE).
-NEW: there is now a special parameter setting (writable == 2), which does
create
+There is a special parameter setting (writable == 2), which does create
an independent BAT (not a view that shares the same heaps), however tries
to share VM heap resources using copy-on-write maps. Note that the result of
this is a read-only BAT (BAT_READ). The copy-on-write VM tricks can be used,
-however, to isolate these copies from changes in the parent.
+ to isolate these copies from changes in the parent.
In these cases the copy becomes a logical view on the original, which ensures
that the original cannot be modified or destroyed (which could affect the
shared
heaps).
-This new mode is used by the XQuery isolation mechanism and is available in
MIL
-as rcopy().
@{
@c
int
@@ -2719,7 +2715,7 @@
Note that this code is not about making heaps mmap-ed in the first place.
It is just about determining which flavor of mmap should be used. The
-MIL/MAL user is oblivious of such details.
+MAL user is oblivious of such details.
The route for making heaps mmapped in the first place (or make them no
longer so) is to request a mode change with BATmmap. The requested modes
@@ -3392,7 +3388,7 @@
We also insert a debug statement triggered with BATDEBUG (mask 32)
that displays the size of the hash table used. We chose BATDEBUG because
-that also gives the best overview of MIL execution - necessary
+that also gives the best overview of program execution - necessary
for determining which algebra commands set properties sub-optimally.
@{
@c
diff --git a/gdk/gdk_bbp.mx b/gdk/gdk_bbp.mx
--- a/gdk/gdk_bbp.mx
+++ b/gdk/gdk_bbp.mx
@@ -2020,7 +2020,7 @@
/*
@-
The @%BBP_ref@ contains the amount of live references to a BAT.
-These might be in recursive BATs, C or MIL variables. The count is
+These might be in recursive BATs, C or MAL variables. The count is
incremented with @%BBPfix@ and decremented with @%BBPunfix@.
@h
*/
@@ -3122,7 +3122,7 @@
@{ var t := time(), i := 0; while((i :+= 1) < 100000) bat(int,int);
print(time() - t); @}
[ 847 ]
-so with caching *some* MIL programs can be nearly twice as fast (optimized
compile),
+so with caching *some* programs can be nearly twice as fast (optimized
compile),
though I expect the gains to be smaller in general.
@{
@c
diff --git a/gdk/gdk_posix.mx b/gdk/gdk_posix.mx
--- a/gdk/gdk_posix.mx
+++ b/gdk/gdk_posix.mx
@@ -2126,7 +2126,7 @@
@}
@+ Memory fragmentation monitoring
-On 32-bits systems, Monet's aggressive use of virtual memory may bring it into
+On 32-bits systems, MonetDB's aggressive use of virtual memory may bring it
into
trouble as the limits of what is addressable in a 32-bits system are reached
(an 32-bits OS only allows 2 to 4GB of memory to be used). In order to aid
debugging
situations where VM allocs fail (due to memory fragmentation), a monitoring
@@ -2137,9 +2137,9 @@
@table @samp
@item 0-9
thread stack space of thread <num>
-@item B
+@item H
in use for a large BAT heap.
-@item b
+@item h
free (last usage was B)
@item S
in use for a malloc block
@@ -2153,10 +2153,6 @@
in use as memory mapped region
@item m
free (last usage was M)
-@item C
-in use as MIL context buffer
-@item c
-free (last usage was C)
@end table
The MT_alloc_printmap condenses the map by printing a char for each MB,
@@ -2199,7 +2195,6 @@
'p', "0x00F2BD16", "free (last usage was P)"}, {
'M', "0x00959516", "in use as memory mapped region"}, {
'm', "0x00CEDC16", "free (last usage was M)"}, {
- 'C', "0x004EFDC7", "in use as MIL context buffer"}, {
'c', "0x00FFFD2D", "free (last usage was M)"}, {
0, "0x00FFFDFE", "free"}
};
diff --git a/gdk/gdk_relop.mx b/gdk/gdk_relop.mx
--- a/gdk/gdk_relop.mx
+++ b/gdk/gdk_relop.mx
@@ -1262,7 +1262,7 @@
}
@-
-This routine does the join optimization. TODO: it should be expressed in MIL.
+This routine does the join optimization.
@c
static BAT *
batjoin(BAT *l, BAT *r, BUN estimate, bit swap)
@@ -1497,8 +1497,7 @@
/* invest in property check, since we cannot easily derive the result
properties,
* but later operations might benefit from / depend on them
- * Disable at runtime via `Mserver --debug=16777216` or
- * `debugmask(or(debugmask(),16777216));` in MIL.
+ * Disable via command line option --debug=16777216
*/
JOINPROPCHK {
if (b) {
@@ -1519,8 +1518,7 @@
/* invest in property check, since we cannot easily derive the result
properties,
* but later operations might benefit from / depend on them
- * Disable at runtime via `Mserver --debug=16777216` or
- * `debugmask(or(debugmask(),16777216));` in MIL.
+ * Disable via command line option --debug=16777216
*/
JOINPROPCHK {
if (b)
@@ -1598,8 +1596,7 @@
/* invest in property check, since we cannot easily derive the
result properties,
* but later operations might benefit from / depend on them
- * Disable at runtime via `Mserver --debug=16777216` or
- * `debugmask(or(debugmask(),16777216));` in MIL.
+ * Disable via command line option --debug=16777216
*/
JOINPROPCHK {
if (bn)
@@ -1710,8 +1707,7 @@
/* invest in property check, since we cannot easily derive the result
properties,
* but later operations might benefit from / depend on them
- * Disable at runtime via `Mserver --debug=16777216` or
- * `debugmask(or(debugmask(),16777216));` in MIL.
+ * Disable via command line option --debug=16777216
*/
JOINPROPCHK {
if (bn)
@@ -2428,7 +2424,6 @@
@-
The BATsemijoin chooses between various alternatives.
-TODO: this should be moved to MIL.
@c
BAT *
@@ -2508,8 +2503,7 @@
}
/* invest in property check, since we cannot easily derive the result
properties,
* but later operations might benefit from / depend on them
- * Disable at runtime via `Mserver --debug=16777216` or
- * `debugmask(or(debugmask(),16777216));` in MIL.
+ * Disable via command line option --debug=16777216
*/
JOINPROPCHK {
if (bn)
@@ -2968,8 +2962,6 @@
@table @code
@item -
printing a multicolumn table to a watching end-user is one such example
-@item -
-the unoptimized [X](bat,bat,..) MIL multiplex construct is another example
@end table
@+ multijoin entry routine
The multijoin will cause a cascade of value_fcn() calls putting
@@ -3186,7 +3178,7 @@
@}
@+ The Matching Algorithm
-In multi-column join, all Monet accelerators are put to use when
+In multi-column join, all MonetDB accelerators are put to use when
equi-lookup is done on a number of head columns. In order of
preference, it:
diff --git a/gdk/gdk_utils.mx b/gdk/gdk_utils.mx
--- a/gdk/gdk_utils.mx
+++ b/gdk/gdk_utils.mx
@@ -1256,8 +1256,7 @@
* To avoid performance penalty in the "production version",
* we only do this in debugging/development mode (i.e.,
* when configured with --enable-assert).
- * Disable at runtime via `Mserver --debug=33554432` or
- * `debugmask(or(debugmask(),33554432));` in MIL.
+ * Disable at command line using --debug=33554432
*/
DEADBEEFCHK memset(s, 0xDB, size - (8 + (size & 1))); /*
0xDeadBeef */
#endif
_______________________________________________
Checkin-list mailing list
[email protected]
http://mail.monetdb.org/mailman/listinfo/checkin-list
