thawkins / strongtalk Goto Github PK

Processes are not getting unregistered or GCed!

"Random test" crashes (with an access violation) deterministically
when the compiler is enabled. A problem with floats ?

Symptom: out-of-memory commit error; the tenured object space just grows
and grows until it crashes, without ever GCing.

The current command line debugger isn't easy to use.

If printing a value (evaluating #printString) generates an error, then the
system will attempt to show a stack trace, and when evaluating the value,
it's trigger the error ... and creates new processes over and over

There are many ways to provoke this bug. For instance, you can implement
#printString on Test

Test>>printString

  ^1+'a' "this obviously fails"

in a workspace, "Test new", showIt will trigger the bug

Strongtalk entities like classes have version number information in them,
using $Revision:$.  Check to make sure that that works with Subversion, and
fix it if necessary.

Right now categories and methods are written in hash order, which will
interfere with the repository diffs.  They need to be written in sorted
order, so that if methods are added, removed, etc, a reasonable diff
would result.

The VM is not internally multi-threaded.  

This is a very big project, and especially needs extremely robust testing.

Fileouts, at least when filing out the world, or groups of classes, contain
varying numbers of spurious duplicate definitions.  The same definition can
appear consecutively many times; the number isn't constant!

Currently, compilation is triggered by an invocation counter reaching a
constant limit.  A feedback mechanism that adjusts that limit dynamically
based on profiling to compute the ratio of the time spent in compiled to
interpreted code, would be better.

Introducing some basic strongtalk maths: 

1'836'311'903 + 2'971'215'073 = 512'559'681

or maybe not.

I found it while i was toying around, running some smalltalk code (which is
basically a translation of a ruby snippet i read), and wondering if it
would work with large integers flawlessly (i'm afraid it does not)

|x| x := 0 ,, 1.
1 to: 50 do: [ :i | "too lazy to write timesRepeat: ..."
  Transcript print: x at2; cr.
  x := x at2 ,, (x at1 + x at2)
].

i ran this with the compiler off btw (not that it matters, LargeIntegers 
are dealt with by primitives anyway)

[ot ps: when is the wiki going to appear ? wasn't it "Real Soon Now" last
month ? :)]

When filing out code subsets from a Hierarchy browser, a file is produced
that appears to not file-in correctly.  There appears to be some kind of
forward referencing problem for classes.  

Also, this feature files out into one big file, but for source code control
we would like this to split each class/entity into a separate file. 
Perhaps we should simply not use this feature for project file-out, since
projects can contain top-level entities that aren't classes, so they won't
show up in the Hierarchy browser anyway.  

Perhaps what is needed is a new kind of 'Project' browser, that shows a
hierarchy browser for the classes, and lists other entities in some kind of
list, all in one window.

The code cache (the area where compiled code is placed) can neither grow
nor compact, and obsolete compiled code just accumulates in it.  When it
fills up, the system just crashes.

In practice this is a very minor problem, since Strongtalk generates only
small amounts of compiled code, and the code cache size can be changed in
the initialization file.  In practice, I don't think we have ever seen this.

While this might be a fair amount of work, a much simpler fix that would
prevent this from crashing the system would be to simply deoptimize all
active compiled contexts, and then just flush the entire code cache, which
would then quickly rebuild itself.  As long as the working set of code is
smaller than the code cache size, and this doesn't happen too often, that
should work fine.

Something to investigate:

Mixin Gub, class variable Test
   accessor methods for Test (inst or class)
Foo subclass of Gub |> Object

accessors are not understood on Foo or Foo instances.

The primdeffilter script source code was not released by Sun as part of the
original source code, and needs to be reconstructed.  It is needed whenever
a primitive is added or a primitive definition is changed.  This is a
simple script that processes .hpp files.  For description of what it does
please see http://code.google.com/p/strongtalk/wiki/Building

Currently, the UI shows only the 16 system colors.  All the code for 32bit
color and palette management is apparently in place in the system, yet
still only 16 colors show up.

A possibly related oddity is that dialog boxes are the 'old-style' pre-XP
Windows dialogs.  Maybe these anachronisms are related to the fact that we
are running as a console application, or perhaps we are linking to old
C-style libraries, rather than newer COM libaries, causing the program to
run in some kind of 'compatibility' mode.

This is probably a very large task.  

The primary reason for doing this would be the potential for supporting
64-bit (62-bit tagged) Doubles as immediates, so real number crunching
could be done in Smalltalk.  An investigation should be made first into
whether low-bit tagging will work for the IEEE 64-bit format.

Major areas this will affect:
    - object layout, header format
    - generated machine code
    - heap management

What steps will reproduce the problem?
1. Download and compile Strongtalk according to readme.txt
2. Verify sources are present for stongtalk-side compile
3. Verify debugging switches point to correct .strongtalkrc (interpreter 
only)
4. run test.bat (which runs test.dlt)

What is the expected output? What do you see instead?
Access violation occurs during phase 3 of GC. Appears to be attempting to 
copy beyond the end of the space.

What version of the product are you using? On what operating system?
revision 115 on Win XP pentium desktop with Visual Studio C++ Express

Please provide any additional information below.

Currently, the system compiles as a Win32 'console' application.  At the
moment, the console is the only way to debug, so we can't change this yet.
Once we have a graphical debugger working, it needs to be changed to run as
a normal Windows program, and write to a log file instead

Currently, invocation counters for methods and loops increase
monotonically, so that if a program runs long enough, any repetitively
executed code will eventually trip the counter and be compiled.

To solve this, time must be included as a factor, by having a background
process occasionally scale invocation counters down, so that they have to
increase at a certain rate to cause compilation.

This is not generally a problem, and can probably be ignored for a very
long time.  If code-cache flushing is implemented to just discard all
compiled code and begin optimizing again when the code cache overflows,
then this can probably be ignored indefinitely.

- define:
! (Delta mirrorFor: #Test) classSide methodsFor: 'toy benchmarks' !
foo

| p1 p2 |
p1 := 234 @ 56.
p2 := 524 @ 766.
^ Time millisecondsToRun: [ 
10000000 timesRepeat: [ p1 + p2 ]
]! !

- Then evaluate "Test foo".  On the second evaluation (when a fully
compiled version of the method should first be used), a stack overflow
occurs.  The process stops, but the VM continues to run.

An wxWidget port would be ideal, because we could do it once and get a UI
that should be very portable.  If wxWidgets turns out not to be the right
option, the alternatives would be:

- write Strongtalk portable versions of the native widgets and dialog boxes.
  This could be a first step, with native widgets coming later.  The GDI
  level interface could either be ported, or a portable bitblt version
  written instead for even more minimal host dependence.

- just port to the native GUI.

To enable us to manage Strongtalk source code in Subversion, we need to be
able to write out library subsets as a group, with each top-level entity in
a separate file.  This can be done for the whole system by
#fileOutWorldToFile:, but people need to be able to work on library
subsets, so as an initial hack I would like to produce a method like
#fileOutWorldToFile: that takes a predicate that determines which classes
are included in the fileout.  Something like 
   #fileOutMatching: pred <[Class,^Boolean]> toFile: <FilePath>

To reproduce: start Strongtalk, launch Hierarchy Browser on Visual, and
"Typecheck all Classes".  Various symptoms of a VM crash appear, either an
actual crash, or hardcode boolean error message window, etc.

Currently when a method is compiled, active contexts are not updated, so
the compiled version is only used for subsequent calls.

This is a big job.  It might not be necessary for a long time, since in
practice it affects only the very rare performance critical inner-loops
that run for a long time, only once.  It is unnoticeable in practice most
of the time.  The one annoying place this often shows up is when newbies
try to run a micro-benchmark just once, or only from a doit.

Several operations appear to take far too long when the system is built now
using open source.  Two things that appear to have around a 10x slowdown!:

- reading the bst file
- running Mandelbrot with optimized floats

However, many other things appear to be about the same speed, so something
is mysterious.  Aligment problems?

Bulk one-way become implementation, which atomically maps all references to
a set of object references to a set of replacement objects.  This is not
required to be a fast operation.

This is needed for class reshaping and other development environment uses.

This is probably a pretty big task.

- Turn off compilation by setting "-UseRecompilation" in .strongtalkrc file.

- file in:
! (Delta mirrorFor: #Test) classSide methodsFor: 'toy benchmarks' !
p1: p1 p2: p2

    ^p1 + p2! !

- then evaluate 

  ^Test p1: 234 @ 56  p2: 524 @ 766

the process crashes (but Strongtalk keeps running) with a "Context for
non-local return does not exist"

This happens in both the 1.1.2 release, and in the current build.

shifts left!

The problematic areas are likely to be:
    - calling conventions/spaghetti stack support
    - memory management
    - thread management

Right now all source files have a $revision$ string, from the days of CVS.
 Under subversion these don't make since, since the revision number is for
the whole system, not per-file, and modifying the file per-revision messes
up other things like diff detection anyway.

So these need to be removed.  However, since that would require modifying
thousands of files and the repository would then have space problems, we
should probably defer this until space isn't a problem anymore.

What steps will reproduce the problem?

1. Open System Monitor
2. Close System Monitor
3. Repeat 

What is the expected output? What do you see instead?

The Strongtalk environment crashes with an access violation error

What version of the product are you using? On what operating system?

R162; Windows Vista 64 bit.

Please provide any additional information below.
If you open and close the System Monitor example a few times it often 
crashes the environment.
I think this is due to the update process sending an invalidate message to 
a window that has been closed; this leads on to an access violation when a 
rectangle that no longer exists is updated.  System Monitor can be made 
less crashprone by checking to see if the applications top level window 
visual is not nil prior to invalidating the window.

System does not yet run when compiled under VC++ 8

Many of the core Strongtalk library classes are not yet typechecked
sufficiently.  Some of this work has been done in the past, but the changes
were lost so it needs to be redone.  This will make the typechecker more
useful.

Right now filtering capability in Hierarchy browser is based on comment
labels; also add predicate for filtering on source code group, and use that
as the primary "project" designator.

This is the first baby step to being able to port the system.

We have source code groups (basically projects) associated with top-level
entities.  But there is no way to look at all of the different groups in
one place, or see what exactly is in a group.

It would be really nice to have two more simple browsers:

1) a simple browser that lists all the groups in the image. when a group is
clicked on, launch a group browser for that group.

2) a group browser, which basically holds a hierarchy browser filtering for
the group, as well as a list of all the other (non-class) entities in the
group, so the entire group can be seen in one place.