Thank you for reviewing my pull request, Reynold. I have followed your advice as blow.
1.Change the name of methods.
Answer: I have changed their names in the last commit as you suggested.

2.Performance issues for HadoopRDD.
Answer: This is a good concerning. In fact, the message size of a blockinfo transferred is no large. To make it flexible, I added a boolean parameter 'tellMaster (default is true)' for broadcast variables. When set false, the broadcast variable will not be reportted to master and not be removed at slave machines in a SparkContext, this is suitable for small-size broadcast variables. Users can choose the broadcast type at their wish.

3.Track the memory usages of broadcast. 
Answer: This a good idea. It can lead making a automatic memory cleaner for broadcast variables. Nevertheless, the purpose of this patch is providing a removing broadcast API to users. These two things do not conflict in essence. For memory cleanup tasks, the lesson I learned is that, whatever program-monitoring mechanisms seems not better than clear the memory explicitly by users if possible. GC can not always be in time and it has overhead costs. Moreover, in this case, it is hard to determine whether a broadcast needed be used by users any more. On the other side, it is a issue to leave large unused broadcast variables in memory, and users have no means to handle that. Therefore, we provide a explicit removing broadcast method to users. It solves my problem in practise. 

Thank you for commenting again and I will continue thinking about the automatic cleaner based on tracking memory usage you put forwarded here , it's interesting.