Re: [Mono-dev] Reference queue
On 2012-01-24 02:32, Robert Vesse wrote: If it is the case that you have unmanaged resources that you need to clean up that you should really be using the IDisposable interface and calling Dispose() on the class when you are done with it. If it is possible for code paths to 'forget' to call Dispose() then you can include a finalizer as well, if you do this you need to make sure that when Dispose() is explicitly called you call GC.SuppressFinalize() on that object so the finalizer can be skipped Ths MSDN has very comprehensive guidelines on implementing IDisposable and finalizers correctly: http://msdn.microsoft.com/en-us/library/system.idisposable.aspx There is also a simpler guide at http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx without using a finalizer, which is enough if you have only managed resources. Best Regards, D. Rob On Jan 23, 2012, at 4:22 PM, Konrad M. Kruczyński wrote: Thanks for the answer. Here is the case: Let's say I have a class which contains some data in temporary file (for example some kind of cache which should not stay in memory). I'd like to have this file removed when object of this class dies. I can implement a finalizer but if I do this, object will be reclaimed later than it should, also putting additional pressure on GC. Problems of objects with finalizers which are not manually invoked are generally known. And this is scenario where such object can be shared and does not fit into any kind of using block. I think that mentioned API can resolve that kind of problems, because I can set up a callback which deletes temporary file *after* object's death. Therefore it is processed like any other object, without being in special collection for disposable objects. I think it would bring significant performance gain, especially if objects are created often and we expect they die soon. It should be measured, but for that I need some kind of API. What do you think? We've thought about exporting such interface, but the maintenance burden made us back off. This interface has some short-coming and exposing it to managed code has it's problems. For example, it doesn't support unregistering. But, if you make your case on why such a feature would help you, I can look into it. -- Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
Hi all, I think I was misunderstood. This is not beginner's question on how to write classes with Disposable pattern (you mentioned) -- believe me, I know that very well. Problem is rather as follows. Let's say we have an object whose life is short - it is collected on first GC scan after creation. But then if it has a finalizer it is not collected. Instead, it is marked for finalization. After some time its finalizer is called. And it is finally collected after next GC scan - so much more later than in the first case. Things will get worse if it will be promoted to next generation in the meantime. In other words such kind of object with finalizer will stay in memory longer than it should and that is the source of performance problems I mentioned. It can also hold reference to another (fully managed) objects, that one to another and so on. This is well known problem with objects implementing finalizers and one of the reasons (among unpredictability) for recommending explicit (via Dispose) release. But how can one do that if object is shared (the thing you would, for instance in C++, do with reference counting)? Finalizers are best as back-ups for such release, not the main mean, as you have written. I think that callback after death mechanism is the solution here. About the I/O operation invoked - I would not put it in the callback directly, rather enqueue it in thread pool. Oh, I've just found an article which talks about what I exactly meant: http://www.bluebytesoftware.com/blog/2011/11/12/ABriefNoteOnObjectMortality.aspx Apparently this is possible in Java. It could be therefore useful also for IKVM, as it has to be provided by it. I do not know how it is implemented in it currently - probably using small objects with finalizers on which they make proper notifications. I hope it is clearer now. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
On Mon, 2012-01-23 at 23:35 -0200, Rodrigo Kumpera wrote: There is no specially collector for finalizable objects. The finalizer will be called around the same time the callback for such an object would be. I meant the sgen equivalent of the f-reachable queue. Callback will be called around the same time, I agree, but the object itself (with the one it points) can stay in memory longer. Even if performance was backed in, it would not help a lot since you have the large bottleneck of file backed. As I said, I would rather not delete file directly on the callback's thread, but queue its deletion. Also the mentioned approach can be useful for other kinds of resources. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Sorry, the name LIBGC_CPPFLAGS cause something wrong
Hello, Thanks to accept my patch. But sorry, the name LIBGC_CPPFLAGS makes something trouble. Next diff is difference of result of LIBGC_INCLUDES or LIBGC_CPPFLAGS --- BUILD-1/Makefile2012-01-24 21:47:57.0 +0900 +++ BUILD-2/Makefile2012-01-24 22:00:41.0 +0900 @@ -174,7 +174,7 @@ LD = /usr/bin/ld LDFLAGS = -pthread LIBC = libc.so -LIBGC_INCLUDES = -I$(top_srcdir)/libgc/include +LIBGC_CPPFLAGS = -DGC_FREEBSD_THREADS -DPLATFORM_BSD -I/usr/local/include -D__default_codegen__ LIBGC_LIBS = $(top_builddir)/libgc/libmonogc.la LIBGC_STATIC_LIBS = $(top_builddir)/libgc/libmonogc-static.la LIBICONV = /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib When variable name is LIBGC_INCLUDES, the result is correct. But when variable name is LIBGC_CPPFLAGS, autotools overwrite results, and build failed. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] libtool version mismatch
I have been working on writing a recipe for mono for open embedded (OE). I have successfully written one for lbgdiplus and am making headway with mono. Mono comes with libtool version 2.2.6, OE uses 2.4 After ./configure, when make is being executed, I am getting the following error for the following command: Command: /bin/sh ./libtool --mode=compile i586-poky-linux-gcc -m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse --sysroot=/home/autif/data2/nosync/dev/yocto/kokosdk/tmp/sysroots/crownbay -DPACKAGE_NAME=\libgc-mono\ -DPACKAGE_TARNAME=\libgc-mono\ -DPACKAGE_VERSION=\6.6\ -DPACKAGE_STRING=\libgc-mono\ 6.6\ -DPACKAGE_BUGREPORT=\hans_bo...@hp.com\ -DPACKAGE_URL=\\ -DGC_LINUX_THREADS=1 -D_REENTRANT=1 -DPARALLEL_MARK=1 -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -D_IN_LIBGC=1 -I./.. -I./.. -I./include -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT -DUSE_MMAP -DUSE_MUNMAP -O2 -pipe -g -feliminate-unused-debug-types -g -mno-tls-direct-seg-refs -MT allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c -o allchblk.lo allchblk.c Error: | libtool: Version mismatch error. This is libtool 2.4, but the | libtool: definition of this LT_INIT comes from libtool 2.2.6. | libtool: You should recreate aclocal.m4 with macros from libtool 2.4 | libtool: and run autoconf again. | make[3]: *** [allchblk.lo] Error 63 Here is how LT_INIT is defined in aclocal.m4: # LT_INIT([OPTIONS]) # -- AC_DEFUN([LT_INIT], [AC_PREREQ([2.58])dnl We use AC_INCLUDES_DEFAULT AC_BEFORE([$0], [LT_LANG])dnl AC_BEFORE([$0], [LT_OUTPUT])dnl AC_BEFORE([$0], [LTDL_INIT])dnl m4_require([_LT_CHECK_BUILDDIR])dnl dnl Autoconf doesn't catch unexpanded LT_ macros by default: m4_pattern_forbid([^_?LT_[A-Z_]+$])dnl m4_pattern_allow([^(_LT_EOF|LT_DLGLOBAL|LT_DLLAZY_OR_NOW|LT_MULTI_MODULE)$])dnl dnl aclocal doesn't pull ltoptions.m4, ltsugar.m4, or ltversion.m4 dnl unless we require an AC_DEFUNed macro: AC_REQUIRE([LTOPTIONS_VERSION])dnl AC_REQUIRE([LTSUGAR_VERSION])dnl AC_REQUIRE([LTVERSION_VERSION])dnl AC_REQUIRE([LTOBSOLETE_VERSION])dnl m4_require([_LT_PROG_LTMAIN])dnl dnl Parse OPTIONS _LT_SET_OPTIONS([$0], [$1]) # This can be used to rebuild libtool when needed LIBTOOL_DEPS=$ltmain # Always use our own libtool. LIBTOOL='$(SHELL) $(top_builddir)/libtool' AC_SUBST(LIBTOOL)dnl _LT_SETUP # Only expand once: m4_define([LT_INIT]) ])# LT_INIT What changes should be made to the auto tools files to fix this? PS - by no means am I suggesting that mono should upgrade to libtool 2.4, I want to make these changes and submit a patch to OE that goes along with the recipe. Thanks! Autif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] How to access AOTed assembly code?
Hi, everyone, If I call mono --aot=static,asmonly on a dll to generate a .s file, how can I get Mono to load the generated AOT'ed assembly if I include the .s in a native .so I'm building myself as part of an application? It seems Mono normally just goes looking for a .so file for the AOT'ed code. Is it possible to get Mono to use the linked in AOT'ed code in the same native library as the rest of my application? Please let me know if I can provide any more details. Thanks! Kamal ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] How to access AOTed assembly code?
On 24.01.2012 19:39, Kamal Aboul-Hosn wrote: Hi, everyone, If I call mono --aot=static,asmonly on a dll to generate a .s file, how can I get Mono to load the generated AOT'ed assembly if I include the .s in a native .so I'm building myself as part of an application? It seems Mono normally just goes looking for a .so file for the AOT'ed code. Is it possible to get Mono to use the linked in AOT'ed code in the same native library as the rest of my application? Please let me know if I can provide any more details. First, you must embed the runtime as described here: http://mono-project.com/Embedding_Mono Second, you must register the static AOT assembly with mono_aot_register_module. See the description of --aot=static on mono's man page. This assembly can be consumed like any other file-based assembly using the embedding API. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Has Mono an equivalent to the Microsoft Roslyn API?
I need something like the Mircosoft Roslyn API (http://msdn.microsoft.com/en-en/roslyn) to do static source code analysis. Since the Roslyn API is just a developer preview I wanted to know whether Mono offers similar features as the Roslyn API (since Mono has a C# compiler written in C# and the Roslyn API is a C# compiler API I thought this would be possible). I am especially interested in syntax trees, semantic analysis (binding), dataflow and controlflow features (to answer questions like: which variables are read in this basic block, etc.) Thanks, Jochen -- View this message in context: http://mono.1490590.n4.nabble.com/Has-Mono-an-equivalent-to-the-Microsoft-Roslyn-API-tp4324128p4324128.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Has Mono an equivalent to the Microsoft Roslyn API?
The MonoDevelop team contributes to NRefactory 5, which provides pretty much exactly the same functionality as Roslyn for C#. This will power the MonoDevelop C# support in a future version. https://github.com/icsharpcode/NRefactory/ Jonathan On 1/24/2012 9:54 AM, JochenHuck wrote: I need something like the Mircosoft Roslyn API (http://msdn.microsoft.com/en-en/roslyn) to do static source code analysis. Since the Roslyn API is just a developer preview I wanted to know whether Mono offers similar features as the Roslyn API (since Mono has a C# compiler written in C# and the Roslyn API is a C# compiler API I thought this would be possible). I am especially interested in syntax trees, semantic analysis (binding), dataflow and controlflow features (to answer questions like: which variables are read in this basic block, etc.) Thanks, Jochen -- View this message in context: http://mono.1490590.n4.nabble.com/Has-Mono-an-equivalent-to-the-Microsoft-Roslyn-API-tp4324128p4324128.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
