Hi All,
>Hi Thomas;
>
>Thomas Bocek wrote:
>> I made a little benchmark with the old source and with the new one:
>>
>> old: vga fillroutine ~7 sec
>> new: vga fillroutine ~5 sec
My testing is much similar to Thomas one. The speed has been improved
after I upgraded the kernel.
>>
>> The results aren't exact, because
>>
>> 1. made the test with a stop-watch
>>
>> 2. the old source crashed after 7 sec, and the screen was only 1/5
filled,
>> the new source crashes after the screen is 4/5 filled.
>
The Crash means the VGA class stop filling screen.
What I have done, I have made some changes on Thomas VGA class.
1. I am trying to make generic interface for Graphics Adapator
2. I added some variables after method call.
i.e.
original one : jos.system.machine.write8(0xaffff, 0);
modified one : short temp = jos.system.machine.write8(0xaffff, 0);
After modifying, the VGA can fill up whole screen without any problem. But
the color on the screen are same color of check mark -_-. I will check it
later.
Also, I have made a memfill routine. It can speed up VGA filling much much a
lots.
For the crash(I use old code), I think the problem is stack overflow. Since
the routine got no problem (it can fill up). I have tried to fill up with
different counter value. When more pixels
are filled, it will hangs very easy. If I fill up a few pixels, it got no
problems.
>OK, so if I were to extrapolate, the old one would finish in 35 seconds
>(barring a crash - HA), and the new one would finish in about 7 seconds
>(barring a crash), right? So, this means we've speeded up the
>calls-to-native code about 5 times, eh? If so, is performance creeping
>into the "acceptable for now" range (At least, until we do the
>JavaOS-style memory classes -- I'm also curious as to why the write32
>stuff is SLOWER -- can you try that one, too?)? If so, is the
>memory-management stuff now the hottest fire?
>
>With respect to the crash:
>
>(1) When my version hangs after displaying the checkmark, is that the
>crash's failure mode? I mean, is this the same "crash" you're getting?
>If so, I can try and debug it.
>
>(2) Do you think it would help if I wrote something that, in the case of
>a detectable crash, reset the VGA display to text mode and spat out some
>debugging info? (Our own little BSOD! What color should I make the
>screen?) I could print out:
>(a) a diagnostic string
>(b) the native-code stacktrace (with "nm" you could see where in the JVM
>we were)
>(c) and maybe some other Java stuff (I'd have to think about how to do
>this, and fit it on one screen -- there could be quite a few Java
>threads -- too many to fit on one screen)
>We don't have enough of a console/GUI/Window Mgr for me to do anything
>else, right?
for debugging, I think we should modified VGA Class to be a Graphical
Console.
(Draw Characters pixel by pixel like Linux Frame Buffer Console). Then we
can
print debugging information on screen.
>Again, thanks for the help -- I appreciate how, er, hostile the
>debugging environment is at this point in time! I shall endeavor to
>make it less so.
>
>-jm
Regards,
Hilary
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
