rik/jlibcom
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

updated autogc notes

Browse Source
This commit is contained in:
clay_shooter
2007-05-17 02:36:08 +00:00
parent e98dc4b0cf
commit 90eb8609a3
2 changed files with 21 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/ReleaseNotes.html
View File

@@ -5,7 +5,8 @@
<h3>What's New</h3>
<ul>
<li>
<b>Now compiles with with Visual Studio 2005</b>
<b>Now compiles with with Visual Studio 2005 (M1)</b>
<b>Changed milestone release naming convetion from "pre..." to "M..."</b>
</li>
</ul>
@@ -23,7 +24,7 @@
</tr>
<tr>
<td width="13%" valign="top">1709841 </td>
<td width="87%" valign="top">(pre-release 1) Compiles with Visual Studio 2005</td>
<td width="87%" valign="top">(M1) Compiles with Visual Studio 2005</td>
</tr>
<tr>
<tr>
@@ -94,9 +95,9 @@
</tr>
<tr>
<td width="13%" valign="top">1674015</td>
<td width="87%" valign="top">(pre-release 1) ROT hashmap handling when autogc=no (default) can lead to key collisions
in hashmap. This causes objects to be garbage finalized when they shouldn't be resulting in vm failures
with large (large) numbers of objects. </td>
<td width="87%" valign="top">(pre-release 1) ROT hashmap key generation when autogc=no (default)
can lead to key collisions in hashmap. This causes objects to be garbage finalized
when they shouldn't be resulting in vm failures with large (large) numbers of objects. </td>
</tr>
<tr>
<td width="13%" valign="top">1674179</td>

18
docs/UsingJacob.html
View File

@@ -34,8 +34,20 @@ This library supports several different :
<h3>com.jacob.autogc </h3>
Determines if automatic garbage collection is enabled. This is the
only way to free up objects created in event callbacks. This
feature is not fully debugged.
only way to free up objects created in event callbacks. Automatic garbage collection , based on Java gc rules, garbage collection can be enabled via the
<code>com.java.autogc</code> command line option.
<em>This feature was added in release 1.9 is not fully debugged. </em>
<p>
There are real reasons for managing the
lifetime of JacobObjects on a per thread basis.
Jacob normally manages the the com/Java object lifetime as described in the
<a href="JacobComLifetime.html">JacobComLifetime.html</a> document.
Some users have run into situations where they wish to try and let the Java
GC lifetime manage the lifetime of objects. This seems to usually be tied
to long running threads or to objects created as part of event callbacks.
Code was added to let users try and let the JVM manage the object life cycles
even though the <a href="JacobComLifetime.html">JacobComLifetime.html</a> document
says this is a bad idea.
<p>
The default value is <strong>false</strong>
<p>
@@ -49,7 +61,7 @@ This library supports several different :
<h3>-XCheck:jni</h3>
This turns on additional JVM checking for JNI issues. This is
not strictly a JACOB system property.
not an actual JACOB system property but a property used by the JVM.
<p>
The default is "no additional checking"
Example: -XCheck:jni