Not sure, nothing is called, "virtual memory" on the page for a completed task WITH cpdn. I get a range between,
Application version OpenIFS v2.21
x86_64-pc-linux-gnu
Peak working set size 8,834.75 MB
Peak swap size 9,729.43 MB
Peak disk usage 2,719.39 MB

and,

Application version UK Met Office HadAM4 at N216 resolution v8.52
i686-pc-linux-gnu
Peak working set size 1,374.03 MB
Peak swap size 1,395.37 MB
Peak disk usage 108.05 MB

The latter running no more than 6 tasks with 32GB RAM. I can't remember how many of the first were running at once but currently running 6 tasks I am not using any swap.

In some OS it is possible for an application to restrict the amount of virtual (swap) memory it is allowed to use. As with many things in BOINC this is a limit not an absolute figure, if the system has enough RAM for the application's demands then there will be no demand on the virtual memory so none will be allocated to the application by the OS.

In some OS it is possible for an application to restrict the amount of virtual (swap) memory it is allowed to use. As with many things in BOINC this is a limit not an absolute figure, if the system has enough RAM for the application's demands then there will be no demand on the virtual memory so none will be allocated to the application by the OS.

Yes, but nevertheless, on a system like mine with lots of memory, BOINC Properties for a task can look like this, and virtual memory is at least shown, even if not used:

Application
Mapping Cancer Markers 7.41
Name
MCM1_0174049_8594
State
Running
Received
10/04/2021 12:03:39
Report deadline
14/04/2021 00:03:28
Estimated computation size
32,556 GFLOPs
CPU time
02:07:41
CPU time since checkpoint
00:03:11
Elapsed time
02:10:12
Estimated time remaining
01:45:16
Fraction done
50.200%
Virtual memory size
76.28 MB
Working set size
78.57 MB
Directory
slots/2
Process ID
1788
Progress rate
23.040% per hour
Executable
wcgrid_mcm1_map_7.41_windows_x86_64

Virtual memory depends on OS.
Sometimes it stores passive data in VM, like already processed WUs, that no longer need any read/modifying.
I presume that in case the system crashes, without saving that data to a file, you can still extract the data with some professional software no one ever uses (more like for recovery purposes).
For WUs it doesn't make sense though, because it takes way longer to properly recover the data, than it does to just redo the entire WU.

I think BOINC just lists corresponding OS counters for those values, nothing more.
And to have them listed is useful for debugging, managing what tasks fit for what PC.
In Windows all "usual" app memory is virtual. So working set size always should be less than "virtual, or swap" size. Even if in reality HDD swap was not used.
In task manager this value called "commit size".

Boinc doesn't manage it. Just as with RAM itself. But, if threshold exceeded, it can suspend task (for example, user could use this as guard against excessive HDD usage with swapping).

---