report contain dump for 158Mb but 450+ is reported as max value, it looks most data is gc-ed at time of report and  it may not be memory leak. but may need to investigate more as I may miss something.

As it's PermGen, previous comment may mean nothing.

I'm not yet good in perm gen and dump evaluation, but dump show a lot of mysql classes loaded by 34 different instances of classloaders, most (about 30 in some cases and about 15 in another) are org.netbeans.modules.hibernate.util.CustomClassLoader. And it may mean there is a problem in hibernate.
HibernateEnvironmentImpl::getProjectClassLoader create new classloader on each access, wonder if it can be optimized here, any ideas?
On other side it's just one report without any steps but I'm going to play more with it.

Each hql querry execution create new classloader, each may hold jdbc classes and may not be released, there are two ways find why it's not released and try to keep 1-2 classloaders per project(i.e. try to cache instead of new creation each time) so the issue will effectively gone away. Still need more investigation if it's the as I'm not getting any PermGen yet.

Integrated into 'main-golden', will be available in build *201102030000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/82425bdd0d91
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: #194449 just two places may cause to keep some references

From investigation driver is kept by DriverManager, each hql querry add one more driver, each "pojo from" add number of drivers also, each one is loaded by new classloader and as reference is here(in DriverManager) classloader isn't released it keep a lot of loaded jdbc classes definitions and duplicate on each access - >Permgen.

There is security issues with access and deregistering of drivers, for example even if I explicitly  register driver with DriverManager.registerDriver right after driver class loading in CustomJDBCConnectionProvider, I will not receive it back just in next line with DriverManager.getDrivers(); and same can't deregister next line and will receive securityexception as DriverManager is loaded by system classloader, CustomJDBCConnectionProvider is by OneModuleClassloader and driver class itself by HibernateCustomClassloader.
Also looks like even without explicit registration it's registered here anyway, not sure where. Googling for  "jdbc driver custom classloader" provider some interesting links also. Don't have a solution yet.

driver register itself in DriverManager in next call in nb code "clazz.newInstance()".

Cc'ing Jirka - Jirko, do you know how this works in the DB node in the Services tab? There is probably no memory leak there, right? Do you have some idea how this could be fixed for Hibernate? Thanks.

waiver candidate - it's likely exists since hibernate module implementation and one report so far, I can see the leak but don't see parmgen after dozen of generations, it's likely isn't reproducible in most usual usecases/usual workflow with 1-2 generation in a project.

Waiver approved.

as I have no good solution for security issues, and db module can't be used here (as projects classpath have to be used in hql), decide to cache classloader with weakreference, it should almost resolve the issue (likely one classloader per project instead of one on each hql execution/query modification in the same project). In general the issue may never appear in usual workflow now but I'm not sure it can be marked as fixed also. But may be can be downgraded to p3, 
Petr, what's  your opinion?
(in some specific cases like use execute hql in 30-40 projects of execute, "modify project claaspath -> execute -> modify -> execute ->" sequence for 30-40 times it may appear, yet I wasn't able to reproduce it even before with reasonable time to reproduce)

http://hg.netbeans.org/web-main/rev/fa7571b6b6f2 cache classloader
and also sync classpath for hql parsing and hql execution.

Integrated into 'main-golden', will be available in build *201104230000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/fa7571b6b6f2
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: fix #194449 cache classloader for a project with WeakReference, sync classpath for hql parse and execution

>p3 for now before more evaluation or more reports

it seems no more permgen reports so far, should be quite rare issue but still good to reevaluate later.

I see no new reports after "part fix", may be extremly rare now or can be considered as fixed.