1

I would like to use Java fork join to solve a recursive problem, but I don't want to create a new task instance explicitly for each recursion step. The reason is that too many tasks is equal to too many objects which fills up my memory after a few minutes of processing.

I have the following solution in Java 6, but is there a better implementation for Java 7?

final static AtomicInteger max = new AtomicInteger(10);  // max parallel tasks
final static ThreadPoolExecutor executor = new ThreadPoolExecutor(....);

private void submitNewTask() {
    if (max.decrementAndGet()>=0) {
        executor.execute(new Task(....));
        return;
    }
    run();  // avoid creating a new object
}

public void run() {
    ..... process ....
    // do the recursion by calling submitNewTask()
    max.incrementAndGet();
}

I tried something like calling the invoke() function on the same task again (after updating the related fields, of course), but it does not seem to work.

Mahdi
  • 1,778
  • 1
  • 21
  • 35
  • What does what you are doing have to do with Fork/Join? The whole idea of recursive decomposition is to break a large array into smaller pieces so each piece can run on a different processor. Those pieces are called Tasks. We need a lot more information here. – edharned Nov 15 '12 at 13:52

1 Answers1

0

I think you are not using the right approach. Fork/Join framework is intended to execute a long time running algorithm on a (potentially) big set of data into a parallel fashion splitting your data into smaller pieces (the RecursiveTask itself) than can be executed by more threads (speeding up execution on multiple "cpu" machines) using a work-stealing strategy.

A RecursiveTask does not need to replicate all your data, but just to keep indexes on the portion you are working on (to avoid harmful overlapping), so data overhead is kept at minimum (of course, every RecursiveTask consumes memory too).

There's often a thread off between memory occupation and time of execution in algorithm design, so FJ framework is intended to reduce time of execution paying a (i think reasonably little) memory occupation. If time of execution is not your first concern, I think that FJ is useless for your problem.

giampaolo
  • 6,906
  • 5
  • 45
  • 73