From: Godmar Back (gback@cs.utah.edu)
Date: Sun Oct 18 1998 - 17:30:54 EDT
Hi,
I was wondering if others have also problems accessing cvs.transvirtual.com.
This is the situation for me since Friday:
1 gw-css (155.99.212.126) 0.687 ms 1.120 ms 0.568 ms
2 gw-meb-x (155.99.25.10) 4.237 ms 1.982 ms 0.946 ms
3 155.99.131.73 (155.99.131.73) 1.737 ms 0.877 ms 0.896 ms
4 205.124.0.5 (205.124.0.5) 1.771 ms 1.639 ms 1.611 ms
5 sl-gw3-che-10-0-T3.sprintlink.net (144.224.15.25) 10.530 ms 10.480 ms 11.907 ms
6 sl-bb10-che-0-2.sprintlink.net (144.232.6.221) 10.507 ms 9.972 ms 10.119 ms
7 sl-bb21-stk-1-0.sprintlink.net (144.232.8.138) 32.111 ms 32.503 ms 32.415 ms
8 sl-bb23-stk-8-0.sprintlink.net (144.232.4.110) 32.906 ms 32.400 ms 32.186 ms
9 sl-bb10-sj-6-0.sprintlink.net (144.232.8.193) 33.887 ms 33.893 ms 35.457 ms
10 sl-gw2-sj-0-0-0-155M.sprintlink.net (144.232.3.38) 36.322 ms 39.629 ms 35.394 ms
11 144.228.111.6 (144.228.111.6) 35.989 ms 36.614 ms 36.233 ms
12 core1-hssi11-1-0.san-francisco.best.net (206.86.228.90) 37.990 ms 37.874 ms 37.471 ms
13 surf-T1-gw.san-francisco.best.net (140.174.75.2) 50.109 ms 47.878 ms 47.419 ms
14 * * *
15 * * *
Also:
Archie, could you please make the output of ThreadLocalTest deterministic?
You cannot not rely on t1 executing before t2 if you create and start
them as t1.start() t2.start(). In fact, this test is now failing for me
because between thread 3 and 4, 4 is started first, then 3, which is contrary
to what the given output is. Note that that's not the problem that
can be twiddled with by changing the sleep parameter.
On a more positive note: I followed Tim's suggestion and implemented
precise heap collection for ordinary objects. It is at a point where it
recompiles itself and passes the tests. The number of lines added is
also rather small. I have not tested it for objects with more than 31
references. I also have not measured how much that will (hopefully)
speed up gc, but I'll do that as soon as cvs.transvirtual.com is back.
I also have not tested it on the m68k, although I think I took its
half-word alignment into account.
I am creating bitmaps for every class that describe the layout of an
object of that class. On the x86, where void* are always aligned at 4byte
boundaries, these bitmaps are 1/32 the size of an object. On machines
where void* are half-word aligned, they're 1/16. That's of course per
class instance, not per object instance. I use a dynamically allocated
(gc_malloc_fixed) array of ints for now.
When walking an object, I look up the bitmap through the class pointer
and walk the bitmap, shifting it left. While I don't use the superfastest
implementation (I think the x86 even has an instruction to find the highest
bit in a word) -- this can be optimized -- I at least bail if no one bits
are left. Feel free to optimize that.
If a bit is set, I can omit making sure that I'm holding a pointer to an
object, i.e., the lookup in the hashtable is no longer necessary. Instead,
I mark the object directly. This leads to the problem of storing non-objects
in objects. Here is my suggestion: let's store all non-objects as references
to kaffe.util.Ptr. This is already the case in the thread libraries as well
as in the awt (correct, Peter?); I changed java.lang.Throwable to put its
backtrace in a kaffe.util.Ptr as well (instead of a java.lang.Object, as it
was before --- btw, this needs to be declared transient.)
Then, I handle fields of type kaffe.util.Ptr such that I clear the corres-
ponding bit. That is, the gc will not mark the objects referenced.
Does that sound okay to you? I.e., do you know of a situation where a
kaffe.util.Ptr is used to point to an object that should be marked
by the garbage collector? I hope we're in agreement that doing so
would be wrong; otherwise, we need to come up with some other agreement
as to how to identify slots in objects that shouldn't be followed.
Let me know what you think.
Since 1.0b2 is out, I would like to check that stuff in and give other
people a chance to test it.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:00 EDT