Thursday, April 18, 2024

Blog List

Posted by at

Oracle AQ Dequeue 'KTC latch subh' Memory Leak and Dequeue Long Running Test

Following previous Blog: "Oracle dbms_aq.dequeue_array Shared Pool "KTC Latch Subh" Memory Leak" (http://ksun-oracle.blogspot.com/2021/11/oracle-dbmsaqdequeuearray-shared-pool.html), we will reproduce another case of AQ Dequeue 'KTC latch subh' Memory Leak test in Orale 19.11 with Patch 31666684, and shows dequeue long (hours) running.

Note: Tested in 19.11 with following DB settings (also reproduced in 19.22. In 19.22, there is no Patch 31666684): 

  Patch 31666684 (Patch Description: MEMORY LEAK KTC LATCH SUBH  ON AQ DEQUEUE)
 
  -- set small shared_pool to observe memory resize between shared pool and buffer cache due to "KTC latch subh"
  alter system set shared_pool_size=1008M scope=spfile;  
  
  -- set 3 subpools in shared_pool
  alter system set "_kghdsidx_count"=3 scope=spfile; 
  
  -- disable autosga to generate ORA-04031
  --alter system set "_memory_imm_mode_without_autosga"=false;


1. Test Setup 



drop type k.t_test_obj force;
					      
create or replace noneditionable type k.t_test_obj is object (id integer, type_id integer);
/  					

begin sys.dbms_aqadm.drop_queue_table(queue_table => 'K.Q_TEST_TAB', force=> TRUE); end;
/

begin
  sys.dbms_aqadm.create_queue_table
  ( queue_table        => 'K.Q_TEST_TAB'
   ,queue_payload_type => 'K.T_TEST_OBJ'
   ,compatible         => '10.0.0'  --'8.1'
   ,storage_clause     => 'nocompress
                           tablespace u1'
   ,sort_list          => 'PRIORITY,ENQ_TIME'
   ,multiple_consumers =>  false
   ,message_grouping   =>  0
   ,comment            =>  'MEMORY LEAK KTC LATCH SUBH AQ test'
   ,secure             =>  false
   );
end;
/

begin
  sys.dbms_aqadm.stop_queue (queue_name => 'K.TEST_QUEUE');
  sys.dbms_aqadm.drop_queue (queue_name => 'K.TEST_QUEUE');
end;
/

begin
  sys.dbms_aqadm.create_queue
  ( queue_name      => 'K.TEST_QUEUE'
   ,queue_table     => 'K.Q_TEST_TAB'
   ,queue_type      => sys.dbms_aqadm.normal_queue
   ,max_retries     => 100
   ,retry_delay     => 2
   ,retention_time  => 604800
   ,comment         => 'AQ Queue Test'
   );
end;
/

begin sys.dbms_aqadm.start_queue(queue_name => 'K.TEST_QUEUE', enqueue => true, dequeue => true); end;
/


create or replace procedure test_enq(p_cnt number := 1, p_sleep number := 0) as
  l_enqueue_options     dbms_aq.enqueue_options_t;
  l_message_properties  dbms_aq.message_properties_t;
  l_message_handle      raw(16);
  l_msg                 t_test_obj;
begin 
  --visibility: 
  --   dbms_aq.immediate: no commit is required, message is enqueued and committed for dequeue immediately in an autonomous transaction.
  --   dbms_aq.on_commit (default): commit is required, message is visibile for dequeue after COMMIT. enqueue session has an open transaction before commit.
  --l_enqueue_options.visibility    := dbms_aq.immediate;
   
  for i in 1..p_cnt loop
    l_msg := t_test_obj(i, 2);
            
    dbms_aq.enqueue(queue_name         => 'K.TEST_QUEUE',
                    enqueue_options    => l_enqueue_options,
                    message_properties => l_message_properties,
                    payload            => l_msg,
                    msgid              => l_message_handle);
    --commit;  -- no commit
    
    if p_sleep > 0 then
      dbms_lock.sleep(p_sleep);
    end if;
  end loop;
end;
/
					
					
create or replace procedure test_deq(p_cnt number := 1, p_dur number := 0, p_sleep number := 0) as
  l_dequeue_options     dbms_aq.dequeue_options_t;
  l_message_properties  dbms_aq.message_properties_t;
  l_message_handle      raw(16);
  l_msg                 t_test_obj;
  l_cnt   number := 0;
begin
  for i in 1..p_cnt loop
    begin 
   	  l_dequeue_options.wait := p_dur;
   	  if p_sleep > 0 then
   	  	 dbms_lock.sleep(p_sleep);
   	  end if;
   	  
      dbms_aq.dequeue(queue_name         => 'K.TEST_QUEUE',
                      dequeue_options    => l_dequeue_options,
                      message_properties => l_message_properties,
                      payload            => l_msg,
                      msgid              => l_message_handle);
            
      --dbms_output.put_line ('id = ' || l_msg.id || ', type_id = ' || l_msg.type_id);
      
      --commit;  -- no commit
      l_cnt := l_cnt + 1;
    exception when others then null;
    end;
  end loop;
	dbms_output.put_line ('l_cnt = ' || l_cnt);
end;
/					        

-- purge queue for repeated test
declare
	po dbms_aqadm.aq$_purge_options_t;
begin
	dbms_aqadm.purge_queue_table('K.Q_TEST_TAB', null, po);
end;
/


2. Test Run


We open 3 Sqlplus sessions.
In SID-1, we enqueue 1e6 messages with commit.
In SID-2, dequeue all 1e6 messages without commit to observe 'KTC latch subh' Memory Leak.
Then in SID-3, dequeue one portion (1e3) of messages to show dequeue long running.


3.1. Queue Filling: SID-1 Enueue with commit 



SQL > exec test_enq(1e6);

    Elapsed: 00:01:55.93
    
SQL > commit;
		
SQL > select segment_name, segment_type, bytes from dba_segments where segment_name like '%Q_TEST_TAB%';

    SEGMENT_NAME         SEGMENT_TYPE            BYTES
    -------------------- ------------------ ----------
    Q_TEST_TAB           TABLE               125829120
    AQ$_Q_TEST_TAB_T     INDEX                   65536
    AQ$_Q_TEST_TAB_I     INDEX                51380224

SQL > select count(*) from q_test_tab;

      COUNT(*)
    ----------
       1000000


3.2. AQ Dequeue 'KTC latch subh' Memory Leak: SID-2 Dequeue without commit 



SQL > select round(bytes/1024/1024, 2) mb, t.* from v$sgastat t where pool='shared pool' and name = 'KTC latch subh';

      MB  POOL         NAME             BYTES
    ----  -----------  --------------  ------
     .04  shared pool  KTC latch subh   46992

SQL > exec test_deq(1e6);

    l_cnt =1000000
    PL/SQL procedure successfully completed.
    Elapsed: 01:26:32.57

SQL > select round(bytes/1024/1024, 2) mb, t.* from v$sgastat t where pool='shared pool' and name = 'KTC latch subh';
                                 
      MB POOL         NAME                   BYTES
    ---- -----------  -------------- -------------
     992 shared pool  KTC latch subh 1,039,969,240
We can list all SGA memory resize operations: 

SQL > select component, parameter, oper_type, initial_size, final_size, final_size-initial_size delta, start_time, end_time 
        from v$memory_resize_ops where parameter in ('db_cache_size', 'shared_pool_size') order by start_time, parameter;     

    COMPONENT              PARAMETER          OPER_TYPE    INITIAL_SIZE       FINAL_SIZE          DELTA  START_TI  END_TIME
    ---------------------  -----------------  ---------- -------------- ---------------- --------------  --------  --------
    DEFAULT buffer cache   db_cache_size      STATIC                  0    2,097,152,000  2,097,152,000  13:46:14  13:46:14
    shared pool            shared_pool_size   STATIC                  0    1,056,964,608  1,056,964,608  13:46:14  13:46:14
    DEFAULT buffer cache   db_cache_size      SHRINK      2,097,152,000    2,080,374,784    -16,777,216  14:31:36  14:31:36
    shared pool            shared_pool_size   GROW        1,056,964,608    1,073,741,824     16,777,216  14:31:36  14:31:36
    DEFAULT buffer cache   db_cache_size      SHRINK      2,080,374,784    2,063,597,568    -16,777,216  14:32:37  14:32:37
    shared pool            shared_pool_size   GROW        1,073,741,824    1,090,519,040     16,777,216  14:32:37  14:32:37
    DEFAULT buffer cache   db_cache_size      SHRINK      2,063,597,568    2,046,820,352    -16,777,216  14:33:41  14:33:41
    shared pool            shared_pool_size   GROW        1,090,519,040    1,107,296,256     16,777,216  14:33:41  14:33:41
    .....                                                                                                          
    shared pool            shared_pool_size   GROW        1,694,498,816    1,711,276,032     16,777,216  15:34:06  15:34:06
    DEFAULT buffer cache   db_cache_size      SHRINK      1,442,840,576    1,426,063,360    -16,777,216  15:36:18  15:36:18
    shared pool            shared_pool_size   GROW        1,711,276,032    1,728,053,248     16,777,216  15:36:18  15:36:18
    DEFAULT buffer cache   db_cache_size      SHRINK      1,426,063,360    1,409,286,144    -16,777,216  15:38:33  15:38:33
    shared pool            shared_pool_size   GROW        1,728,053,248    1,744,830,464     16,777,216  15:38:33  15:38:33
    DEFAULT buffer cache   db_cache_size      SHRINK      1,409,286,144    1,392,508,928    -16,777,216  15:41:14  15:41:14
    shared pool            shared_pool_size   GROW        1,744,830,464    1,761,607,680     16,777,216  15:41:14  15:41:14
    
    88 rows selected.
There are 42 resize operations from 14:31:36 to 15:41:14, each time shift 16MB from DEFAULT buffer cache to shared pool. The memory changes are: 

	shared_pool_size  GRO 1,008M	-> 1,680M
	db_cache_size   	SHR 2,000M  -> 1,328M
	KTC latch subh	          0M  ->	 992M
By the way, we can observe many ORA-04031 errors if disable SGA auto resize with: 

  -- disable autosga to generate ORA-04031
  alter system set "_memory_imm_mode_without_autosga"=false;


3.3. Dequeue Long Running: SID-3 Dequeue


We can see 7 hours long dequeue by: 

SQL > exec test_deq(1e3);

    l_cnt =0
    PL/SQL procedure successfully completed.
    Elapsed: 07:51:02.15
If we trace SID-3, they are all about 'db file sequential read' on file#=3 (UNDO file) to construct CR block of AQ Queue messages. 

PARSING IN CURSOR #139862144662288 len=587 dep=1 uid=0 oct=3 lid=0 tim=25914746826315 hv=3930832701 ad='7f7cb148' sqlid='1y072amp4rgtx'
select  /*+ INDEX(TAB AQ$_Q_TEST_TAB_I) */   tab.rowid, tab.msgid, tab.corrid, tab.priority, tab.delay,   tab.expiration ,tab.retry_count, 
tab.exception_qschema,   tab.exception_queue, tab.chain_no, tab.local_order_no, tab.enq_time,   tab.time_manager_info, tab.state, 
tab.enq_tid, tab.step_no,   tab.sender_name, tab.sender_address, tab.sender_protocol,   tab.dequeue_msgid, tab.user_prop, tab.user_data   
from "K"."Q_TEST_TAB" tab  where q_name = :1 and (state = :2  )  order by q_name, state, priority, enq_time, step_no, chain_no, 
local_order_no for update skip locked
END OF STMT

EXEC #139862144662288:c=12383,e=39484,p=4,cr=55,cu=0,mis=1,r=0,dep=1,og=1,plh=1032419615,tim=25914746866093
WAIT #139862144662288: nam='db file sequential read' ela= 5849 file#=3 block#=621 blocks=1 obj#=0 tim=25914746872095
WAIT #139862144662288: nam='db file sequential read' ela= 5476 file#=3 block#=620 blocks=1 obj#=0 tim=25914746877756
WAIT #139862144662288: nam='db file sequential read' ela= 11281 file#=3 block#=619 blocks=1 obj#=0 tim=25914746889170
WAIT #139862144662288: nam='db file sequential read' ela= 5466 file#=3 block#=618 blocks=1 obj#=0 tim=25914746894797
WAIT #139862144662288: nam='db file sequential read' ela= 5655 file#=3 block#=617 blocks=1 obj#=0 tim=25914746900588
WAIT #139862144662288: nam='db file sequential read' ela= 5374 file#=3 block#=616 blocks=1 obj#=0 tim=25914746906117
WAIT #139862144662288: nam='db file sequential read' ela= 5522 file#=3 block#=615 blocks=1 obj#=0 tim=25914746911793
WAIT #139862144662288: nam='db file sequential read' ela= 5488 file#=3 block#=614 blocks=1 obj#=0 tim=25914746917451
WAIT #139862144662288: nam='db file sequential read' ela= 108815 file#=3 block#=613 blocks=1 obj#=0 tim=25914747026421
Posted by at

Tuesday, April 9, 2024

One Test of Oracle Object Collection MEMBER OF Function

Following previous Blog: Performance of Oracle Object Collection Comparisons - Part1 (http://ksun-oracle.blogspot.com/2016/01/performance-of-oracle-object-collection_13.html), we will make one test of MEMBER OF Method.

Oracle Docu writes:
     The MEMBER [OF] or NOT MEMBER [OF] condition tests whether or not an element is a member of a nested table, returning the result as a Boolean value.

It seems that order method of object type is used in MEMBER OF Function to make direct one-to-one object comparisons.
Therefore, we use order method to record the number of comparisons.

Note: Tested in Oracle 19c and 22c.


1. Test Setup 



drop type t_obj_tab force;
drop type t_obj_varray force;
drop type t_obj force;

create or replace noneditionable package recorder as
  p_cnt number := 0;
end;
/

create or replace noneditionable type t_obj as object (
  p_num number,
  order member function comp (c t_obj) return integer
);
/

create or replace noneditionable type body t_obj as
   order member function comp (c t_obj) return integer is 
   begin 
      recorder.p_cnt := recorder.p_cnt + 1;  -- count the number of calling
      -- for debug
      --  dbms_output.put_line('COMP Debug: p_cnt: (p_num > c.p_num) ? sign = '||recorder.p_cnt||
      --                     ' ('||p_num||' > '||c.p_num||' ?) = '||sign(p_num - c.p_num));
      return sign(p_num - c.p_num);           -- return 1, -1, 0 for bigger, less, equal
   end;
end;
/

create or replace noneditionable type t_obj_tab as table of t_obj;
/

create or replace noneditionable type t_obj_varray as varray(100) of t_obj;
/

drop table test_tab;

create table test_tab (id number, obj_tab t_obj_tab,  obj_varray t_obj_varray) 
  nested table obj_tab store as test_tab_obj_store  
/


create or replace procedure fill_tab(p_rows number := 1000, p_obj_tab_size number := 100) as 
  l_obj_tab       t_obj_tab;
  l_obj_varray    t_obj_varray;
begin
  execute immediate'truncate table test_tab';
  -- If inserting the same l_obj_tab (or same l_obj_varray), Oracle observes the same objects and optimizes (reduce) to one for the same objects.
  --select cast(collect(t_obj(level)) as t_obj_tab) into l_obj_tab    from dual connect by level <= l_obj_tab_size; 
  --select t_obj(level) bulk collect                into l_obj_varray from dual connect by level <= l_obj_tab_size;
  --insert into test_tab select level, l_obj_tab, l_obj_varray from dual connect by level <= l_rows; 
  
  -- Insert 1000 rows, each row has one l_obj_tab and one l_obj_varray with 100 different numbers (values are 1..100)
  -- The first element is always 1, the others (2-100) are sorted by dbms_random.value.
  -- For each row, insert different l_obj_tab/l_obj_varray by dbms_random.value.
  
  dbms_random.seed(31);   -- to make test stable
  for i in 1..p_rows loop
    with sq as (select level+1 id from dual connect by level <= (p_obj_tab_size -1) order by trunc(dbms_random.value(1, p_rows)))
    select t_obj(id), t_obj(id) bulk collect into l_obj_tab, l_obj_varray 
      from (select 1 id from dual 
              union all 
            select * from sq); 

    insert into test_tab values (i, l_obj_tab, l_obj_varray);
  end loop;
  commit;
end;
/

-- exec fill_tab(1000, 100);



create or replace procedure memberof_test (p_size number := 100, p_sign number := 1, p_tab varchar2 := 'varray') as
  l_obj_tab           t_obj_tab    := t_obj_tab();
  l_obj_varray        t_obj_varray := t_obj_varray();
  l_start_time        number;
  l_elapsed           number;
  l_cnt               number := 0;
begin
  select cast(collect(t_obj(p_sign*level)) as t_obj_tab) into l_obj_tab from dual connect by level <= p_size order by level; 
    
  recorder.p_cnt := 0;
  l_start_time := dbms_utility.get_time;

  if p_tab = 'varray' then
    for c in (
        select * from test_tab p 
         where exists
                 (select 1 from table (p.obj_varray) t
                   where t_obj(t.p_num) member of cast (l_obj_tab as t_obj_tab))
    ) loop
      l_cnt := l_cnt + 1;
    end loop; 
  else     
    for c in (
        select * from (select * from test_tab p order by p.id) p
         where exists
                 (select 1 from table (p.obj_tab) t
                   where t_obj(t.p_num) member of cast (l_obj_tab as t_obj_tab))  
                      -- in COMP method, "(c t_obj)" is "t_obj(t.p_num)"; (self t_obj) is from "l_obj_tab"
    ) loop
      l_cnt := l_cnt + 1;
    end loop;
  end if;
  
  l_elapsed := dbms_utility.get_time - l_start_time;
  
  dbms_output.put_line('Selected Rows  = ' || l_cnt);
  dbms_output.put_line('Elapsed(centi) = ' || l_elapsed);
  dbms_output.put_line('Comparisons    = ' || recorder.p_cnt);
  dbms_output.put_line('obj_tab.size   = ' || cardinality(l_obj_tab));
end;
/


2. Test Run


At first, we fill test_tab with 1000 rows, each row has one nested table and one varray of 100 different numbers (values are 1..100).
The first element is always 1, the others (2-100) are sorted by dbms_random.value. 

exec fill_tab(1000, 100);
Then we run test for varray and nested table by using "MEMBER OF" with 10 or 100 elements, once with all positive numbers, once with all negative numbers.
With positive numbers, "MEMBER OF" returns true for first element.
With negative numbers, "MEMBER OF" returns false after going all elements. 

exec memberof_test(10, +1, 'varray');
exec memberof_test(10, -1, 'varray');
exec memberof_test(100, +1, 'varray');
exec memberof_test(100, -1, 'varray');

exec memberof_test(10, +1, 'ntab');
exec memberof_test(10, -1, 'ntab');
exec memberof_test(100, +1, 'ntab');
exec memberof_test(100, -1, 'ntab');


3. Test Outcome


In case of varray, with positive numbers, the number of Comparisons is the same as table rows; with negative numbers, the number of Comparisons is ("table rows" * "varray size" * "number of positive numbers");

In case of nested table, with positive numbers, the number of Comparisons is more than table rows because nested table in each row is physically stored in "test_tab_obj_store" (nested table storage), and its physical sequence is not the same as its logical sequence (one can dump "test_tab_obj_store" data block to check them).

With negative numbers, the number of Comparisons is ("table rows" * "varray size" * "number of positive numbers"); 

SQL > exec memberof_test(10, +1, 'varray');
  Selected Rows  = 1000
  Elapsed(centi) = 16
  Comparisons    = 1000
  obj_tab.size   = 10
  
SQL > exec memberof_test(10, -1, 'varray');
  Selected Rows  = 0
  Elapsed(centi) = 325
  Comparisons    = 1000000
  obj_tab.size   = 10
  
SQL > exec memberof_test(100, +1, 'varray');
  Selected Rows  = 1000
  Elapsed(centi) = 16
  Comparisons    = 1000
  obj_tab.size   = 100
  
SQL > exec memberof_test(100, -1, 'varray');
  Selected Rows  = 0
  Elapsed(centi) = 3174
  Comparisons    = 10000000
  obj_tab.size   = 100


SQL > exec memberof_test(10, +1, 'ntab');
  Selected Rows  = 1000
  Elapsed(centi) = 16
  Comparisons    = 4491
  obj_tab.size   = 10
  
SQL > exec memberof_test(10, -1, 'ntab');
  Selected Rows  = 0
  Elapsed(centi) = 328
  Comparisons    = 1000000
  obj_tab.size   = 10
  
SQL > exec memberof_test(100, +1, 'ntab');
  Selected Rows  = 1000
  Elapsed(centi) = 16
  Comparisons    = 2662
  obj_tab.size   = 100
  
SQL > exec memberof_test(100, -1, 'ntab');
  Selected Rows  = 0
  Elapsed(centi) = 3174
  Comparisons    = 10000000
  obj_tab.size   = 100
Posted by at

In Memoriam of Prof. Niklaus Wirth: One Email on Program Debugging


1. Email Reply from Prof. Wirth 



Sent: Tuesday, August 21, 2007 at 06:49:43 PM GMT+2
Subject: Re: Debugger Help

Dear Mr. Sun,

With your letter you raise an old argument. I doubt that I ever said 
"A good programmer should not use Debugger", 
but rather "A good programmer doesn't need a Debugger". 
This was a bit sarcastic, and it was said in the context of teaching and solving exercises.

What I really meant was that one should strive for careful programming,
where every step is done with the certainty that it is correct,
such that at the end the whole program is correct and no search for errors (debugging) is needed. 
This is quite possible and is the right way to train programmers.

However, when programs become complex, we fail to be sufficiently careful. 
We make errors and must find them. Also this we must learn. But only as a "last resort". 
In general, debuggers have become so sophisticated, that programmers cannot live without them. 
They make debugging so common-place, that nobody even tries to design a program to
be correct from the start. This is why I exaggerated by saying to the students: 
Do try to do without the help of debuggers, at least while solving my simple assignments.

In fact, I believe that the sophisticated tools, along with the very fast processors, 
are largely responsible for the wide-spread replacement
of careful design by trial and error techniques. The latter is believed
to be easier and faster. And sophisticated tools are cheaper than
excellent designers. However, they cannot replace them!

To be fair, we must acknowledge another point. Very few programs are
designed from scratch and are thus in the head of an originator. 
Mostly, programs grow, and programmers extend existing ones. Unfortunately, they
are often poorly documented, sometimes even wrongly documented. 
Then, our work is no longer like "program design". It is rather detecting the
reasoning behind an undocumented text.Then our only resort is inspection and testing. 
Then we must use every tool available to conquer the misery. 
But as always, the sledgehammer must be used only when finer tools fail.

 > 3. An alternative approach not to use Debugger is to insert Printout statements
 > into the programs, and eventually build flags into programs to toggle and regulate
 > the output finesse. How do you think of this practice?
 
I often do this, but remove the "debug outputs" when the problem is found.

 > 4. I read again your 1984 Turning Award Lecture, and found only one place mentioning
 > Debugger: "His efforts (Ken Bowles) to develop a suitable Environment with integrated
 > compiler, filer, editor, and debugger caused a breakthrough:..." This sounds that
 > the Debugger was appreciated.

Yes it was a big part of the success for the UCSD Pascal System. 
Quick turn-around -> quick fixes.

 > Also in your talk with Dr. Carlo Pescio (Published in Software Development, Vol. 5 No. 6, June 1997) 
 > about the 20% / 80% partition of design / debugging time, it seems that
 > Debugger was not excluded from daily programming.
 
I never claimed that the world programs without the support of debuggers.

 > In Oberon, I also heard that both a post-mortem Debugger and a runtime debugging facilities
 > (BlackBox Component Builder) were implemented.
 
Blackbox was designed by a company in Zurich, and they were quite successful with their tools.

I hope this clarifies my points of view about programming with or without debuggers. 

Sincerely yours,

Niklaus Wirth


2. Email to Prof. Wirth 



Sent: Monday, July 30, 2007 at 11:24:11 AM GMT+2
Subject: Debugger Help


Dear Professor Wirth,

My name is Kun Sun, working in a software company with more than 100 developers,
of which many are ETH computer graduates. Recently we have some discussion
on the subject of "Debugger". Some of ETH graduates claim that they do not need
Debugger since Prof. Wirth taught them: "A good programmer should not use Debugger".

I have been involved in the computer field around 25 years, starting from binary programming
to nowadays-symbolic programming, always childishly seeking for the reason.
To this purpose, I would like to have your help on the following points:

1. Why a good programmer should not use Debugger? In which context does it hold?

2. A Debugger (or better called Inspector or Watcher) can reveal the runtime
behaviour of system. In the case of basic (scalar) variables, maybe the
usefulness is not tremendous, but for the composite type, like record, array,
object, XML type, it would be helpful to recognize the inherent state
and detect the side-effect of some code. On the other hand, for the program structure
like: iterative and recursive (specially non tail-recursive), Inspector can aid
in understanding of program logic. Further more, to handle with dynamic code
(program with reflection, indirection, and even string-append generated code),
a Debugger appears to be beneficial.

3. An alternative approach not to use Debugger is to insert Printout statements
into the programs, and eventually build flags into programs to toggle and regulate
the output finesse. How do you think of this practice?

4. I read again your 1984 Turning Award Lecture, and found only one place mentioning
Debugger: "His efforts (Ken Bowles) to develop a suitable Environment with integrated
compiler, filer, editor, and debugger caused a breakthrough:..." This sounds that
the Debugger was appreciated.

Also in your talk with Dr. Carlo Pescio (Published in Software Development, Vol. 5 No. 6, June 1997) 
about the 20% / 80% partition of design / debugging time, it seems that
Debugger was not excluded from daily programming.

In Oberon, I also heard that both a post-mortem Debugger and a runtime debugging facilities
(BlackBox Component Builder) were implemented.

Best regards,

Kun Sun
Posted by at
Subscribe to: Posts (Atom)