konradreiche / java-concurrency-profiler Goto Github PK

The pie chart illustrating the current thread state distribution can be improved by adding the dimension time. Implement this visualization by using another diagram from JFreeChart.

Logging when and by which thread notifyAll() and wait() is invoked is not sufficient. Profile also the information in which methods notifyAll() and wait() were invoked.

Prepare the use case which profiles ReentrantLock versus ReadWriteLock.

For first results in the bachelor thesis, prepare the code for The Santa Claus Problem. This includes adjusting the solution to use notifyAll() and compare it with other available solutions.

Use the concurrent merge sort implementation to explore a possible problem sketch and its solution by using the profiler. If required extend the functionality of the profiler in order to find a solution. A possible problem sketch is to measure where most of the time is spent in the merge sort implementation.

Refine the use case "The Santa Claus Problem" and "Producer Consumer" in order to get more interesting results on the profiling.

The thesis needs a lot more content for now. Increase the number of thesis pages from 22 to 32.

The Java Programming Language provides for a Thread instance the method getId(). However this ID is not accessibly from fields provided by the JVMTI agent. Therefore a unique identifier is needed in order to distinguish different threads from each other. The JVMTI provides an object tag mechanism. Tag every thread with an incrementing number.

Provide a basic code documentation for the C++ code and provide JavaDoc for the Java code.

Using printf-debugging in Java notifyAll is called less than the profiler displays. This might be due to implementation reasons of the JVM within the operating system and system calls. Investigate this inconsistency and state it in the bachelor thesis.

Refactor the whole Java code base so far to implement a clean use of the MVC pattern.

Implement the designed logging concept #8.

Implement the profiling of the synchronized statement in Java. The implementation includes a new tab in the graphical user interface which displays the logged events concerning actions on the monitors.

Each view should not differ in too many facets. Therefore think about a consistent way of designing each view.

Implement the use of the Java Attach API in order to start profiling already launched JVMs.

Use the Java implementation of the producer-consumer problem to explore a possible problem sketch and its solution by using the profiler. If required extend the functionality of the profiler in order to find a solution.

Comparing the transmitted timestamps and their events with each other, there seems to be an inconsistency. Investigate what the reason is.

Implement the construction of a wait-for graph to the profiler. Consider to replace the log on monitor enter and monitor leaving by this graph.

While iterating over the profiled events it would improve the understanding of what is happening, if the type of the event is displayed. Implement this feature in a meaningful way.

Refactor the inter-process communication between the profiler agent and the profiler GUI. Instead of using XML for serialization use protobuf.

Use the Java ReadWriteLock synchronization construct to explore a possible problem sketch and its solution by using the profiler. If required extend the functionality of the profiler in order to find a solution.

Prepare the results of the first two use cases for proofreading.

The presentation of the logged notify-wait data can be improved by using a flowchart graph. Implement this flowchart graph.

Currently every monitor events triggers agent messages which include a monitor lock, respectively its identification and statistics about it. When entering a synchronized block this is valid. However these data should not be send when wait(), notify() or notifyAll() is called upon a monitor lock, because this leads to too much monitor locks in the end.

Since wait(), notify() and notifyAll() calls are usable to get the class type of the monitor lock, an intermediate solution should be found in order to get meaningful data.

Due to the nature of profiling, it is possible, Agent Messages are received in the wrong order. This applies only to a little number of messages. To reduce the fault tolerance anyway, implement a message reordering.

Finish the thesis.

The section 1.4 "Threads are everywhere" in Java Concurrency In Practice offer a good set of arguments, why dealing with threads is important. Use this argumentation to start writing the motivation section in the bachelor thesis.

A feature which is missing for a long time, is the profiling of multiple JVMs. Since the tool is in the process of a total refactoring, use this to implement the possibility of profiling multiple JVMs. The different JVMs should by selectable through a new tabbed panel which encapsulates the different views.

The message processing in the Java front-end is not flexible. Refactor the message processing in a way it is encapsulated in a wrapper class allowing to execute and undo the message.

In order to have enough time for rewriting finish the first thesis draft.

Add timetamps to the messages generated by the profiling agent.

Provide a building process which can be adapted as easy as possible without using the Eclipse CDT development environment. Provide a short manual how to build and use the profiler.

Find a solution to start Java programs from the Profiler GUI which also initiates the profiling at the start.

Add a monitor event when the method notify() is exited.

Use the Java implementation of the Santa Claus problem to explore a possible problem sketch and its solution by using the profiler. If required extend the functionality of the profiler in order to find a solution.

Add simple statistics about invocations of notify wait, for instance count the method invocations per thread.

Add some sort of collecting thread data which provides a thread statistic for every thread. The thread statistic is visualized in Java using a graphical design.

The JVMTI API offers functions to get the time which the CPU spent for a certain thread. Get these information on the termination of a thread and display it in the overview tab.

At the moment, generated Agent Messages are sent by invoking the send function on the active socket. Instead the generated Agent Messages should only be inserted into the queue of messages which pend for being transmitted.

Implement or at least refactor the GUI to the new concept which was developed in the last week.

Instead of JGraph the JUNG library should be used.

Displaying the current events will not be sufficient to get an insight on the profiled program behavior. Investigate a potential solution for logging all the events generated by the profiling agent, for instance using snapshots at certain hooks or using a complete event history.

The JVMTI API function GetObjectMonitorUsage offers information about an object's monitor. Pack these information into the MonitorEvent and model it in Java as a class describing a lock object. Display these information in Java on the Lock tab in a textual representation.

Provide a first draft for the basics chapter in the thesis for the topics Java Threads and Java Memory Model.

In #7 the idea was taken up for a conceptional visualization of the Java methods notify() and wait() and their side effects. Implement it in a simple way without further visualization but textual representation.

Check if it useful to put the profiling agent into its own C++ class. Further create a class in C++ which encapsulates the auxiliary functions used by the profiler agent.

Methods can be measured in different means: time taken, CPU clock cycles, number of invocations or relative wall time compared to every other method. Implement this feature and display the results in a table.

Create the first draft of a possible target use case for the profiler, for instance a simple program using the producer-consumer pattern which lacks balanced number of producer or consumer thread with respect to the CPU utilization.