As we all know, cpuidle canāt save any power if cpu is wakeup frequently during idleā cpu doesnāt have chance to go to deep sleep. So to get power savings, besides cpuidle support, we must remove those unnecessary wakeups.
During the bonding period, I added some code to dump system timer wakeup events and found the cpu wakeup during idle is too high, ~550 wakeup/s. Then with the help of KDL, I found one obvious wakeup source ā the schedulerās quantumTimer. But I canāt understand its duty. Then with the help of Axel, I catch its functionality and meaning. Axel also gave one suggestion:disable the timer for idle thread. So the only one patch during my bonding period was submitted and latter was merged by my mentor tqh. By my test, this patch removes ~41% unnecessary wakeups during idle.
Over the community bonding period Iāve been researching the best approach to take for the AWT port, and over the past week or two Iāve been implementing a prototype.
AWT demands the implementation of a number of āpeersā for buttons, text boxes, etc. which have historically been implemented using the native widgets of the underlying platform. The time taken to implement and maintain these peers is quite large, especially considering that these AWT widgets have been superseded by Swing and are rarely used anymore.
An alternative implementation approach used by the Caciocavallo project involves providing native heavyweights for the windows and views and then calling on Swing to provide drawing and event handling for the various widgets. This eases the porting of AWT and reduces the amount of platform-specific code to maintain. This approach is also taken by the recent port of OpenJDK to Mac OS X.
Over the past week or two Iāve written a prototype implementation using the Caciocavallo Swing AWT peers. Itās very incomplete thus far, but Iāve got drawing working pretty reliably, as well as some event handling including mouse input. Screenshot below the fold.
Just saw on Haikuware that there is another GUI for setting a decorator. First, Iām happy that people are actually using this āhiddenā functionality to write custom applications. However, after Alpha 3 I changed the decorator API which broke all other decorators.
The reason for that is that the stacking feature of Stack and Tile is now integrated into the decorator. In other words all decorators have to support Stack and Tile now! Stacked windows share the same decorator and the decorator is responsible to display multiple tabs. This has the advantage that the developer has more freedom to design the appearance of the tabs. Furthermore, tabs can be arranged more flexible. For example, you can add the stacking features to the Amiga decorator by drawing the tabs beside each other into the title bar.
Having started my PhD at the University of Auckland two years ago I think itās time to provide a brief overview for the Haiku community about what I am doing here. Since a complete overview would result in a pretty big post I intend to split it into multiple smaller posts. Fingers crossed that I remain motivated enough to keep writing :).
The topic of my PhD is āUser Interface Customizationā and covers three aspects. First, customization in the large which targets the management of multiple windows of different applications using Stack and Tile. Secondly, customization in the small. Here I take a look at how customization can be effected within an application, especially how the user can change the layout of an application at runtime, e.g. to optimize an application for his special use-cases. Finally, Iād like to take a look at how far it is possible to also let the user customize the functionality of an application, e.g. connect a button click event to a new component that plays a sound effect to emphasize the importance of the button clicked event.
With one big push the work I did on ALM (Auckland Layout Model) while I was at the University of Auckland is now in the main Haiku repo. In short, Iāve brought the BALMLayout up to standard with the other layouts in Haiku, and added some new features as well.
I started to work on the xHCI driver in late 2011: I found the code provided during the Google Summer of Code 2011 was promising and didnāt get its full exposure. Another reason was Haiku Inc. provided me with hardware I needed to mentor the xHCI project by Jian Jiang.
The goal of this project is to create code for resizing a BFS volume in a safe manner, through the existing volume resizing interface. At first utilized with a command line tool, and toward the end of the summer hopefully integrated with DriveSetup if time allows.
During the community bonding period, I want to get my development environment set up, and gain some basic familiarity with writing to disk. To accomplish that, Iām going to write a small program that can read and write sectors to the hard drive.
My GSoC project is to implement a Network File System version 4 client. NFS since its early versions became one of the most popular way of sharing files among Unix-like (and not only) systems. The fourth version brings many changes to the protocol that both simplify implementation and make it more efficient. That includes better support of client side caching which can significantly improve performance. In addition to that neither mountd nor NLM needs to be used anymore since services they provide are now part of the protocol.
My name is Alex, I am a first year computer science student with a strong interest in operating systems and low-level software. My GSoC project this year is to begin a port of Haiku to the x86_64 architecture. Almost all modern x86 CPUs have 64-bit support, therefore a port of Haiku will allow it to take full advantage of these CPUs. The GSoC coding period is almost certainly too little time to finish a port of the whole OS, however my plan is to have ported at least the boot loader, kernel and some modules/drivers.
My Google Summer of Code project for this year is to provide a complete port of OpenJDK 7 to Haiku. Over the past few months I've been working on putting together a bootstrapping environment for building OpenJDK on Haiku, and porting the virtual machine and core libraries. Over the summer I hope to bring the port to a mostly-complete state by adding support for AWT, Java2d and jsound. This will allow Swing and AWT-based applications to run on Haiku. Here is an outline of my plans:
Community bonding period
- Continue to work on getting the virtual machine and core libraries self-hosting.
- Eradicate as many bugs as possible from the virtual machine and core libraries to give me a stable base to work from.
- Familiarise myself with Bryan Varner and Andrew Bachmann's AWT/Java2d code from their Java 1.4.2 port, and see what needs to be done to update it to the OpenJDK 7 codebase.
Summer
- Update the existing AWT/J2d port to the OpenJDK 7 codebase and implement the missing functionality.
- Write a jsound port using the Media and MIDI kits.
Future
- Get my work uploaded to the Haiku port project at OpenJDK to make it more official.
- Create a Haiku look & feel for Swing.
- Merge in the updates from the jdk7u project.
You can find my work and a quick attempt at build instructions on Bitbucket: https://bitbucket.org/hamishm/haiku-jdk. The entire source is split across multiple repositories; check my Bitbucket profile for the rest. In the coming weeks I also hope to release some binaries so interested parties can more easily test it out.
