# Monday, 26 March 2012
« IKVM.Reflection: Inspecting an Assembly ... | Main | Lang.NEXT »
New Development Snapshot

Enough changes to warrant a new development snapshot.

Changes:

  • Fixes and improvements to Windows version of JFileChooser.
  • Bug fix. When writing a direct ByteBuffer to a non-blocking socket and the write fails because there is no kernel buffer available, we should not advance the ByteBuffer position.
  • Bug fix. Non-public property getter/setter methods should be ignored when we create properties to hide properties inherited from shadow types. This fixes a build break with .NET 4.5 beta which introduces a protected setter for Exception.HResult.
  • Bug fix. Custom attribute properties that don't have a public getter and setter should not be exposed as annotation properties.
  • Added ikvmc -win32manifest: option.
  • Added ikvmc -filealign: option.
  • Added ikvmc -highentropyva option (to enable high entropy ASLR in 64 bit processes on Windows 8).
  • Added support for custom paper format to Win32 print service.
  • Changed ikvmstub to create a missing assembly when a dependency is not found and only complain about it when it is actually needed.
  • Added explicit -help and -? options to ikvmc.
  • Added ikvmc -nologo option.
  • Changed ikvmc to print copyright when compiling (unless -nolog is specified).
  • Cleaned up to ikvmc help message.
  • Lots of ikvmc error handling clean up. All errors now have an IKVMCnnnn error code.
  • Added support to ikvmc to automatically set the full source path in the debugging info if the source file lives next to the .class file.
  • Improved BufferedImage.setRGB().
  • IKVM.Reflection: Added AssemblyBuilder.__DefineManifestResource() API to add a Win32 manifest resource.
  • IKVM.Reflection: Various win32 resource related methods on AssemblyBuilder now throw ArgumentException if a conflicting resource has already been defined.
  • IKVM.Reflection: Marked ModuleBuilder.__SetStackReserve() obsolete and made ModuleBuilder.__StackReserve property writeable to be consistent with __ImageBase property.
  • IKVM.Reflection: New API. Made ModuleBuilder.__FileAlignment writeable.
  • IKVM.Reflection: New API. Added Module.__DllCharacteristics and ModuleBuilder.__DllCharacteristics properties to get and set image DLL characteristics flags.

Binaries available here: ikvmbin-7.1.4468.zip

Monday, 26 March 2012 08:53:15 (W. Europe Daylight Time, UTC+02:00)  #    Comments [10]
Monday, 02 April 2012 03:24:29 (W. Europe Daylight Time, UTC+02:00)
could you advise how to build IKVM targetting 4.0 framework? nant 0.85 doesn't seem to support it, at least out of the box. it would be nice to have the HOWTO file updated with the information how to target different frameworks.

thanks.
Ivan
Monday, 02 April 2012 10:22:14 (W. Europe Daylight Time, UTC+02:00)
If you use Nant 0.91 it will build against 4.0 by default.
Monday, 02 April 2012 13:27:41 (W. Europe Daylight Time, UTC+02:00)
oh well, 2.0 version dies with OutOfMemory exception due to classloader objects not being GCed, 4.0 doesn't leak but crashes randomly with System.ExecutionEngineException. is there a chance that 4.5 is going to work?
Ivan
Monday, 02 April 2012 14:26:36 (W. Europe Daylight Time, UTC+02:00)
If you want 4.5 to work, your best bet is to report a bug with Microsoft for the System.ExecutionEngineException.

I don't mind doing it myself, but I won't have time until next week and the sooner the better, because I think they're already pretty close to freezing 4.5 development.
Monday, 02 April 2012 14:30:00 (W. Europe Daylight Time, UTC+02:00)
Also, on a more practical note, is this really a showstopper for your? Because if it is there are several possible workarounds for the class leaking. For example, you can create the report in a new AppDomain and unload it after you're done.

It might also be possible to configure Jasper Reports to not do any code gen (I'm just guessing here, I don't know anything about it) or at maybe reuse the code for the same reports.

Wednesday, 04 April 2012 03:13:33 (W. Europe Daylight Time, UTC+02:00)
there is a problem with AppDomain approach: domain sometimes won't unload (CannotUnloadAppDomainException). it appears that the reason for this is a thread named "IKVM AWT WinForms Message Loop" that keeps running inside a domain and prevents it from unloading. is there a way to stop it?
Ivan
Wednesday, 04 April 2012 03:38:05 (W. Europe Daylight Time, UTC+02:00)
Are you running into this occasionally during stress or does every AppDomain unload fail?

I know that I see AppDomain unload failures under stress as well.
Wednesday, 04 April 2012 04:51:56 (W. Europe Daylight Time, UTC+02:00)
in this particular test scenario i run 10 AppDomains in 10 threads in parallel and unload failures happen pretty much on every run, but they happen at random - usually between 1 and 4 domains fail to unload. i set up a try-catch block to reattempt domain unloads:

int attempt = 1;
while (attempt <= 100)
{
try
{
AppDomain.Unload(_domain);
break;
}
catch
{
Console.WriteLine("AppDomain.Unload attempt " + attempt + " failed for " + _domainName);
attempt++;
Thread.Sleep(10000);
}
}

after some time when all threads have completed, there's a consistent list of stuck domain names in the console. at this point i break the execution and check the Threads window in visual studio debugger. there is exactly the same amount of "IKVM AWT WinForms Message Loop" threads as the amount of domains that failed to unload.
Ivan
Wednesday, 04 April 2012 05:10:25 (W. Europe Daylight Time, UTC+02:00)
The fact that you see the message loop threads does not necessarily mean that they cause the unload to fail, it can simply be the result of the failed unload (if the unload for some reason fails before it gets around to aborting the message loop thread).

I'll have to have a more detailed look at this when I get back.
Wednesday, 04 April 2012 05:38:49 (W. Europe Daylight Time, UTC+02:00)
valid point. just in case, some extra information that could possibly give some ideas: i create domains in separate threads. unload never fails if only 1 domain is being loaded/unloaded consecutively (ie no parallel execution). fails only appear if 2 or more threads are being run simultaneously, and happen faster when number of parallel threads is greater.
Ivan
Name
E-mail
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Answer:  
Comment (HTML not allowed)  

Live Comment Preview