A farewell to pigs
Tonight I have bagged up 12Kg of sausages, 9Kg of chops, 4Kg of spare ribs. I have salted one 7Kg ham, and I have another one waiting in the cool box. In refrigerators and freezers up in the void there is a veritable mountain of pork...
But I get ahead of myself. This week is the first time we've had pigs commercially slaughtered. Previously, we've slaughtered pigs here on the farm, but if you do that firstly need cool weather, and secondly you can't sell the meat, or even give it away. Two pigs, each of them substantially bigger than me, are far more than I can eat; and processing them would have needed me to call on a lot of support from friends.
So after a lot of swithering I decided to get them slaughtered commercially. I organised for them to go to Lockerbie slaughterhouse, and organised for them to be delivered from there to my favourite butcher, Henderson's in Castle Douglas. Again, if you slaughter commercially, you have to have them butchered in a commercial standard, health approved butchery, or you can't sell meat. Henderson's, apart from being my butcher of choice, also quoted a very favourable price — £50 per pig.
Freezer sizing
As I prepare to send the pigs to slaughter, one important issue is how big a freezer to buy.
My estimate of my pigs' live weight, using a well known estimating technique, is about 90 Kg each. Boned out dead weight is likely to be about 66% of that, so say 120 Kg. Of course I shan't keep all that, I'll sell some and give some away; and I shan't freeze all I keep. But given that I won't know how much I'll sell until I sell it, I need to reckon on being able to store 100 Kg of frozen meat.
Flesh just about floats in water; it's within 10% the same density. So a kilogram of meat is about a litre of meat, give or take not very much. But, the packing density will not be perfect; there will inevitably be gaps. Let's say between fudge factors and packing density, I'll need to have space for at least 120 litres.
Reference counting, and the garbage collection of equal sized objects
Yes, I'm still banging on about ideas provoked by the Wing, White and Singer paper, as presented at Mostly Functional. Brief summary: on Friday I posted an essay on the possible use of cons-space as an optimisation for the JVM memory allocator, for use specifically with functional languages (I'm thinking mainly of Clojure, but it has implications for other things such as Armed Bear Common Lisp, and possibly also Scala). Yesterday, I wrote about maintaining a separate heap for immutable objects, as another optimisation. Today, I'm going to write about reference counting, and where it fits in the mix.
The HotSpot JVM uses a tunable generational garbage collector, as detailed here. Generational garbage collectors are a development of the classic mark-and-sweep garbage collector that was used in early LISP implementations from about 1962.
Images of rape
Today has been a day to remember Martin Niemöller. He first cropped up for me this morning, when I saw a news article about the Greek authorities rounding up and interning transexual people as 'undesirables'. But it bit into something I have been thinking for a while about Scotland's (and soon England's, too) repressive and ill thought out legislation on extreme pornography, and especially images of (simulated) rape.
I don't make images of simulated rape. I'm not aware of having ever seen images of 'simulated rape' — and I don't believe I'd know one if I saw one. This law is not against me.
But I do write stories about the ambiguities of sexual morality, and some of my stories touch on ambiguities about consent. In my novel, Harem, there is a rape scene, although I'd claim it's intentionally not eroticised. But what can be done to the visual image can be done even more to the written narrative, because while a static image literally cannot portray consent or the absence of consent, a narrative can (and, if it's taking the matter seriously, must). So this law may not be against me, but it is on a slippery slope, and if the moral Taleban are allowed to get away with this one, the next law may well be about me.
The immutable pool: more on optimising memory management for functional languages
Further to yesterday's note on optimising the Java Runtime Environment's memory allocator for the code generated by functional language compilers, I've been reading up on the memory allocator in the OpenJDK Java platform implementation.
First, a note about nomenclature. To my mind the 'Java Virtual Machine' is simply a processor which processes instruction codes — as it were, something in the same category as an ARM 6 or an Intel 80486, except implemented in software. To me it's clear that memory management is not 'part of' that device, it's a low level library expected to be available as part of the runtime environment. However, the writers of the HotSpot VM documentation don't see it that way. To them, the memory allocator is part of the virtual machine, not part of the runtime environment, and as I'm playing with their ball I shall try in what follows to stick to their preferred nomenclature.