Basically like Jonatan Hedborg here says you don't directly control what is garbage collected.
My guess is you're from a c/c++ background or the like where you are responsible for maintaining memory more strictly and directly, this isn't exactly the case with AS3 and Java; though memory management is still very important it's handled more at an Object level. Although Boolean extends from Object read here regarding primitive types:
Null data type The Null data type contains only one value, null . This
is the default value for the String data type and all classes that
define complex data types, including the Object class. None of the
other primitive data types, such as Boolean, Number, int and uint,
contain the value null . Flash Player and Adobe AIR will convert the
value null to the appropriate default value if you attempt to assign
null to variables of type Boolean, Number, int, or uint. You cannot
use this data type as a type annotation.
http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f88.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f82
In both cases you do have mechanisms such as nulling references to detach objects from the graph of all of the active objects which means they'll be garbage collected at the next scheduled run of the garbage collector (which can be forced but it isn't really recommended, the configuration for the JVM or AVM in this case will handle it based on the system it's running/executing in).
nulling an object will allow it to be garbage collected but you shouldn't really be concerned about individual primitive properties. There's a good article explaining some details on garbage collection in AS3 here (I would leave a an abstract but the whole page is pretty good, main points I suppose being garbage collection isn't necessarily 100% straight-forward but with some effort can be managed):
http://tomgabob.blogspot.com/2009/11/as3-memory-management.html
Basically the way it works is the FlashPlayer or whatever virtual machine is running your (byte)code has a graph of all the objects that have been created and that there is a current reference to.
It also has a memory limit for what it can use based on the environment (config etc.) so the GC has algorithms setup to figure out when it should attempt to garbage collect. You should primarily be concerned with nulling references to objects you no longer need, and really this isn't too big of a deal if your application isn't fairly complex, or your hardware isn't extremely restrictive with regard to RAM.
So the concern shouldn't be making the GC run too little or too much, but creating references that are never removed (addingListeners and not removing from objects that should be collected, or simply having references to them within collections etc. after they are no longer needed). Again the article above explains this in a bit more depth.